目录
微服务拆分的10条规范
如果你的组织想要采用微服务,那么就需要了解领域驱动设计,事件驱动架构,核心域,子域,有界上下文,反腐层等等,以正确地拆分你的业务逻辑(Business Space)并将其与微服务体系结构(Code Space)映射,这样你就可以获得微服务的好处。
我将在本文中对它们进行总结,并为你在组织中拆分微服务时提供一些指导。
微服务拆分的10条规范
1.使用有界上下文:
使用有界上下文,我们分离数据模型,抽象业务中的共性。每个有界上下文都有自己的业务逻辑。
在进行微服务拆分之前,首先要做的是缩小产品经理与开发人员之间的距离,产品经理可能不了解技术术语,技术团队可能不了解技术术语在业务方面的重要性。他们就像一个葡萄牙语人士与一位英语人士交谈:没有人理解彼此的信息。因此,为了弥补差距,我们需要采取以下步骤:
- 开发人员与产品经理需要讨论:“业务目标是什么?”。“特定功能中的主要角色是什么?” “他们在定义功能时使用了哪些术语?” 在每个步骤上,都要提出更多问题,直到双方达成一致。
- 每个上下文中每个域名实体名称都要是清晰的。
- 为每种上下文定义一种通用语言,以便业务团队和技术团队在交流时可以使用一种通用语言进行交流。
- 从一个粗粒度的有界上下文开始。
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