微服务如何划分

Posted 2022-07-29 方丈的寺院

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务如何划分相关的知识，希望对你有一定的参考价值。

摘要

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

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

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

如何衡量有序呢?

因此制定一些标准

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

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

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

如何衡量高效呢？

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

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

基于迭代频次
变更是引发故障的主要原因，因此如果一个服务是稳定的，我们可以把他单独拆分为一个微服务，这样在项目快速迭代时，不会影响已有功能。不需要投入太多回归测试时间。
基于可靠性
核心服务需要重点保障，流量高的应用和流量低的应用稳定性要求也不一样。
可以将核心服务，流量高的应用单独拆出来，这样使得核心服务功能逻辑简单，依赖减少，存储独立。稳定性得到极大保障。
基于开发人员
架构活动不仅要关心机器，还要关心人。开发人员的工作效率极大影响了业务的交付速度和质量。
一个微服务需要一个唯一owner和2-3个开发人员(owner也参与开发)。owner是第一责任人，负责整个应用的代码质量，服务稳定性。2-3个人负责开发一个系统，不会有单点，在人员流动的情况能够进行相互补位，同时相互之间可以进行技术方案深度讨论，能够应对一定级别的复杂需求。人数不宜超过4个人，人太多，在同一个应用中开发不同的需求，可能每天都要处理不同的分支之间冲突，多套环境进行测试，效率比较低。同时人数太多，讨论效率也比较低。
此外需要尽量保证每个中高级别的开发者都是一个微服务的owner，有自己的一块自留地，在需求承接之外，能够在做一些技术相关的开发工作。

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

举个例子，比如你公司是做在线教育的，你入职负责开发公司的客户管理系统(CRM,下面统一用CRM代替)业务。首先你需要从全局分析CRM这块业务。

CRM按照流程划分主要是获客-跟进-转化-签约-服务。按照领域进行抽象，可以分为售前，售中，售后。

按照服务来划分，主要有投放服务、营销活动服务、呼叫服务、客户管理、日程管理、消息提醒、订单、合同、工单、销售效果分析。

每个服务有更细粒度的功能。比如
投放服务：提供多渠道投放方式，百度，头条，微信等，投放分析。
营销活动服务：营销落地页，开学季优惠活动，抽奖活动，优惠券活动。
客户管理服务：客户档案，销售机会，销售看板。
其他不再赘述。

目前业务还是在初级阶段，负责这块的开发总共有6人，3个后端，2个前端，一个测试。

基于以上考虑，服务划分为以下6个服务。

考虑到只需要一个pc工作台，市场人员、销售人员都用同一个工作台，应用系统这一层不需要。
然后核心领域分为售前（市场人员）、售中（客服，销售）、售后（客服，财务）三个服务，每个开发负责一个服务。同时抽象出3个通用基础能力服务，每个开发负责一个。

公司内部的账号系统
提供统一的账号管理能力，组织架构能力，权限管理能力。
服务系统
通用的一些工具能力，比如隐私号、坐席呼叫、待办、消息提醒等能力。这些并不属于同一个领域，但是考虑到当前阶段，服务不宜拆分的过细。所以都放在同一个服务中。
数据分析
各个模块都需要数据分析，所以抽象出一个单独能力，统一处理。