微服务数据库拆分原则微服务拆分选择

转载

智能开发先锋 2024-02-23 21:27:05

文章标签 微服务数据库拆分原则设计模式微服务服务拆分模式 文章分类 运维

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

场景

基于业务分解的原则

场景

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

微服务数据库拆分原则微服务拆分选择_设计模式

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

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

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

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

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