学习笔记：《微服务架构设计模式》之服务的拆分策略
Posted 海棠依旧€
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了学习笔记：《微服务架构设计模式》之服务的拆分策略相关的知识，希望对你有一定的参考价值。
目录
一、软件架构的定义和视图模型
软件架构的定义：
计算机系统的软件架构是构建这个系统所需要的一组结构，包括软件元素、它们之间的关系以及两者的属性。
软件架构的4 + 1视图模型：
- 逻辑视图:开发人员创建的软件元素。在面向对象的语言中，这些元素是类和包。它们之间的关系是类和包之间的关系，包括继承、关联和依赖。
- 实现视图:构建编译系统的输出。此视图由表示打包代码的模块和组件组成，组件是由一个或多个模块组成的可执行或可部署单元。在Java中，模块是JAR文件，组件通常是WAR文件或可执行JAR文件。它们之间的关系包括模块之间的依赖关系以及组件和模块之间的组合关系。
- 进程视图:运行时的组件。每个元素都是一个进程，进程之间的关系代表进程间通信。
- 部署视图:进程如何映射到机器。此视图中的元素由(物理或虚拟)计算机和进程组成。机器之间的关系代表网络。该视图还描述了进程和机器之间的关系。
二、架构风格
1、分层式架构风格
分层架构将软件元素按层的方式进行组织，每一层只能依赖于下方的层或其下面的任何层。
可以将分层架构应用于前面讨论的四个视图中的任何一个。流行的三层架构是应用于逻辑视图的分层架构。它将应用程序的类组织到以下层中:
- 表现层:包含实现用户界面或外部API的代码。（Controller）
- 业务逻辑层:包含业务逻辑。（Service）
- 数据持久化层:实现与数据库交互的逻辑。（Dao）
Springmvc从大的方面来说，一共有三层。m层：model数据模型层，V:view视图层 C：controller控制层。这是整体上谈的，把控制层往下分，就还可以再分Service层、Dao层、DB层。其中service含有Dao业务逻辑组件，可以通过Dao去操作数据库。
分层架构是架构风格的一个很好的例子，但它确实有些明显的弊端:
- 单个表现层:它无法展现应用程序可能不仅仅由单个系统调用的事实。
- 单一数据持久化层:它无法展现应用程序可能与多个数据库进行交互的事实。
- 将业务逻辑层定义为依赖于数据持久化层:理论上，这样的依赖性会妨碍你在没有数据库的情况下测试业务逻辑。
2、六边形架构
六边形架构是分层架构风格的替代品。如图2-2所示，六边形架构风格选择以业务逻辑为中心的方式组织逻辑视图。应用程序具有一一个或多个人站适配器，而不是表示层，它通过调用业务逻辑来处理来自外部的请求。同样，应用程序具有一个或多个出站适配器，而不是数据持久化层，这些出站适配器由业务逻辑调用并调用外部应用程序。此架构的--个关键特性和优点是业务逻辑不依赖于适配器。相反，各种适配器都依赖业务逻辑。
3、微服务架构是一种架构风格
微服务架构也是一-种架构风格。它的实现视图由多个组件构成:一-组可执行文件或WAR
文件。它的组件是服务，连接器是使这些服务能够协作的通信协议。每个服务都有自己的逻
辑视图架构，通常也是六边形架构。
- 单体架构：将应用程序构建为单个可执行和可部署组件
- 微服务架构：将应用程序构建为松耦合、可独立部署的一组服务
三、为应用程序定义微服务架构
服务的分解有几个障碍需要克服。首先是网络延迟。你可能会发现，由于服务之间的网络往返太多，特定的分解将是不切实际的。分解的另一个障碍是服务之间的同步通信降低了可用性。你可能需要使用第3章中描述的自包含服务的概念。第三个障碍是需要维护跨服务的数据一致性。你需要使用第4章中讨论的Saga。分解的第四个也是最后--个障碍是所谓的上帝类( God Class),它广泛应用在整个应用程序中。幸运的是，你可以使用领域驱动设计中的概念来消除上帝类。
1、识别系统操作
第一步是创建由关键类组成的抽象领域模型，这些关键类提供用于描述系统操作的词汇表。第二步确定系统操作，并根据领域模型描述每个系统操作的行为。系统操作被定义后，下一步就是完成应用服务的识别。
2、根据业务能力进行服务拆分
特殊业务的业务能力取决于这个业务的类型。例如，保险公司业务能力通常包括承保、理赔管理、账务和合规等。在线商店的业务能力包括:订单管理、库存管理和发货，等等。一旦确定了业务能力，就可以为每个能力或相关能力组定义服务。
3、根据子域进行服务拆分
领域模型以解决具体问题的方式包含了一个领域内的知识。DDD把领域模型的边界称为限界上下文( bounded context)。限界上下文包括实现这个模型的代码集合。当使用微服务架构时，每-一个限界上下文对应-一个或者一组服务。换一种说法，我们可以通过DDD的方式定义子域，并把子域对应为每一个服务，这样就完成了微服务架构的设计工作。图2-9展示了子域和服务之间的映射，每-一个子域都有属于它们自己的领域模型。领域驱动设计(DDD)
4、拆分单体应用为服务的难点
- 网络延迟
网络延迟是分布式系统中一直存在的问题。你可能会发现，对服务的特定分解会导致两个服务之间的大量往返调用。有时，你可以通过实施批处理API在一次往返中获取多个对象，从而将延迟减少到可接受的数量。但在其他情况下，解决方案是把多个相关的服务组合在一起，用编程语言的函数调用替换昂贵的进程间通信。
- 同步进程间通信导致可用性降低
另一个需要考虑的问题是如何处理进程间通信而不降低系统的可用性。例如，实现
createOrder ()操作最常见的方式是让Order Service 使用REST同步调用其他服务。这样做的弊端是REST这样的协议会降低Order Service 的可用性。如果任何一个被调用的服务处在不可用的状态，那么订单就无法创建了。有时候这可能是-一个不得已的折中，但是在第3章中学习异步消息之后，你就会发现其实有更好的办法来消除这类同步调用产生的紧耦合并提升可用性。
- 在服务之间维持数据一致性
另一个挑战是如何在某些系统操作需要更新多个服务中的数据时，仍旧维护服务之间的数据一致性。例如，当餐馆接受订单时，必须在Kitchen Service 和Delivery Service中同时进行更新。Kitchen Service 会更改Ticket的状态。Delivery Service 安排订单的交付。这些更新都必须以原子化的方式完成。传统的解决方案是使用基于两阶段提交( two phase commit)的分布式事务管理机制。但正如你将在第4章中看到的那样，对于现今的应用程序而言，这不是一一个好的选择，你必须使用一种非常不同的方法来处理事务管理，这就是Saga。Saga 是一系列使用消息协作的本地事务。Saga 比传统的ACID事务更复杂，但它们在许多情况下都能工作得很好。Saga 的一个限制是它们最终是一致的。如果你需要以原子方式更新某些数据，那么它必须位于单个服务中，这可能是分解的障碍。
- 获取一致的数据视图
分解的另一个障碍是无法跨多个数据库获得真正--致的数据视图。在单体应用程序中，ACID事务的属性保证查询将返回数据库的一致视图。相反，在微服务架构中，即使每个服务的数据库是一致的，你也无法获得全局一致的数据视图。如果你需要一些数据的一致视图，那么它必须驻留在单个服务中，这也是服务分解所面临的问题。幸运的是，在实践中这很少带来真正的问题。
- 上帝类阻碍了拆分
分解的另一个障碍是存在所谓的上帝类。上帝类是在整个应用程序中使用的全局类，上帝类通常为应用程序的许多不同方面实现业务逻辑。它有大量字段映射到具有许多列的数据库表。大多数应用程序至少有一个这样的上帝类，每个类代表一个对领域至关重要的概念:银行账户、电子商务订单、保险政策，等等。因为上帝类将应用程序的许多不同方面的状态和行为捆绑在一起，所以将使用它的任何业务逻辑拆分为服务往往都是一个不可逾越的障碍。
5、定义服务API
定义服务API的起点是将每个系统操作映射到服务。之后确定服务是否需要与其他服务协作以实现系统操作。如果需要协作，我们将确定其他服务必须提供哪些API才能支持协作。
确定支持服务协作所需要的API
有些系统操作跨越多个服务，例如，为了实现creatOrder（）操作，Order Service必须调用其他服务以验证前置条件并使后置条件成立。
四、小结
- 架构决定了软件的各种非功能性因素，比如可维护性、可测试性、可部署性和可扩展性，它们会直接影响开发速度。
- 微服务架构是- -种架构风格，它给应用程序带来了更高的可维护性、可测试性、可部署性和可扩展性。
- 微服务中的服务是根据业务需求进行组织的，按照业务能力或者子域，而不是技术上的考量。
- 有两种分解模式:
- 按业务能力分解，其起源于业务架构。
- 基于领域驱动设计的概念，通过子域进行分解。
- 可以通过应用DDD并为每个服务定义单独的领域模型来消除上帝类，正是上帝类引起了阻碍分解的交织依赖项。
《微服务架构设计模式》读书笔记 | 第2章 服务的拆分策略 #yyds干货盘点#
@[TOC](第2章 服务的拆分策略)
前言
这是一本关于微服务架构设计方面的书，这是本人阅读的学习笔记。首先对一些符号做些说明：
（）为补充，一般是书本里的内容；
[]符号为笔者笔注；
1. 微服务架构到底是什么
1.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应用程序从能力到服务的映射：
2.3.2 根据子域进行服务拆分
一些概念：
- 领域模型：以解决具体问题的方式包含了一个领域的知识；
- DDD通用语言：定义了当前领域相关团队的词汇表，其有两个重要概念：
- 子域：是领域的一部分，识别方式跟识别业务类似；
- 限界上下文：领域模型的边界，通常每一个限界上下文对应一个或一组服务；
拆分步骤：
- 通过DDD的方式定义子域；
- 把子域对应为每一个服务；
- 下图为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 Service中，该服务由其他服务调用用以检索和更新订单（问题在于Order Service将成为一个纯数据服务，成为很少或没有业务逻辑的贫血领域模型）；
- 【推荐】应用DDD将每个服务视为具有自己的领域模型的单独子域，使每个与订单有关的服务都有自己的领域模型及其对应的Order类版本，如下图所示；
2.4 第三步：定义服务API
2.4.1 定义服务API的步骤与事项
- 第一步：把系统操作分配给服务；
- 即确定哪个服务是请求的初始入口点；
- 第二步：确定支持服务协作所需要的API；
- 某些系统操作完全由单个服务处理；也可能分散在多个服务周围。
3. 本章小结
- 架构决定了软件的各种非功能性因素，比如可维护性、可测试性、可部署性和可扩展性，它们会直接影响开发速度；
- 微服务架构是一种架构风格，它给应用程序带来了更高的可维护性、可测试性、可部署性和可扩展性；
- 微服务中的服务是根据业务需求进行组织的，按照业务能力或者子域，而不是技术上的考量；
- 有两种分解模式：
- 按业务能力分解，其起源于业务架构；
- 基于领域驱动设计的概念，通过子域进行分解；
- 可以通过应用DDD并为每个服务定义单独的领域模型来消除上帝类，正是上帝类引起了阻碍分解的交织依赖项。
最后
::: hljs-center
新人制作，如有错误，欢迎指出，感激不尽！
:::
::: hljs-center
欢迎关注公众号，会分享一些更日常的东西！
:::
::: hljs-center
如需转载，请标注出处！
:::
::: hljs-center
:::
以上是关于学习笔记：《微服务架构设计模式》之服务的拆分策略的主要内容，如果未能解决你的问题，请参考以下文章