· 服务治理：这是Spring Cloud的核心。目前Spring Cloud主要通过整合Netflix的相关产品来实现这方面的功能（Spring Cloud Netflix），包括用于服务注册和发现的Eureka，调用断路器Hystrix，调用端负载均衡Ribbon，Rest客户端Feign，智能服务路由Zuul，用于监控数据收集和展示的Spectator、Servo、Atlas，用于配置读取的Archaius和提供Controller层Reactive封装的RxJava。
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章 Microservices， 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务，和我最近几年工作的实践比较相关感觉深受启发。本文吸收了部分原文观点，结合自身实践经验来探讨下服务架构模式的演化。
面向服务架构 SOA 思想概念的提出已不是什么新鲜事，大概在10年前就有不少相关书籍介绍过。当时 java 企业应用领域 J2EE 依然是主流，应用程序被部署在庞大统一的符合 J2EE 规范的容器中运行，在单一进程中提供所有的功能。 而 SOA 提出的一些架构原则，在当时看来无疑是革命性的。 由于业已存在的大量单一庞大的应用，按照 SOA 的思想和架构原则来改造无疑相当于推翻重新开发一遍，在成本上很难接受。 因此早期的 SOA 通常和另外一个术语关联在一起——ESB（企业服务总线）。 当时在 SOA 的实施思路上无一例外的选择了 ESB 模式来整合集成大量单一庞大的应用，以保护企业前期投入成本。因此 ESB 其实是 SOA 特定历史阶段的一种实现方式。
然而，愿望总是美好的，现实却要残酷的多。过去这些年我们看到了很多实施 ESB 搞砸了的项目，投入几百万，产出几乎为 0，因此 SOA 这个概念也蒙上了不详的标签。 近几年流行起来的服务化架构，其拥护者开始拒绝使用包裹着失败阴影的 SOA 这个标签，而称其为微服务架构（Microservices Architecture Style）。但事实上 微服务架构依然是 SOA 架构思想的一种实现。
对微服务架构我们没有一个明确的定义，但简单来说微服务架构是：
采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。
1. 通过服务实现组件化
传统实现组件的方式是通过库（library），传统组件是和应用一起运行在进程中，组件的局部变化意味着整个应用的重新部署。 通过服务来实现组件，意味着将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需重新部署对应的服务进程。
另外将服务作为组件可以更明确的定义出组件的边界，因为服务之间的调用是跨进程的，清晰的边界和职责定义是设计时必须考虑的。
2. 按业务能力来划分服务与组织团队
康威定律（Conway's law）指出：
organizations which design
systems ... are constrained to produce designs which are copies of the
communication structures of these organizations.
任何设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。
传统开发方式中，我们将工程师按技能专长分层为前端层、中间层、数据层，前端对应的角色为UI、页面构建师等，中间层对应的角色为服务端业务开发工程师，数据层对应着DBA等角色。 事实上传统应用设计架构的分层结构正反应了不同角色的沟通结构。 而微服务架构的开发模式不同于传统方式，它将应用按业务能力来划分为不同的服务，每个服务都要求在对应业务领域的全栈（从前端到后端）软件实现，从界面到数据存储到外部沟通协作等等。 因此团队的组织是跨功能的，包含实现业务所需的全面的技能。 近年兴起的全栈工程师正是因为架构和开发模式的转变而出现，当然具备全栈的工程师其实很少，但将不同领域的工程师组织为一个全栈的团队就容易的多。
3. 服务即产品
传统的应用开发都是基于项目模式的，开发团队根据一堆功能列表开发出一个软件应用并交付给客户后，该软件应用就进入维护模式，由另一个维护团队负责，开发团队的职责结束。
而微服务架构的倡导者提议避免采用这种项目模式，更倾向于让开发团队负责整个产品的全部生命周期。Amazon 对此提出了一个观点：
You buidl it, you run it.
开发团队对软件在生产环境的运行负全部责任，让服务的开发者与服务的使用者（客户）形成每天的交流反馈，来自直接客户端的反馈有助于开发者提升服务的质量。
4. 智能终端与哑管道
微服务架构抛弃了 ESB 过度复杂的业务规则编排、消息路由等。 服务作为智能终端，所有的业务智能逻辑在服务内部处理，而服务间的通信尽可能的轻量化，不添加任何额外的业务规则。
5. 去中心统一化
传统应用中倾向采用统一的技术平台或产品来解决所有问题。
不是每个问题都是钉子，也不是每个解决方案都是一个锤子。 问题有其具体性，解决方案也应有其针对性。 用最适合的技术方案去解决具体的问题，在大一统的传统应用中其实很难做到，而微服务的架构意味着，你可以针对不同的业务服务特征选择不同的技术平台或产品，有针对性的解决具体的业务问题。
6. 基础设施自动化
单一进程的传统应用被拆分为一系列的多进程服务后，意味着开发、调试、测试、集成、监控和发布的复杂度都会相应增大。
必须要有合适的自动化基础设施来支持微服务架构模式，否则开发、运维成本将大大增加。
7.
Design for failure
正因为将服务独立在不同的进程中后，引入了额外的失败因素。
任何时刻对服务的调用都可能因为服务方不可用导致失败，这就要求服务的消费方需要优雅的处理此类错误。 这其实是相对传统应用开发方式的一个缺点，不过随着一些开源服务化框架的出现，对业务开发人员而言适当的屏蔽了类似的错误处理，不过开发人员依然需要知道对服务的调用是完全不同于进程内的方法或函数调用的。
8. 进化设计
一旦采用了微服务架构模式，那么在服务需要变更时我们要特别小心，服务提供者的变更可能引发服务消费者的兼容性破坏，时刻谨记保持服务契约（接口）的兼容性。
对于解耦服务消费方和服务提供方，伯斯塔尔法则（Postel's law）特别适用：
Be conservative in what you send,
be liberal in what you accept.
发送时要保守，接收时要开放。
按照伯斯塔尔法则的思想来设计实现服务调用时，发送的数据要更保守，意味着最小化的传送必要的信息，接收时更开放意味着要最大限度的容忍信息的兼容性。 多余的信息不认识可以忽略，而不应该拒绝或抛出错误。
采用微服务架构面临的第一个问题就是如何将一个单一应用拆分为多个服务。 有一个一般的原则是，单一服务提供的功能是可以独立被替换和升级的。 也就是说如果有 A 和 B 两个功能，如果 A 功能发生变化时同时 B 功能也需要变化，那么 A 和 B 这两个功能应该被划在一个服务中。
微服务架构应用的成功经验近年已越来越多，例如国外的 Amazon，Netflix，国内如阿里都采用微服务架构取得了很多正面的成功案例。 但通过上文所述微服务架构特征看出，其实微服务架构模式有利有弊，需要根据实际的业务、团队、环境进行仔细权衡利弊。 其中的服务拆分带来的额外开发、测试、运维、监控的复杂度，在现有的环境、团队下是否能够很好的支持。
另外，有人可能会说，我一开始不采用微服务架构方式，而是在单一进程内基于清晰定义的模块化方式，模块之间通过接口调用，到了适当阶段，必要的时候再将模块拆分为服务。 其实这个想法显得过于理想，因为进程内良好定义的接口通常不是很好的服务化接口。 一开始没有考虑服务化的设计方法，那么后期拆分时依然是一个痛苦的过程。
正如，Martin Fowler 在其文中所说，微服务架构是否就是企业应用开发的未来，还有待时间的检验。 就目前的情况看，对此我们可以保持谨慎的乐观，这条路依然值得去探索。 实际任何的架构决策都是基于我们不完美的现状做出的，这正是架构取舍的微妙之处，超越任何的方法论。