前言
这是一本关于微服务架构设计方面的书，这是本人阅读的学习笔记。首先对一些符号做些说明：
（）为补充，一般是书本里的内容；
[]符号为笔者笔注；
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并为每个服务定义单独的领域模型来消除上帝类，正是上帝类引起了阻碍分解的交织依赖项。
