什么是微服务架构
“微服务 ”一词源于Martin Fowler 的名为 Microservices 的博文， 可以在他的官方博客上找到： http://martinfowler.com/articles/microservices.html。简单地说， 微服务是系统架构上的一种设计风格， 它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作。 被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建， 并且每个服务都维护着自身的数据存储、 业务开发、自动化测试案例以及独立部署机制。 由千有了轻量级的通信协作基础， 所以这些微服务可以使用不同的语言来编写。
如何实施微服务
在实施微服务之前， 我们必须要知道， 微服务虽然有非常多吸引人的优点， 但是也因为服务的拆分引发了诸多原本在单体应用中没有的问题。
• 运维的新挑战：在微服务架构中， 运维人员需要维护的进程数量会大大增加。 有条不紊地将这些进程编排和组织起来不是 一 件容易的事， 传统的运维人员往往很难适应这样的改变。 我们需要运维人员有更多的技能来应对这样的挑战， 运维过程需要
更多的自动化， 这就要求运维人员具备 一 定的开发能力来编排运维过程并让它们能自动运行起来。
• 接口的 一 致性：虽然我们拆分了服务， 但是业务逻辑上的依赖并不会消除， 只是从单体应用中的代码依赖变为了服务间的通信依赖。 而当我们对原有接口进行了 一 些修改， 那么交互方也需要协调这样的改变来进行发布， 以保证接口的正确调用。 我们需要更完善的接口和版本管理， 或是严格地遵循开闭原则。
• 分布式的复杂性：由于拆分后的各个微服务都是独立部署并运行在各自的进程内，它们只能通过通信来进行协作， 所以分布式环境的问题都将是微服务架构系统设计时需要考虑的重要因素， 比如网络延迟、 分布式事务、 异步消息等。尽管微服务架构有很多缺点和问题， 但是其实现的敏捷开发和自动化部署等优点依然被广大优秀架构师和开发者所青眯， 所以解决这些问题就是这几年诸多架构大师努力的目标。
在架构师对于 一 个大型系统架构的设计与实施的过程中， 面对环境、 资源、 团队等各种因素的影响， 几乎不会出现完全相同的架构设计。 对于微服务架构而言更是如此， 由于并没有 一 个标准或正式的定义，每位架构师都根据自身理解与实际情况来进行设计， 并在发展的过程中不断演化与完善。 经过多年的发展，Martin Fowler 在 Microservices一 文中，提炼出了微服务架构的九大特性，用于指导大家设计架构。
服务组件化
组件， 是 一 个可以独立更换和升级的单元。 就像 PC 中的 CPU、 内存、 显卡、 硬盘 一样， 独立且可以更换升级而不影响其他单元。在微服务架构中，需要我们对服务进行组件化分解。 服务， 是 一 种进程外的组件， 它通过 HTTP 等通信协议进行协作， 而不是像传统组件那样以嵌入的方式协同工作。 每 一 个服务都独立开发、 部署， 可以有效避免 一 个服务的修改引起整个系统的重新部署。打 一 个不恰当的比喻，如果我们的 PC 组件以服务的方式构建，那么只维护主板和 一些必要外设之后，计算能力通过 一 组外部服务实现， 我们只需要告诉 PC 从哪个地址来获得计算能力，通过服务定义的计算接口来实现我们使用过程中的计算需求， 从而实现 CPU组件的服务化。 这样原本复杂的 PC 服务得到了轻量化的实现， 我们甚至只需要更换服务地址就能升级 PC 的计算能力。
按业务组织团队
当决定如何划分微服务时， 通常也意味着我们要开始对团队进行重新规划与组织。 按以往的方式，我们往往会从技术的层面将团队划分为多个，比如DBA团队、运维团队、 后端团队、 前端团队、 设计师团队等。 若我们继续按这种方式组织团队来实施微服务架构开发，当有 一 个服务出现问题需要更改时，可能是 一 个非常简单的变动， 比如对人物描述增加 一 个字段， 这需要从数据存储开始考虑 一 直到设计和前端， 虽然大家的修改都非常小，但这会引起跨团队的时间耗费和预算审批。在实施微服务架构时，需要采用不同的团队分割方法。 由于每 一 个微服务都是针对特定业务的宽栈或是全栈实现， 既要负责数据的持久化存储， 又要负责用户的接口定义等各种跨专业领域的职能。 因此，面对大型项目的时候， 对于微服务团队的拆分更加建议按业
务线的方式进行拆分，一 方面可以有效减少服务内部修改所产生的内耗； 另 一 方面， 团队边界可以变得更为清晰。
做“产品”的态度
在实施微服务架构的团队中，每个小团队都应该以做产品的方式， 对其产品的整个生命周期负责。 而不是以项目的模式，以完成开发与交付并将成果交接给维护者为最终目标。开发团队通过了解服务在具体生产环境中的情况， 可以增加他们对具体业务的理解，比如， 很多时候，一 些业务中发生的特殊或异常情况， 很可能产品经理都并不知晓， 但细心的开发者很容易通过生产环境发现这些特殊的潜在问题或需求。所以， 我们需要用做“ 产品 ”的态度来对待每 一 个微服务， 持续关注服务的运作情况，
并不断分析以帮助用户来改善业务功能。
智能端点与哑管道
在单体应用中， 组件间直接通过函数调用的方式进行交互协作。 而在微服务架构中，由于服务不在一个进程中， 组件间的通信模式发生了改变， 若仅仅将原本在进程内的方法调用改成 RPC 方式的调用， 会导致微服务之间产生烦琐的通信， 使得系统表现更为糟糕，所以， 我们需要更粗粒度的通信协议。在微服务架构中， 通常会使用以下两种服务调用方式：
• 第 一 种， 使用HTTP的 RESTful API或轻量级的消息发送协议， 实现信息传递与服务调用的触发。
• 第二种， 通过在轻量级消息总线上传递消息， 类似 RabbitMQ 等 一 些提供可靠异步交换的中间件。
在极度强调性能的情况下 ， 有些团队会使用二进制的消息发送协议 ， 例如protobuf。 即使是这样 ， 这些系统仍然会呈现出“ 智能瑞点和哑管道 ”的特点， 这是为了在易读性与高效性之间取得平衡。当然大多数 Web 应用或企业系统并不需要在这两者间做出选择， 能够获得易读性已经是一个极大的胜利了。
一Martin Fowler
去中心化治理
当我们采用集中化的架构治理方案时， 通常在技术平台上都会制定统 一 的标准， 但是每 一 种技术平台都有其短板， 这会导致在碰到短板时， 不得不花费大力气去解决， 并且可能因为其底层原因解决得不是很好， 最终成为系统的瓶颈。在实施微服务架构时， 通过采用轻量级的契约定义接口， 使得我们对于服务本身的具体技术平台不再那么敏感， 这样整个微服务架构系统中的各个组件就能针对其不同的业务特点选择不同的技术平台， 终千不会出现杀鸡用牛刀或是杀牛用指甲钳的尴尬处境了。
不是每一个问题都是钉子， 不是每一个解决方案都是锤子。
去中心化管理数据
我们在实施微服务架构时， 都希望让每一个服务来管理其自有的数据库， 这就是数据管理的去中心化。在去中心化过程中， 我们除了将原数据库中的存储内容拆分到新的同平台的其他数据库实例中之外（如把原本存储在MySQL中的表拆分后，存储到多个不同的MySQL实例中），也可以将 一 些具有特殊结构或业务特性的数据存储到 一 些其他技术的数据库实例中（如把
日志信息存储到 MongoDB 中或把用户登录信息存储到 Redis 中）。虽然数据管理的去中心化可以让数据管理更加细致化， 通过采用更合适的技术可让数据存储和性能达到最优。 但是， 由于数据存储于不同的数据库实例中后， 数据 一 致性也成为微服务架构中亟待解决的问题之 一 。 分布式事务本身的实现难度就非常大， 所以在微服务架构中， 我们更强调在各服务之间进行“ 无事务 ”的调用， 而对于数据一致性， 只要求数据在最后的处理状态是 一 致的即可；若在过程中发现错误， 通过补偿机制来进行处理，使得错误数据能够达到最终的 一 致性。
基础设施自动化
近年来云计算服务与容器化技术的不断成熟， 运维基础设施的工作变得越来越容易。但是， 当我们实施微服务架构时， 数据库、 应用程序的个头虽然都变小了， 但是因为拆分的原因， 数量成倍增长。 这使得运维人员需要关注的内容也成倍增长， 并且操作性任务也会成倍增长， 这些问题若没有得到妥善解决， 必将成为运维人员的噩梦。所以， 在微服务架构中， 务必从 一 开始就构建起 “待续交付” 平台来支撑整个实施过程， 该平台需要两大内容， 缺一不可。
• 自动化测试：每次部署前的强心剂， 尽可能地获得对正在运行的软件的信心。
• 自动化部署：解放烦琐枯燥的重复操作以及对多环境的配置管理。
容错设计
在单体应用中，一 般不存在单个组件故障而其他部件还在运行的情况， 通常是 一 挂全挂。 而在微服务架构中， 由于服务都运行在独立的进程中， 所以存在部分服务出现故障，而其他服务正常运行的情况。 比如， 当正常运作的服务B调用到故障服务A时， 因故障服务 A 没有返回， 线程挂起开始等待， 直到超时才能释放， 而此时若触发服务 B 调用服务 A的请求来自服务 C, 而服务 C 频繁调用服务 B 时， 由于其依赖服务 A, 大量线程被挂起等待， 最后导致服务A也不能正常服务， 这时就会出现故障的蔓延。所以， 在微服务架构中， 快速检测出故障源并尽可能地自动恢复服务是必须被设计和考虑的。 通常， 我们都希望在每个服务中实现监控和日志记录的组件， 比如服务状态、 断路器状态、 吞吐量 、 网络延迟等关键数据的仪表盘等。
演进式设计
通过上面的几点特征， 我们已经能够体会到， 要实施 一 个完美的微服务架构， 需要考虑的设计与成本并不小， 对于没有足够经验的团队来说， 甚至要比单体应用付出更多的代价。所以， 在很多情况下， 架构师都会以演进的方式进行系统的构建。 在初期， 以单体系统的方式来设计和实施， 一方面系统体量初期并不会很大， 构建和维护成本都不高。 另一方面， 初期的核心业务在后期通常也不会发生巨大的改变。 随着系统的发展或者业务的需要， 架构师会将 一 些经常变动或是有 一 定时间效应的内容进行微服务处理， 并逐渐将原来在单体系统中多变的模块逐步拆分出来， 而稳定不太变化的模块就形成 一 个核心微服务存
在于整个架构之中。
为什么选择Spring Cloud
近几年很多入对于微服务架构的热情非常高， 但是回头看“ 微服务 ”被提及也有很多年了。 无数的架构师和开发者在实际项目中实践该设计理念并为此付出了诸多努力， 同时也分享了他们在微服务架构中针对不同应用场景出现的各种问题的各种解决方案和开源框架， 其中也不乏国内互联网企业的杰出贡献。
• 服务治理：阿里巴巴开源的Dubbo和当当网在其基础上扩展的DubboX、 Netflix的Eureka、Apache的Consul等。
• 分布式配置管理：百度的Disconf、 Netflix的Archaius、360的QConf、SpringCloud的Config、 淘宝的Diamond等。
• 批量任务：当当网的Elastic-Job、 Linkedln的Azkaban、 SpringCloud的Task等。
• 服务跟踪：京东的Hydra、SpringCloud的Sleuth、Twitter的Zipkin等。
上面列举了 一 些在实施微服务架构初期， 就需要被我们考虑进去的问题， 以及针对这些间题的开源解决方案。 可以看到国内、 国外的技术公司都在贡献着他们的智慧。 我们搜索微服务架构的实施方案时会发现， 几乎大部分的分享主要以理论或是一 个粗轮廓框架为主， 整合了来自不同公司或组织的诸多开源框架， 并加入针对自身业务的 一 些优化， 所以找不到 一 个完全相同的架构方案。
Spring Cloud的出现，可以说是对微服务架构的巨大 支持和强有力的技术后盾。它不像我们之前所列举的框架那样， 只是解决微服务中的某 一 个问题， 而是 一 个解决微服务架构实施的综合性解决框架， 它整合了诸多被广泛实践和证明过的框架作为实施的基础部件，又在该体系基础上创建了 一 些 非常优秀的边缘组件。
打个不太恰当的比喻：我们自己对各个问题选择框架来实施微服务架构就像在DIY电脑 一 样， 我们对各环节的选择自由度很高， 但是最终结果很有可能因为 一 条内存质量不行就点不亮了，总是让人不怎么放心。当然，如果你是 一 名高 手，这些自然都不是问题， 然而千军易得 、 良将难求。而使用Spring Cloud来实施就像直接购买品牌机 一 样，在Spring社区的整合之下， 做了大量的兼容性测试， 保证了其拥有更好的稳定性， 如果要在Spring Cloud架构下使用非原装组件时， 就需要对其基础有足够的了解。
Spring Cloud也许对很多已经实施微服务并自成体系的团队不具备足够的吸引力，但是对于还未实施微服务或是未成体系的团队，这必将是 一 个 非常有吸引力的框架选择。不论其项目的发展目标， 还是 Spring的强大背景， 亦或其极高的社区活跃度，都是未来企业架构师必须了解和接触的重要框架，有 一 天成为微服务架构的标准解决方案也并非不可能。