微服务设计模式（系列）-微服务拆分

Posted 2023-02-24 amongdata

软件模式-微服务拆分：按业务能力分解微服务

• 场景
• • 基于业务分解的原则

场景

如果你正准备将你的单体架构（Monolithic architecture）应用改造为微服务架构，并希望使用微服务架构将应用程序构造为一组松耦合的服务。那么第一个要面对的问题就是如何进行服务的拆分。

上图展示了微服务的架构优势，主要包括两方面：

• 简化测试并允许独立部署
• 将工程组织结构化为一组小型（6-10名成员）的自治团队，每个团队负责一个或多个服务

这些好处不会自动得到保证。相反，它们只能通过合理的服务分解为实现。

服务必须足够小，以由小型团队开发并易于测试。单一职责（SRP）是一个非常有用的面向对象设计（OOD）原则。SRP将Class的责任定义为只由一个原因而改更，并且Class仅应该为一个原因而改变。将SRP应用于服务设计以使服务是具有少量紧密相关功能的凝聚体。

还可以以另一种方式分解应用，以保证大多数新需求和更改的需求仅影响单个服务。这是因为影响多个服务的变更需要多个团队之间的协调，这减慢了开发速度。OOD的另一个有用原理是闭包原则（CCP），它指出由于相同原因而更改的类应位于同一包中。例如，也许两个类实现了同一业务规则的不同方面。目的是当该业务规则更改开发人员时，只需要更改少量（理想情况下仅更改）一个程序包中的代码。在设计服务时，这种思路很有意义，因为它将有助于确保每次更改仅影响一项服务。

基于业务分解的原则

• 架构必须稳定
• 服务必须高内聚，单个服务应该实现一小组强相关的功能
• 服务必须符合开闭原则， 即一起的变更应该打包在一起，以确保每次变更只影响单个服务（译者注：这只是理想情况，实际上很多情况我们会影响多个服务）
• 服务间必须松耦合，每个服务作为API封装自己的实现，其实现的变更不会影响到客户端
• 服务必须是易测试的
• 每个服务是足够小以至于可以由“two pizza” team开发完成，即6-10人
• 每个开发团队必须是自治的。每个团队必须可以以最小的协作成本进行开发和部署