前言

这是一本关于微服务架构设计方面的书，这是本人阅读的学习笔记。首先对一些符号做些说明：

（）为补充，一般是书本里的内容；
[]符号为笔者笔注；

---

1. 微服务架构到底是什么

1.1 软件架构的4+1视图

软件架构的4+1视图模型

1.2 应用程序的两个层面需求

• 功能性需求；
• 非功能性需求，又称质量属性需求。（包括可扩展性、可靠性、可维护性、可测试性与可部署性等）[这点是架构为什么重要的原因]

1.3 分层式架构风格

流行的三层架构是应用于逻辑视图的分层架构，如下：

• 表现层：包含实现用户界面或外部API的代码；
• 业务逻辑层：包含业务逻辑；
• 数据持久层：实现与数据库交互的逻辑；

其弊端是：

• 单个表现层：无法展现应用程序可能不仅仅由单个系统调用的事实；
• 单一数据持久化层：无法展示应用程序可能与多个数据库进行交互的事实；
• 将业务逻辑层定义为依赖于数据持久化层：理论上，这样是依赖会妨碍在没有数据库的情况下测试业务逻辑；

1.4 关于架构风格的六边形

六边形架构是分层架构风格的替代品 [解决分层架构的弊端]，六边形架构选择以业务逻辑为中心的方式组织逻辑视图。

六边形架构

图解：

• 业务逻辑具有一个或多个端口，端口定义了一组操作，关于业务逻辑如何与外部交互。
• 有两种端口：入站端口与出站端口；
  • 入站端口是业务逻辑公开的API（如服务接口等，外部可以访问）；
  • 出站端口是业务逻辑调用外部系统的方式（如储存库接口，定义数据访问操作的集合）；
• 业务逻辑周围是适配器，有两种适配器：入站适配器与出站适配器；
  • 入站适配器：通过调用入站端口处理外部请求（如Spring MVC Controller，实现REST接口或一组Web界面）；
  • 出站适配器：通过调用外部应用程序或服务处理来自业务逻辑的请求（如实现数据访问对象DAO类）；

好处：

• 将业务逻辑与适配器中包含的表示层和数据访问层的逻辑分离开，使单独测试业务逻辑容易；
• 反映现代应用程序的架构；

1.5 什么是服务

服务是一个单一的、可独立部署的软件组件，它实现了一些有用的功能。

服务的外部视图

图解：

• 服务具有API，为客户端提供对功能的访问；
• API由命令、查询和事件组成；
• 开发人员无法绕过API直接访问服务内部的方法或数据（松耦合）；

1.6 微服务架构的架构风格

• 它实现的视图由多个组件构成；
• 组件是服务，连接器是使这些服务能够协作的通信协议；
• 松耦合；
• 共享类库（里面实现不太可能改变的功能）；
• 服务大小不重要；

2 为应用程序定义微服务架构

定义架构是一项艺术而非技术；在现实世界中，这是一个不断迭代和持续创新的过程。

2.1 定义应用程序架构的三步式流程

定义应用程序架构的三步式流程

• 第一步：识别系统操作；
• 第二步：定义服务；
• 第三步：定义服务API；

2.2 第一步：识别系统操作

抽象的领域模型与系统操作能够回答这个应用“做什么”这一问题，有助于推动应用程序的架构设计。

识别系统操作

2.2.1 识别系统操作的步骤与一些事项：

• 第一步：创建抽象领域模型；
  • 可以通过分析用户故事和场景中频繁出现的名词，经过迭代分析为这个领域模型的一些类；
• 第二步：定义系统操作；
  • 识别系统必须的各种请求， 通常有两种：
    • 命令型：创建、更新或删除数据的系统操作；
    • 查询型：查询和读取数据的系统操作；
  • 系统操作的切入点在分析用户故事和场景中频繁出现的动词；
  • 需要考虑命令规范（参数、返回值和领域模型类）与行为规范（前置条件、后置条件）；

2.3 第二步：定义服务

2.3.1 根据业务能力进行服务拆分

拆分步骤：

• 首先要确定业务能力，通常指这个组织的业务是做什么，可以通过对组织的目标、结构和商业化流程分析得来；
• 确定了业务能力后，就可以为每个能力组定义服务，这是一个非常主观的判断；

• 下图为FTGO应用程序从能力到服务的映射：

  
  FTGO应用程序从能力到服务的映射

2.3.2 根据子域进行服务拆分

又称：基于领域驱动设计分解应用程序的方法

一些概念：

• 领域模型：以解决具体问题的方式包含了一个领域的知识；
• DDD通用语言：定义了当前领域相关团队的词汇表，其有两个重要概念：
  • 子域：是领域的一部分，识别方式跟识别业务类似；
  • 限界上下文：领域模型的边界，通常每一个限界上下文对应一个或一组服务；

拆分步骤：

• 通过DDD的方式定义子域；
• 把子域对应为每一个服务；
• 下图为FTGO应用程序从子域到服务的映射：

FTGO应用程序从子域到服务的映射

2.3.3 拆分的指导原则

受启发于面型对象设计原则。

• 单一职责原则：定义的每一个类都应该只有一个职责；
• 闭包原则：如果出于某种原因，两个类的修改必须耦合先后发生，那么就应该把它们放在同一个包内；

2.3.4 拆分单体应用为服务的难点

• 网络延迟：
  • 描述：对服务的特定分解导致两个服务之间的大量往返调用；
  • 解决：把多个相关服务组合在一起，用编程语言的函数调用替换进程间通信；或者实施批处理API在一次往返中获取多个对象；
• 同步进程间通信导致可用性降低：
  • 描述：使用REST协议同步调用其他服务时，会降低service的可用性；
  • 解决：参考《第三章 异步消息》；
• 在服务之间维护数据一致性：
  • 描述：当一个系统操作需要修改多个服务的数据时，需要维护数据的一致性；
  • 解决：参考《第四章 Saga相关》；
• 获取一致的数据视图：
  • 描述：无法跨多个数据库获得真正一致的数据视图；
  • 解决：（在实践中很少带来真正的问题）；
• 上帝类阻碍了拆分：
  • 描述：上帝类是在整个应用程序中使用的全局类，通常与多个服务的状态与行为绑定；
  • 解决：参考本章《2.3.5 上帝类阻碍了拆分》，以FTGO的Order类为例；

2.3.5 上帝类阻碍了拆分

在定义微服务架构时，必须识别并消除上帝类。

问题描述：在FTGO应用程序中，Order类与订单处理、餐馆订单管理、送餐与付款等服务有关，具有复杂的状态模型，如下图所示；

Order上帝类

解决方法：

• 将Order类打包到库中并创建一个中央Order数据库（违反松耦合原则）；
• 将Order数据库封装在Order Service中，该服务由其他服务调用用以检索和更新订单（问题在于Order Service将成为一个纯数据服务，成为很少或没有业务逻辑的贫血领域模型）；
• 【推荐】应用DDD将每个服务视为具有自己的领域模型的单独子域，使每个与订单有关的服务都有自己的领域模型及其对应的Order类版本，如下图所示；

Delivery Service的领域模型
Kitchen Service的领域模型 Order Service的领域模型

2.4 第三步：定义服务API

2.4.1 定义服务API的步骤与事项

• 第一步：把系统操作分配给服务；
  • 即确定哪个服务是请求的初始入口点；
• 第二步：确定支持服务协作所需要的API；
  • 某些系统操作完全由单个服务处理；也可能分散在多个服务周围。

3. 本章小结

• 架构决定了软件的各种非功能性因素，比如可维护性、可测试性、可部署性和可扩展性，它们会直接影响开发速度；
• 微服务架构是一种架构风格，它给应用程序带来了更高的可维护性、可测试性、可部署性和可扩展性；
• 微服务中的服务是根据业务需求进行组织的，按照业务能力或者子域，而不是技术上的考量；
• 有两种分解模式：
  • 按业务能力分解，其起源于业务架构；
  • 基于领域驱动设计的概念，通过子域进行分解；
• 可以通过应用DDD并为每个服务定义单独的领域模型来消除上帝类，正是上帝类引起了阻碍分解的交织依赖项。

---

最后