微服务拆分的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

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址