【Dubbo】微服务架构(二): 如何把应用分解成多个服务

青旅半醒 2022-06-17 20:49 175阅读 0赞

工作中使用了[微服务][Link 1]，接下来的一段时间里，我会写一系列的文章来介绍微服务[架构][Link 2]，同时我也会在github上写一个microservices的应用框架（地址会在后续文章给出）。

[上一篇文章][Link 3]详细说明了单一应用架构与微服务架构各自的优缺点，这篇文章是对

[http://microservices.io/patterns/decomposition/decompose-by-business-capability.html][http_microservices.io_patterns_decomposition_decompose-by-business-capability.html]和 [http://microservices.io/patterns/decomposition/decompose-by-subdomain.html][http_microservices.io_patterns_decomposition_decompose-by-subdomain.html] 的翻译和整理， 内容是讲解如何把应用拆分成服务： 根据业务能力拆分或者根据子域拆分。

# 一、上下文 #

你正在开发一个大型的复杂项目，并且你想要使用微服务架构。微服务架构把应用的结构变成了一系列松耦合的服务。使用微服务架构的目的是通过持续交付、持续部署来加速软件开发的速度。

![20170402123659845][]

微服务架构用两种方式来达到目的：

1.  简化测试，使得组件可以独立部署
2.  把工程师团队分成一个个小的、自主的团队（6到10人），每个团队负责一个或多个服务

这些好处不是自动就能得到的，相反的，它需要我们对服务有一个仔细的划分。

一个服务必须足够小，使得可以被一个小的团队开发和[测试][Link 4]。从面向对象设计那里学到的一个有用的方法是单一职责原则。

应用也要被一种合适的方法拆分，从而大多数新的和修改的需求只影响到单个service。因为影响到多个service的改动需要多个团队之间的合作，这会拖慢开发的速度。另一个面向对象设计的有效原则是共同封闭原则，它是说，因为同一个原因修改的类应该在同一个包中。这种思想在设计服务时也同样有效：每个变化应该只影响一个service。

# 二、问题和强制条件 #

**问题：**

如何把应用拆解成服务？

**强制条件：**

*  架构应该稳定
 *  一个服务应该实现一个强相关的方法的小集合
 *  服务必须遵从共同封闭原则
 *  服务应该松耦合：一个服务的实现的变化不影响调用它的API的客户端
 *  服务应该是可测试的
 *  服务应该足够小，可以被6到10人的小团队开发
 *  每个团队应该是自主的。一个团队可以开发和部署他们的服务，而只需要和别的团队有一些最小的合作

# 三、解决方案 #

## 1.根据业务能力拆分 ##

业务能力是业务架构模型中的一个概念。业务模型经常对应于一个业务对象，比如说：订单管理负责订单，客户管理负责客户。

业务能力经常组织成一个多层等级。比如说，一个企业应用也许有顶级的分类，如产品开发、产品交付、需求挖掘等。

### 示例 ###

一个在线商城的业务能力包括：

*  产品目录管理
 *  存货管理
 *  订单管理
 *  发货管理
 *  …

对应的微服务架构会有一些服务对应于这些业务能力：

![20170402132533051][]

##     ##

### 结果 ###

这种模式有以下好处：

*  架构稳定，因为业务能力相对比较稳定
 *  开发团队是自主的，围绕着交付业务价值而不是技术特性来组织
 *  服务之间共同合作，松耦合

#### 问题 ####

有以下问题需要解决：

*  如何定义业务能力？定义业务能力和服务需要对业务有一个好的理解， 需要对组织的目标、结构、业务流程做一个分析。定义业务能力的好的开始点是：
    
     *  组织结构： 一个组织内的不同组对应于业务能力或者业务能力组
     *  高层领域模型： 业务能力经常对应于领域对象

## 2. 根据子域拆分 ##

定义对应于领域驱动设计（DDD）的子域的服务。 一个领域由多个子域组成。每个子域对应了业务的不同组成部分。

子域可以被这样分类：

*  核心: 业务的核心区分点，应用的最有价值的部分
 *  支持： 与业务是做什么的相关，但不是主要区分点。这个可以自己做或者外包。
 *  通用： 不特定于业务，理想情况下使用现成的软件来实现

### 示例 ###

一个在线商城的子域包括

*  商品目录
 *  存货管理
 *  订单管理
 *  发货管理
 *  …

对应的微服务架构会有一些服务对应于这些子域。

![20170402135519439][]

### 结果 ###

这种模式有以下这些好处：（与上面的方法一样的）

*  架构稳定，因为业务能力相对比较稳定
 *  开发团队是自主的，围绕着交付业务价值而不是技术特性来组织
 *  服务之间共同合作，松耦合

#### 问题 ####

有以下问题需要解决：

*  如何定义子域？定义子域和服务需要对业务有一个好的理解， 需要对组织的目标、结构、业务流程做一个分析。定义子域的好的开始点是：
    
     *  组织结构： 一个组织内的不同组对应于业务能力或者业务能力组
    
     *  高层领域模型： 业务能力经常对应于领域对象

原文来自原 [点击打开链接][Link 5]

[Link 1]: http://lib.csdn.net/base/microservice
[Link 2]: http://lib.csdn.net/base/architecture
[Link 3]: http://blog.csdn.net/u012422829/article/details/68947350
[http_microservices.io_patterns_decomposition_decompose-by-business-capability.html]: http://microservices.io/patterns/decomposition/decompose-by-business-capability.html
[http_microservices.io_patterns_decomposition_decompose-by-subdomain.html]: http://microservices.io/patterns/decomposition/decompose-by-subdomain.html
[20170402123659845]: /images/20220618/0c82c76bb0d148fea3ac5969f8209143.png
[Link 4]: http://lib.csdn.net/base/softwaretest
[20170402132533051]: /images/20220618/4863a68604854eb4a261ab87caa62473.png
[20170402135519439]: /images/20220618/b7f15824aa454b25b34b1842cf840a82.png
[Link 5]: http://blog.csdn.net/u012422829/article/details/68951579