[翻译]微服务设计模式 - 3. 按业务功能拆分模式

短命女 2022-11-09 11:20 160阅读 0赞

> 原文地址：https://microservices.io/patterns/decomposition/decompose-by-business-capability.html

# 背景介绍 #

假设你在开发一个大型复杂的微服务架构的应用，微服务架构的目标是将程序设计成一组松耦合的微服务应用，通过持续交付与部署，加速软件开发。

![image][]

微服务架构通过两种方式实现这一点：

1.  简化测试，并且保证组件能够独立部署。
2.  小型的（6-10个人）且自治的团队互相协作完成软件开发，每个小团队负责一个或多个微服务。

但是要想享受这些好处，必须将服务拆分好。微服务要足够的小，以便由一个小团队开发，并且这样更加易于测试。面向对象设计(OOD)的一个重要的指导原则就是**单一职责原则**(SRP)。SRP 将类的职责定义为更改这个类的原因，并规定一个类应该只有一个更改的原因。可以将 SRP 应用于服务设计，来设计更加内聚的服务并实现一小部分**强相关的功能**。

拆分微服务，还需要以一种让大多数新的和需要更改的需求只影响单个服务的方式进行拆分。这是因为影响多个服务的更改需要跨多个团队的协调，这会减缓开发速度。OOD 的另一个有用的原则是**共同封闭原则**(CCP)，它指出，由于同样的原因而改变的类应该在同一个包中。这样，当需求发生变化时，只需要修改少量的代码，理想情况下只有一个包需要改变。这种想法在设计服务时也是有指导意义的，它将有助于确保每个更改只影响一个服务。

# 问题 #

如何将应用程序分解为微服务？

# 考虑因素 #

*  整体架构需要是**稳定的**
 *  微服务必须是**内聚**的，即每个微服务应该实现一小部分强相关的功能
 *  微服务设计需要按照**共同封闭原则**，会一起更改的内容，需要打包成为一个微服务，以确保每次变化只会影响一个微服务。
 *  微服务必须是**松散耦合**的。每个服务都是封装其实现的API，可以在不影响客户端的情况下更改实现。
 *  微服务需要是**可测试的**
 *  每个微服务可以由一个**小团队开发**
 *  每个拥有一个或多个微服务的团队必须是自主的。团队必须能够**独立开发和部署他们的服务**，减少与其他团队的协作成本。

# 解决方案 #

定义与**业务功能相对应**的服务。**业务功能**是业务体系结构建模中的一个概念，一般是指一个为创造价值而做的事情。**业务功能**通常是作用于**业务对象**，例如：

*  **订单管理**负责执行订单相关操作
 *  **用户管理**负责针对用户的操作

# 举例 #

一个线上商店通常包括下面的业务功能：

*  产品目录管理
 *  库存管理
 *  订单管理
 *  交付管理
 *  …

设计对应于这些功能的微服务：

![image][image 1]

# 好处 #

这种模式有以下好处：

*  稳定的体系结构，因为业务功能的划分是相对稳定的。按照业务功能拆分微服务模块也会是稳定的，不会发生一会增加一个微服务，一会去掉一个微服务。
 *  开发团队是跨功能的、自主的，并且是围绕着交付业务价值而不是技术特性而组织起来的。
 *  微服务具有内聚性和松散耦合性。

# 问题 #