微服务如何划分

方丈的寺院

发布于 2022-04-12 05:56:34

1.3K0

摘要

作为团队架构师/技术负责人你该如何进行微服务的划分呢?在以前的文章中讨论过这个话题，可落地的DDD(4)-如何利用DDD进行微服务的划分(2)[1]，最近结合在不同的开发团队实践，又有了新的思考，相比较之前的基于DDD会更加全面可落地，也欢迎大家留言讨论。

为何要划分微服务

微服务架构被广泛用于互联网公司，其优势在于每个服务足够小，相互之间具备隔离性。配合一些基础设施，能够使得需求快速迭代上线。但是每个服务的粒度应该多大呢，服务之间的关系应该是怎样的呢?

首先我们来探讨一下微服务划分的目标。微服务划分涉及到两个对象，一个是微服务，一个是开发人员。所以目标是高效有序将微服务及开发人员组织起来。

如何衡量有序呢?

1.职责清晰2.相互间的依赖关系清晰一个无序的微服务调用，会陷入混乱地狱。

因此制定一些标准

横向：按照业务流程拆，业务流程反映的是数据流程，数据从上游流下下游。上游需要和下游解耦，上游不可通过服务间调用下游。下游可以。

纵向：按照技术拆分，由上到下分为4层，上层可以调用下层，同级可以相互调用，下层强制不能调用上层。

1.应用系统面向各个端，比如pc端，面向用户的，面向小二的。app端。属于前端应用。

2.核心领域整个系统的核心业务，与业务紧密相连。支撑业务发展。

3.基础能力从核心领域中下沉抽象出来的更通用的服务，不只是服务当前业务。也服务于公司其他业务。

4.依赖系统一些通用的公共模块以及与其他兄弟部门的服务依赖。

如此调用关系比较清晰了。

如何衡量高效呢？

对于服务是性能高且稳定对于开发人员是效率高且有技术成长空间

业务量上来一个，后端的很多工作就是围绕着性能和稳定，微服务的划分也深深影响着。因此服务划分还会按照

1.基于迭代频次变更是引发故障的主要原因，因此如果一个服务是稳定的，我们可以把他单独拆分为一个微服务，这样在项目快速迭代时，不会影响已有功能。不需要投入太多回归测试时间。

2. 基于可靠性核心服务需要重点保障，流量高的应用和流量低的应用稳定性要求也不一样。可以将核心服务，流量高的应用单独拆出来，这样使得核心服务功能逻辑简单，依赖减少，存储独立。稳定性得到极大保障。

3.基于开发人员架构活动不仅要关心机器，还要关心人。开发人员的工作效率极大影响了业务的交付速度和质量。一个微服务需要一个唯一owner和2-3个开发人员(owner也参与开发)。owner是第一责任人，负责整个应用的代码质量，服务稳定性。2-3个人负责开发一个系统，不会有单点，在人员流动的情况能够进行相互补位，同时相互之间可以进行技术方案深度讨论，能够应对一定级别的复杂需求。人数不宜超过4个人，人太多，在同一个应用中开发不同的需求，可能每天都要处理不同的分支之间冲突，多套环境进行测试，效率比较低。同时人数太多，讨论效率也比较低。此外需要尽量保证每个中高级别的开发者都是一个微服务的owner，有自己的一块自留地，在需求承接之外，能够在做一些技术相关的开发工作。

当然高效和有序并不总是统一的，有时候我们需要去做架构取舍。