你适合微服务么：实施微服务的4个先决条件和重点工作

       “Mesh App and Service Architecture”作为Gartner2016 十大战略技术趋势中之一，里面大量提到微服务的概念。微服务（Microservices）这个概念不是新概念，很多公司已经在实践了，例如Google、Netflix、Facebook、Twiter、Alibaba。微服务架构模式（Microservices Architecture Pattern）的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务，每个服务都可以很容易得局部改良。微服务从去年以来一直受到众多开发者的热捧，已经看到有许多项目尝试使用微服务架构，结果很鼓舞人心。然而，在微服务架构带来可独立部署、高扩展与伸缩、自由选择开发语言、高效利用资源、故障隔离等优点，同时也因为服务多带来分布式事务、服务之间通信、监控、部署等新的问题。

       除了上述问题，我相信大家也会存在一些疑问：我们公司或者系统适不适合选择微服务架构？选择微服务架构前，我需要准备哪些预备知识或者先决条件？碰到上述哪些问题，我们该如何解决？需要哪些基础框架或组件来支持微服务架构？接触微服务大概一年多的时间，并且我们团队已经在去年使用微服务架构搭建我们数字化企业云平台，同时在这块也投入了很多时间去学习和研究，有一些经验和学习心得，可以和大家一起分享与学习，下面我将会从以下几点进行分享：

（1）    为什么要选择微服务架构以及何时选择微服务架构；

（2）    讲述实施微服务架构的一些先决条件；

（3）    实施微服务架构中重点知识与实践的介绍。

一．为什么要选择微服务架构以及何时选择微服务架构

        提到微服务架构时，我们常常会做的一件事情，就是会拿来与单体架构进行比较，单体架构存在如下缺点：代码维护难度大，臃肿的部署，局限的弹性与扩展能力，阻碍团队与技术革新等等；微服务架构存在如下优点：代码维护简化，可独立部署，高扩展与伸缩，自由选择开发语言等优点。那么单体架构真的如此不堪一击吗？答案显然不是这样，下面我们来看Martin Fowler在其一篇文章里面给出关系图：

 

        上面的图来自 Martin Fowler 的文章，揭示了生产率和复杂度的一个关系。在复杂度较小时采用单体应用（Monolith）的生产率更高，复杂度到了一定规模时，单体应用的生产率开始急剧下降，这时对其进行微服务化的拆分才是合算的。所以说脱离业务场景，空谈架构绝对是耍流氓。异常牛逼的架构设计，如果无法在业务场景中落地实施，也只是空谈。因此架构需要服务于业务，针对不同的业务场景架构设计也会不同，架构设计不必追求高大上，简而美的架构，若能满足业务发展需求，便是好架构。此外，好的架构不完全是设计出来的，随着业务量、请求量的增长，好的架构是演化而来的。微服务架构之所以得到广泛认可，源于对于业务多变性的不可预测，微服务架构能够不断的自演化，进而快速适应业务变化。但相对于单体架构且经过严格定义的大规模开发项目，微服务架构要求大家面对由众多小型服务所构成的复杂生态系统。

        鉴于此，如果长期业务规划不需要微服务架构或者团队不具备实施微服务一些基本的条件，不建议各位盲目迈向微服务这一新兴架构领域，或者从试点入手，逐步在团队中推行微服务架构。

二．   实施微服务架构的一些先决条件

如上所述，实施微服务架构需要一些先决条件，那么到底有哪些基准条件呢？Martin Fowler在其的一篇文章给出他的理解，如下所示：

  

     （1）快速配置:大家应该能够在几个小时之内配置并启用一台全新服务器设备。一般来说采用云计算方案能够大大缩短这一处理流程，不过我们同样可以在无需依赖完整云服务的前提下实现这一目标，容器技术不断成熟使其变得可行；（2）基础运维与监控:由于微服务架构要求我们将大量松散耦合的服务统一在同一套生产流程中并实现其协作，因此大家往往很难单纯依靠测试环境来检测出未来可能发生的意外故障。这样一来，运维和监控体系就成了快速检测并定位严重问题的不二选择；（3）应用程序快速部署:由于存在大量需要管理的微服务，大家必须有能力快速将其部署到开发、测试、预发，生产环境当中。通常情况下，我们只能利用部署流水线（Deployment Pipeline）来保证整个过程在数小时之内彻底完成。在早期阶段，大家还可以通过人工方式加以干预，但在后续运作当中所有相关工作都要由自动化机制负责完成；（4）持续改进的团队组织：著名的康威定律说过“设计系统的组织，最终产生的设计等价于组织的沟通结构“，由于微服务“按业务能力组织服务“和“服务即产品“的特征，我们会把一个大应用拆分成不同的微服务，更倾向于让每个团队自己负责整个产品的全部生命周期，所以每个微服务背后的小团队的组织是跨功能的，包含实现业务所需的全面的技能，微服务负责制对个人能力要求更高，自驱动和自学习能力更强的人会得到更多的成长机会。

三．   实施微服务架构中重点知识的介绍

3.1运行期配置管理

       首先，我们认为配置分成两部分：运行前静态配置和运行期动态配置，静态配置部分可以阅读我同事的文章《DevOps之软件配置协作化管理》，我这里主要讲解运行期动态配置管理。

        服务一般有很多依赖配置，例如访问数据库有连接字符串配置，连接池大小和连接超时配置，这些配置在不同环境(开发/测试/预发/生产)一般不同，比如生产环境需要配连接池，而开发测试环境可能不配，另外有些参数配置在运行期可能还要动态调整，例如，运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置，简化架构如下图所示:

       动态配置存放在集中的配置服务器上，用户通过管理界面配置和调整服务配置，具体服务通过定期拉(Scheduled Pull)的方式或者服务器推(Server-side Push)的方式更新动态配置，拉方式比较可靠，但会有延迟同时有无效网络开销(假设配置不常更新)，服务器推方式能及时更新配置，但是实现较复杂，一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题，对于大规模服务化环境，配置中心还要考虑分布式和高可用问题。

      类似配置中心比较成熟的开源方案有百度的Disconf，360的QConf，Spring的Cloud Config和阿里的Diamond等。

3.2 基础运维与监控

        由于微服务架构一个大应用拆分成不同的微服务，每个服务都是运行在不同进程上。因此，需要为服务建立独立的监控、告警、快速分析与定位的机制。

        监控是整个运维环节中非常重要的一环。监控通常分为两类：系统监控与应用监控。系统监控关注服务运行所在节点的健康状况，譬如CPU、内存、磁盘、网络等。应用监控则关注应用本身及其相关依赖的健康状况，譬如服务本身是否可用、其依赖的服务是否能正常访问等。我们知道，当系统出现异常时，通过监控能发现异常，这时候我们通过合适的告警机制，则能及时、有效地通知相关责任人，做到早发现问题，早分析问题，早修复问题。然而当我们面对很多微服务，每个服务由于负载均衡又会部署多个实例，再使用单体架构那边查看日志方式显然不合适(成本会呈几何倍增加)，通过日志聚合的方式，能有效将不同节点的日志聚合到集中的地方，便于分析和可视化，能够快速发现和解决问题，基本流程如下图所示：

          在我们的数字化企业云平台中，由于是基于容器技术的，使用的CoreOS系统，最终我们采用了Journald+Fluentd+ElasticSearch的技术，更多详情见我们另外一个同事的《微服务来了，监控怎么办？》。

3.3应用程序快速部署

        由于存在大量需要管理的微服务，大家必须有能力快速将其部署到开发、测试、预发，生产环境当中。通常情况下，我们只能利用部署流水线（Deployment Pipeline）来保证整个过程在数小时之内彻底完成。在早期阶段，大家还可以通过人工方式加以干预，但在后续运作当中所有相关工作都要由自动化机制负责完成。部署大概经历了三个发展阶段：手动部署，脚本部署，以及自动化部署（应用和基础设施）。在我们数字化企业云平台中，由于使用容器的技术，最终都会打包成镜像部署到相应的容器里面，我们抽象出一个微服务叫做SRM（软件发布管理），同时为了避免环境的差异性（物理机、虚拟机、容器），又抽象出另外一个微服务叫做SEM（软件环境管理），有他们俩共同完成应用程序的快速部署。其与其他领域微服务的关系图如下：

       那么，他的部署流程到底又是咋样呢？SRM收到部署请求后，会加载产品与组件部署拓扑数据；然后根据组件的依赖逆序向“软件环境管理系统SEM”发起部署请求，对于单个组件部署，SRM将用户指定的部署规格传递到SEM系统中，SEM系统根据部署规格进行组件的部署，部署规格目前采用yaml文件格式描述，主要包含的内容包括镜像地址、部署类型、部署参数等数据。实际上SRM中的部署规格主要是对SEM系统内容器的服务部署能力的体现。如下图所示：

      上述只是应用自动化部署的过程，如果还想了解其中的详情，可以阅读我的同事另一篇文章《DevOps之应用自动化发布与资源管理》。

3.4持续改进的团队组织

       由于微服务“按业务能力组织服务“和“服务即产品“的特征，我们会把一个大应用拆分成不同的领域系统，更倾向于让每个团队自己负责整个产品的全部生命周期，形成团队组织去中心化。著名的康威定律说过“设计系统的组织，最终产生的设计等价于组织的沟通结构“，常见的微服务组织结构图如下：

      这本来是一个很好的想法，每个团队有自主的权利，选择合适开发语言与数据库，相互之间通过RestFul API进行通信，维护更加简化，责任明确等优点，但是也带来一些问题：代码风格不统一，全局系统化考虑不周到，日志格式不统一，依赖关系变变复杂，服务之间团队协作比较差等。为了解决以上问题，我们对于上述组织结构进行改动（我这里说主要是研发团队），如下图所示：

       总体架构组负责对于每个领域系统技术选型进行评定与约束，以及共有的标准制定、底层架构的支持，领域系统关系的梳理等，这样就不会导致技术选型过度碎片化，给后期管控以及实现自动自助化运营带来方便。无自动化不微服务，自动化包括编译、打包、测试和部署，单一进程的传统应用被拆分为一系列的多进程服务后，意味着开发、调试、测试、监控和部署的复杂度都会相应增大，必须要有合适的自动化基础设施来支持微服务架构模式，否则开发、运维成本将大大增加，正是由于DevOps的存在使得微服务能够得到大规模化的使用。试想一下，把 1 个应用进程部署到 1 台主机，部署复杂度是 1 x 1 = 1，若应用规模需要部署 20 台主机，那么部署复杂度是 1 x 20= 20。 把 1 个应用进程拆分成了 50 个微服务进程，则部署复杂度变成了 50 x 20 = 1000，缺乏自动化设施，光部署就会把人搞死。

总结

        本文从微服务的定义出发，得出微服务的优点与问题，然后分成几大模块：第一部分，为什么选择微服务架构，以及何时开始实施微服务架构；第二部分，讲述实施微服务架构的一些先决条件；第三部分，我们在实施微服务架构中一些重点知识的介绍,比较全面的梳理总结微服务架构的各方面。微服务是一个近年的新概念，但却真不是一个原创性的新东西。它帮助大型应用打散和转移了复杂性，使其可以被更高效的并行解决，但并没有减少任何复杂性，甚至还引入了额外的分布式计算固有的复杂性。我们需有一个清晰的认识，才能更好的认识和实践微服务架构。