微服务拆分的10条规范

本文涉及的产品
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 微服务拆分的10条规范

目录

微服务拆分的10条规范

1.使用有界上下文:

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

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

4.考虑支持领域:

5.引入反腐层:

6.识别数据通信模式:

7.引入事件驱动架构(EDA):

8.使API简洁明了:

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

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

结论



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



目录
相关文章
|
5月前
|
Java API 微服务
【Spring Boot系列】通过OpenAPI规范构建微服务服务接口
【4月更文挑战第5天】通过OpenAPI接口构建Spring Boot服务RestAPI接口
220 0
|
3月前
|
SQL 数据库 微服务
微服务03,最简单的Demo,我们每个服务不能重复开发相同业务,微服务数据独立,不要访问其他微服务的数据库,微服务的特点之一是提供不能功能的数据库互相分割,微服务需要根据业务模块拆分,做到单一职责,
微服务03,最简单的Demo,我们每个服务不能重复开发相同业务,微服务数据独立,不要访问其他微服务的数据库,微服务的特点之一是提供不能功能的数据库互相分割,微服务需要根据业务模块拆分,做到单一职责,
|
2月前
|
消息中间件 监控 Java
解锁Spring Cloud微服务架构的奥秘:深度剖析拆分原则,打造高内聚低耦合的业务创新引擎!
【8月更文挑战第3天】踏入微服务领域,Spring Cloud以丰富组件助力高效系统构建。微服务拆分需遵循原则确保系统高内聚低耦合且能适应变化。首要原则为单一职责,每个服务专注一个业务功能,降低复杂度并提高可维护性。其次,追求高内聚低耦合以减少服务间影响。围绕业务域拆分有助于保持逻辑清晰及团队协作。处理数据一致性问题时,考虑采用最终一致性模型。Spring Cloud提供Eureka、Zuul/Gateway、Sleuth和Config等工具支持服务发现、路由、跟踪及配置管理,共同构建灵活健壮的微服务架构。
66 2
|
2月前
|
敏捷开发 数据库 微服务
SpringCloud微服务拆分原则
SpringCloud微服务拆分原则
48 2
|
3月前
|
敏捷开发 运维 监控
微服务将大型应用拆分成小型自治服务,每个服务专注单一功能,独立部署。
【7月更文挑战第2天】微服务将大型应用拆分成小型自治服务,每个服务专注单一功能,独立部署。起源于对单体架构局限性的应对,它促进了敏捷开发、技术多样性及高可伸缩性。但同时也增加了系统复杂度、数据一致性和运维挑战。实施涉及服务划分、技术选型、CI/CD及监控。Netflix、Uber和Spotify的成功案例展示了微服务在应对高并发和快速迭代中的价值。尽管挑战重重,微服务仍是构建现代应用的关键。
125 2
|
3月前
|
监控 Java API
Java面试题:解释微服务架构的概念及其优缺点,讨论微服务拆分的原则。
Java面试题:解释微服务架构的概念及其优缺点,讨论微服务拆分的原则。
68 0
|
3月前
|
缓存 Devops 微服务
微服务01好处,随着代码越多耦合度越多,升级维护困难,微服务技术栈,异步通信技术,缓存技术,DevOps技术,搜索技术,单体架构,分布式架构将业务功能进行拆分,部署时费劲,集连失败如何解决
微服务01好处,随着代码越多耦合度越多,升级维护困难,微服务技术栈,异步通信技术,缓存技术,DevOps技术,搜索技术,单体架构,分布式架构将业务功能进行拆分,部署时费劲,集连失败如何解决
|
4月前
|
敏捷开发 缓存 算法
从数据闭环谈微服务拆分
从数据闭环谈微服务拆分
|
5月前
|
敏捷开发 运维 监控
【专栏】微服务架构,以敏捷、灵活著称,通过拆分大型应用为小型自治服务,简化开发运维
【4月更文挑战第27天】微服务架构,以敏捷、灵活著称,通过拆分大型应用为小型自治服务,简化开发运维。本文探讨其基本概念、起源,核心优势(如敏捷开发、高可伸缩性)及挑战(系统复杂度、数据一致性),并分享实施策略(服务划分、技术选型、CI/CD)与实践案例(Netflix、Uber、Spotify),展示微服务如何重塑软件开发,并成为未来复杂应用系统的基础。
131 1
|
5月前
|
运维 监控 数据处理