微服务拆分的10条规范

如果你的组织想要采用微服务，那么就需要了解领域驱动设计，事件驱动架构，核心域，子域，有界上下文，反腐层等等，以正确地拆分你的业务逻辑（Business Space）并将其与微服务体系结构（Code Space）映射，这样你就可以获得微服务的好处。

我将在本文中对它们进行总结，并为你在组织中拆分微服务时提供一些指导。

微服务拆分的10条规范

1.使用有界上下文：

使用有界上下文，我们分离数据模型，抽象业务中的共性。每个有界上下文都有自己的业务逻辑。

在进行微服务拆分之前，首先要做的是缩小产品经理与开发人员之间的距离，产品经理可能不了解技术术语，技术团队可能不了解技术术语在业务方面的重要性。他们就像一个葡萄牙语人士与一位英语人士交谈：没有人理解彼此的信息。因此，为了弥补差距，我们需要采取以下步骤：

1. 开发人员与产品经理需要讨论：“业务目标是什么？”。“特定功能中的主要角色是什么？” “他们在定义功能时使用了哪些术语？” 在每个步骤上，都要提出更多问题，直到双方达成一致。
2. 每个上下文中每个域名实体名称都要是清晰的。
3. 为每种上下文定义一种通用语言，以便业务团队和技术团队在交流时可以使用一种通用语言进行交流。
4. 从一个粗粒度的有界上下文开始。

2.确定核心域并保持竞争优势：

核心域是为你的业务带来收益的领域。对于在线购物而言，购物车模块是核心领域，它为从企业到消费者（B2C）提供了平台。了解你的核心模块，并思考如何改进竞争对手没有的功能。

任何自动化或创新都会提高优势并增加你的收入，因此请注意，要在核心领域进行研发和投资，以保持竞争优势。

3.对通用域进行成本优化：

通用域就是该领域中每个企业所共有的领域，并且不同的第三方厂商已经提供了解决方案。像你的信息通知模块或广告活动模块，建议不要花钱来重新发明轮子，最好以便宜的价格采用第三方解决方案。

4.考虑支持领域：

核心域需要支持域的帮助来丰富自身功能，甚至在某些情况下，支持域也可以带来收益，并且将来有可能成为核心域。例如，在购物车域中，库存管理是支持领域，但投资研发-识别客户订单最近库存位置的算法，对降低运输成本也很重要。

5.引入反腐层：

反腐层（Anti-corruption layer，简称 ACL）介于新应用和旧应用之间，用于确保新应用的设计不受老应用的限制。是一种在不同应用间转换的机制。

创建一个反腐层，以根据客户端自己的域模型为客户提供功能。该层通过其现有接口与另一个系统进行通信，几乎不需要对其进行任何修改。因此，反腐层隔离不仅是为了保护你的系统免受异常代码的侵害，还在于分离不同的域并确保它们在将来保持分离。

反腐层是将一个域映射到另一个域，这样使用第二个域的服务就不必被第一个域的概念“破坏”。

实际上，我们经常遇到基于大型机或任何其他语言构建的旧系统，但无法拆分该系统，并且还需要使用旧应用的数据。因此，在旧应用和微服务通信之间创建反腐层是一个好主意。

还要考虑通用领域，因为他们是不受开发团队控制的任何外部系统(第三方系统)，因此也需要引入一个反腐层，该层将微服务与外部AP隔离开来，充当微服务和第三方之间的翻译者。它还可以帮助你将来采用任何第三方库。

6.识别数据通信模式：

一旦基于功能拆分了微服务，并且每个核心服务封装了它们自己的数据库，接下来就要考虑不同微服务间是如何通信的？是同步的？还是异步的？例如，对于一些系统，用户可以执行部分功能并创建中间状态，另一个系统对中间状态采取措施并回调或通知用户。

7.引入事件驱动架构（EDA）：

在实际的应用程序中，你的业务案例具有复杂的工作流，并且根据数据的状态在工作流上具有许多分支。如果你考虑通过Rest API公开所有内容，则会看到它创建了一个复杂的通信网络。

因此，我们需要一个干净的架构，其中每个微服务都可以独立运行而不会产生耦合，这里事件驱动的架构起着至关重要的作用，每个事件都包裹着状态的变化，并且微服务遵循发布订阅(pub/sub) 模型，因此一个微服务会发布以事件的形式包装的数据，其他微服务会侦听该事件。由于事件是不可变的，因此它也保存实体或聚合器的历史记录。

8.使API简洁明了：

在微服务中，在发布API时，请确保你的API不发布内部状态。发布API是一种使其他服务可以获取足够的信息以继续其流程的方式，因此要虑封装和网络调用，不应多次返回以获取派生信息。还要考虑事件，应该发布哪些事件以及哪些事件必须保留在内部。也许你可以发布一个粗粒度事件，而不是发布一个个内部的小事件。

例如，你有地址更改事件和个人信息更改事件。最好是发布一个名为CustomerUpdateEvent的粗粒度事件，而不是提供两个独立的事件。

9.将相关的微服务合并为更大的服务：

拆分之后，当需要添加或更新功能时，你会遇到一些微服务总是一起变化的情况。这时候，你应该知道你已经以错误的方式拆分了它。它们一定不能被隔离到一个小型服务中，它们是同一逻辑单元的一部分。因此，将它们合并为一个服务是明智的，将减少不必要的网络通信。

10. 引入无缝开发支持工具：

微服务不是免费的午餐。如果你采用微服务，那么首先要做好准备，因为微服务是分布式的，因此要投资一些软件工具，以此来扩展弹性和提高可用性，并缩短产品投产时间，帮助尽早发现故障等。

因此，请花钱在CI / CD流水线上，采用云基础架构，使用跟踪工具，使用日志聚合器来搜索日志，使用混沌工程测试你的系统，等等。

结论

拆分微服务时，以上几点是必要的。我将针对每个主题写一篇文章，介绍它们如何在采用微服务体系结构中发挥关键作用。另外，我想听听你在拆分微服务时所面临的挑战。

译文链接: https://dzone.com/articles/10-commandments-on-microservice-decomposition