微服务实践手册-服务的拆分策略

定义微服务架构

如何定义一个微服务架构？ 不同的人有不同的定义方法，我介绍一种我使用并且效果还不错的定义方法。

第一步定义系统操作，通过将应用程序的需求提炼为各种关键功能。

第二步分解服务，这里会有不同的分解策略，常规使用的一般有两种（按照业务能力定义和围绕领域驱动设计的子域设计）。

第三步 确定每个服务的API及协作方式及流程，因为要与其他服务协作，协作的方式是采用同步调用还是消息的通信机制。

第四步 通过前面三步之后，应用程序的初步服务已经分解出来了，但是仍然会有不足的地方，随着对应用程序领域的了解越来越多，会发现更多的问题，这个时候就需要针对这些问题选择更好的解决方式。例如你可能会发现过多的服务调用可能会导致特定的分解效率低下，导致你必须把一些服务组合在一起。反之，服务可能会越来越复杂，需要将其拆分成多个服务的程度。

1. 识别系统操作

如何识别系统操作，我们都知道在软件开发流程中，起点是来自业务方的需求（包括用户故事或对应的用户场景）。我们使用两步式流程识别和定义系统操作：

• 第一步创建由关键类组成的抽象领域模型，关键类提供用于描述系统操作的词汇。
• 第二步定义系统操作，并根据领域模型描述每个系统操作的行为。

1.1 创建抽象领域模型

创建领域模型会采用一些标准的技术，例如与领域专家沟通后，分析需求和用户场景中频繁出现的名词。例如 Place an order 用户故事，我们可以把它分解为多个用户场景（用户收货地址，订单信息，商品搜索） 。场景中出现的名称，如 Order、User、Product，我们可以将至对应到操作类

• User：下订单的用户
• Order：用户操作的订单
• Product：用户搜索的商品信息

1.2 定义系统操作

系统操作一般分为两类

• 命令型：创建、更新或删除数据的操作
• 查询型：查询和读取数据的操作

2. 定义服务

服务的识别会有多种策略，但是结果都是以业务为中心

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

业务能力是指一些能够为公司产品价值的商业活动或产品。例如 电商公司的业务能力包括：订单管理、库存管理和发货、商品管理等。

• 识别业务能力：一个组织或应用程序有哪些业务能力，是通过对组织的目标、结构分析得来的。每一个业务能力都可以认为是一个或多个服务。以YShop为例，其业务能力分为：订单管理、库存管理、商品管理

• 从业务能力到服务：一旦确定了业务能力，就可以为每个能力或相关能力组定义服务

2.2 根据子域进行服务拆分

todo

3. 定义服务API和协作方式

定义服务的API也就是服务的操作和时间。服务API操作有两种：

• 系统操作：由外部客户端调用，也可能有其他服务调用
• 其他操作：和其他服务之间进行协作

3.1 协作方式

一般的协作方式有REST方式，提供对外API，供其他服务进行HTTP调用。还有通过消息的异步方式进行交互：

• 同步模式：客户端请求需要服务端实时响应，客户端等待影响时可能导致堵塞。
• 异步模式：客户端请求不是阻塞请求，服务端的响应非实时。

4. 持续优化和迭代

在最初的服务拆分完毕之后，随着业务不断的改变和对该领域知识的不断深入，可能会觉得系统有很多可以优化和改进的地方，这个时候需要好好的衡量优化的意义和改进后是否会带来新的问题。对现有业务来说是利大于弊 or 弊大于利，这需要认真思考。另外在服务拆分的时候记住两个主要原则：

• 单一职责原则
• 闭包原则

5. 拆分单体应用未服务的难点

• 网络延迟
• 同步进程间通信导致可用性降低
• 服务之间维持数据一致性
• 获取一致的数据视图

本作品采用《CC 协议》，转载必须注明作者和本文链接