《微服务架构设计模式》第二章 服务的拆分策略

内容总结自《微服务架构设计模式》

一、架构是什么

软件架构的定义：计算机系统的软件架构是构建这个系统所需要的一组结构，包括软件元素、他们之间的关系以及两者的属性（Bass等著）

其实质是应用程续的架构将软件分解为元素（element）和这些元素之间的关系（relation）。由于这两个原因，分解很重要：

1. 它促进了劳动和知识的分工。它使具有特定专业知识的人们（或多个团队）能够就应用程序高效的协同工作
2. 它定义了软件元素的交互方式

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

1. 逻辑视图（开发）：开发人员创建的软件元素。在面向对象的语言中，这些元素是类和包。它们之间的关系是类和包之间的关系，包括继承、关联和依赖。
2. 实现视图（编辑器）：构建编译系统的输出。此视图由表示打包代码的模块和组件组成，组件是由一个或多个模块组成的可执行或可部署单元。在Java中，模块是JAR文件，组件通常是WAR文件或可执行JAR文件。它们之间的关系包括模块之间的依赖关系以及组件和模块之间的组合关系。
3. 进程视图（网络）：运行时的组件。每个元素都是一个进程，进程之间的关系代表进程间通信。
4. 部署视图（部署）：进程如何映射到机器。此视图中的元素由(（物理或虚拟）计算机和进程组成。机器之间的关系代表网络。该视图还描述了进程和机器之间的关系。

为什么重要

应用程序有两个层面的需求。第一类是功能性需求，这些需求决定一个应用程序做什么。这些通常都包含在用例(use case)或者用户故事(user story)中。应用的架构其实跟这些功能性需求没什么关系。功能性需求可以通过任意的架构来实现，甚至是非常糟糕的大泥球架构。

架构的重要性在于，它帮助应用程序满足了第二类需求：非功能性需求。我们把这类需求也称之为质量属性需求，或者简称为“能力”。这些非功能性需求决定一个应用程序在运行时的质量，比如可扩展性和可靠性。它们也决定了开发阶段的质量，包括可维护性、可测试性、可扩展性和可部署性。为应用程序所选择的架构将决定这些质量属性。

分层架构风格

分层架构

架构的典型例子是分层架构。分层架构将软件元素按“层”的方式组织。每个层都有明确定义的职责。分层架构还限制了层之间的依赖关系。每一层只能依赖于紧邻其下方的层(如果严格分层)或其下面的任何层。

可以将分层架构应用于前面讨论的四个视图中的任何一个。流行的三层架构是应用于逻辑视图的分层架构。它将应用程序的类组织到以下层中:

• 表现层：包含实现用户界面或外部API的代码。业务逻辑层:包含业务逻辑。

• 数据持久化层：实现与数据库交互的逻辑。

六边形架构

六边形架构是分层架构风格的替代品。六边形架构风格选择以业务逻辑为中心的方式组织逻辑视图。应用程序具有一个或多个入站适配器，而不是表示层，它通过调用业务逻辑来处理来自外部的请求。同样，应用程序具有一个或多个出站适配器，而不是数据持久化层，这些出站适配器由业务逻辑调用并调用外部应用程序。此架构的一个关键特性和优点是业务逻辑不依赖于适配器。相反，各种适配器都依赖业务逻辑。

---

二、定义微服务

如何定义

我们需要拿到领域专家或者现有应用的需求文档。跟所有的软件开发一样，定义架构也是一项艺术而非技术。定义应用程序架构的三步式流程。但我们也需要名单，世界上没有一个机械化的流程可以遵循，然后指望这个流程输出一个合理的架构。我们只能介绍一个大概的方法，现实世界中，这是一个不断迭代和持续创新的过程。

应用程序是用来处理客户端请求的，因此定义其架构的第一步是将应用程序的需求提炼为各种关键请求。但是，不是根据特定的进程间通信技术(如REST或消息)来描述这些请求，而是使用更抽象的系统操作这个概念。系统操作（system operation)是应用程序必须处理的请求的一种抽象描述。它既可以是更新数据的命令，也可以是检索数据的查询。每个命令的行为都是根据抽象领域模型定义的，抽象领域模型也是从需求中派生出来的。系统操作是描述服务之间协作方式的架构场景。

该流程的第二步是确定如何分解服务。有几种策略可供选择。一种源于业务架构学派的策略是定义与业务能力相对应的服务。另一种策略是围绕领域驱动设计的子域来分解和设计服务。但这些策略的最终结果都是围绕业务概念而非技术概念分解和设计的服务。

定义应用程序架构的第三步是确定每个服务的API。为此，你将第一步中标识的每个系统操作分配给服务。服务可以完全独立地实现操作。或者，它可能需要与其他服务协作。在这种情况下，你可以确定服务的协作方式，这通常需要服务来支持其他操作。你还需要确定选用第3章中描述的哪种进程间通信机制来实现每个服务的API。
定义应用程序架构的第三步是确定每个服务的API.为此，你将第一步中标识的每个系统操作分配给服务.服务可以完全独立地实现操作.或者，它可能需要与其他服务协作.在这种情况下，你可以确定服务的协作方式，这通常需要服务来支持其他操作.你还需要确定选用第3章中描述的哪种进程间通信机制来实现每个服务的API.

1、根据业务能力分

业务能力是一个来自于业务架构建模的术语。业务能力是指一些能够为公司(或组织)产生价值的商业活动。特定业务的业务能力取决于这个业务的类型。例如，保险公司业务能力通常包括承保、理赔管理、账务和合规等。在线商店的业务能力包括：订单管理、库存管理和发货，等等。

2、根据子域进行服务拆分

Eric Evans在他的经典著作中(Addison-Wesley Professional，2003 )提出的领域驱动设计是构建复杂软件的方法论，这些软件通常都以面向对象和领域模型为核心。领域模型以解决具体问题的方式包含了一个领域内的知识。它定义了当前领域相关团队的词汇表，DDD也称之为通用语言(Ubiquitous language)。落地到具体开发则借助DDD的战略设计和战术设计进行软件设计

服务拆分难点

1. 网络延迟：性能问题
2. 同步进程间通信导致可用性降低：服务可用性问题
3. 在服务之间维持数据一致性：分布式事务问题
4. 获取一致的数据视图：不同服务之间数据的隔离性问题
5. 上帝类阻碍拆分：类属性耦合严重问题

定义服务API

1. 把系统操作分配给服务：划定操作划定到具体的服务域

2. 确定支持服务协作所需要的API：细化需求到底需要哪些能力