王东，曾任融数数据北京研发中心 CTO，负责微服务、DevOps 以及大数据平台的研发和管理工作。曾供职于 IBM、普元、Amazon、OneAPM 等国内外知名公司。拥有 15 年以上的 JavaEE 编程和架构设计经验，精通 DevOps 和微服务，曾领导设计和开发普元 ESB 产品。熟悉支付相关的业务流程以及各个银行和支付机构的业务处理模式，熟悉应用与支付领域的大规模分布式系统设计和开发方法，熟悉电子商务行业的业务模型。专注于客户行为分析、营销、产品和服务、客户关系、线上销售、物流配送、渠道整合、供应链集成、售后服务、预测和推荐等各个电子商务主要环节的分析和设计，以及 IT 系统的规划和实施。精通 DDD、Scrum 等软方开发和设计方法论。
9.1 概述
首先，我们来看看微服务的定义：微服务是一个界限明确、高度封装、松耦合、可以独立部署和独立扩展的服务应用组件，如图 9.1 所示。微服务架构基于 SOA 和领域驱动设计（DDD）构建，其主要目的包含以下三个方面：开发的敏捷性、部署的便利性及明确的可扩展性。
其次，微服务和传统的 SOA 有什么异同：
从设计原则上来讲，微服务架构遵循 SOA 的设计原则。
小的、可重用的服务并不一定是微服务，微服务架构强调敏捷、独立开发、独立部署、独立扩展，重用在某种程度上会影响敏捷性。
微服务架构为了实现其敏捷特性，在 SOA 架构约束的基础之上又添加了新的约束，微服务之间不能互相依赖，因此要求微服务能够独立部署、独立扩展，微服务之间的依赖越少越好。
微服务中的一个服务只实现一个独立的特性。
对于微服务而言，尽量不要为外部应用发布代码级 API，可以通过服务调用或者事件解决依赖问题。
微服务中的服务之间最好通过异步事件交互。
微服务中的每个服务都拥有自己独立的数据。
另外，微服务架构的优点有很多：
- 敏捷性：微服务不仅可以提高开发的敏捷性，还可以加速持续部署（CD），从而使开发团队能够尽快部署新的功能。
- 减少风险：由于每个微服务都是比较小巧并且独立部署的，因此可以减少每次部署的风险。
- 适合分布式开发：微服务之间依赖程度低，因此可以更加灵活地独立开发。
- 技术灵活性：微服务之间的耦合程度低，因此技术团队可以根据不同的特点选择最合适的技术栈，例如利用不同的编程语言解决不同的领域问题。
- 可扩展性：一个应用有许多微服务组成，每个微服务可以根据需要独立扩展，而无须对整个应用做整体扩展。
鉴于以上优点，我们来看一下微服务的本质。微服务在本质上是一种服务实现模式，微服务可以实现一个应用中独立的业务功能，而不是整个应用或者模块，因此，微服务其实是将单体应用的复杂性从程序内部转移到了服务组件之间，这就对微服务抽象的粒度有一个比较高的权衡要求。对于微服务的粒度，大家讨论的最多，这也是实践过程中经常遇到的令人纠结的问题。实际上，如果抽象粒度太细，就需要大量的服务编排来满足业务场景，而大量使用服务编排就可能会导致微服务退回到 SOA 模式（服务编排是类似 BPM 或者 ESB 的系统）；而如果服务粒度太粗，则不利于开发的敏捷性和部署的便利性。
微服务的主要目的是实现敏捷，微服务架构的主要构建方式是采用领域驱动设计，而领域驱动设计主要包括如下五个概念：
- Bounded Context
- Context Map
- Event Sourcing
- CQRS
- BASE
微服务的粒度并没有一个明确的界限，也就是说“尺寸”是相对的。通常，微服务的粒度和对敏捷性的要求密切相关，往往粒度越细其敏捷度也越高，但是并不是所有的应用对敏捷的要求都那么高，也就是说在微服务的设计和实现过程中，对于粒度的大小可以做适当的调整。对于想要采用微服务架构的团队，首先要考虑如下几个前提条件：
现有软件架构是否已经服务化或者按照系统功能做了模块化切分。
团队的敏捷成熟度如何，是否有足够的 DevOps 经验。
开发团队是否有足够的架构设计能力来适应采用微服务所带来的设计方法、模式以及技术架构上的巨大差异。
DBA 团队是否有能力和意愿制定新的数据管理模式——将数据管理的方式由原来的集中管理转变为去中心化管理。
运维团队是否有足够的能力为微服务提供全新的环境管理工具、部署工具和监控工具。
综上所述，我们建议微服务的演进线路如图 9.2 所示。
从单体应用或者传统分层架构的应用向服务化过渡，通过封装和组合等方式提供对外发布接口的能力，从而提升应用的可访问性。
通过重构将 Domain-Level（领域层面）的功能模块转变为可以独立部署的服务，从而提升整个应用的敏捷性。我们将这种可独立部署的服务称为 MiniService，其粒度比微服务粗，因而抽象难度比较低，但是也能在一定程度上获得微服务所带来的敏捷性提升的好处，但是对 DevOps 的基础设施等要求没有微服务高，因此建议没有微服务经验的团队可以从 MiniService 开始尝试。
通过 Feature-Level（特性层面）的抽象，根据单一职责原则将 MiniService 拆分成微服务，从而获得更高的扩展性和敏捷性。
