微服务如何划分

Posted 2022-03-07 方丈的寺院

摘要

作为团队架构师/技术负责人你该如何进行微服务的划分呢?在以前的文章中讨论过这个话题，可落地的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，有自己的一块自留地，在需求承接之外，能够在做一些技术相关的开发工作。

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

如何划分

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

流程

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

服务

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

功能

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

人员

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

服务划分

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

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

1. 公司内部的账号系统 提供统一的账号管理能力，组织架构能力，权限管理能力。

     2. 服务系统        通用的一些工具能力，比如隐私号、坐席呼叫、待办、消息提醒等能力。这些并不属于同一个领域，但是考虑到当前阶段，服务不宜拆分的过细。所以都放在同一个服务中。

    3.数据分析        各个模块都需要数据分析，所以抽象出一个单独能力，统一处理。

演进

经过半年的发展，业务蒸蒸日上，需求越来越多。人员也在逐步扩展。后端人员扩大到了10人。原有的微服务架构逐渐不太适应。因此需要进行适当调整。经过分析，当前业务重点是

1. 售前 

   两个核心指标一个是有效线索量，一个是单个线索成本

       2. 售中              售中决定了线索能否转化为订单。目前对应的运营人员最多，客服100人，销售300人。提高运营人员效率是重点。

      3. 售后                      工单响应时长

售前这块基本系统功能已搭建完毕，通用的营销工具已经有了，市场人员可以进行组件组合，搭建不同营销页，然后根据投放效果进行适当调整。服务比较稳定了，所以这块有2个开发即可。主要负责营销工具开发。

售后相对也比较稳定了，2个开发。售中是重点，需求迭代也比较多，6个开发。之前只有一个微服务，开发效率比较低了。需要进行适当拆分。增加3个服务

1.应用系统增加一个移动工作台 因为销售人员经常在外部，所以需要移动端，而移动端通常是销售管理活动中的操作类功能。pc端则是查看分析。

     2.核心领域层增加一个售中服务域

售中拆成2个服务，一个是线索域，主要围绕着公海、私海，线索推荐。另外一个是服务域，是面向销售日常活动的。如活动，拜访，小记，客户标签等。

3 .基础能力层增加一个流程引擎服务 各个角色人员需要经常发起审批，流程编排，所以新构建一个基础能力，流程引擎。能够服务于整个crm业务，同时如果公司其他业务需要，可以提供给其他业务使用。

参考文章

    http://www.woshipm.com/pd/3983693.html

[1] 可落地的DDD(4)-如何利用DDD进行微服务的划分(2): https://blog.csdn.net/FS1360472174/article/details/90738148?spm=1001.2014.3001.5501

如何将一个ER图划分为多个微服务

【中文标题】如何将一个ER图划分为多个微服务

【英文标题】：How to divide a ER digram into multiple microservices

【发布时间】：2021-09-10 01:29:54

【问题描述】：

我有一个 ER 图，我想把它分割，这样我就可以实现多个微服务

enter image description here

我以前是实现单体类型的，有没有关于如何将ER图划分为微服务的指南？

例如，用户微服务将具有（用户表，用户类型表）。我有这些表车零件，汽车，国家，投诉，商店？

【参考方案1】：

在微服务架构中，定义微服务的既定方式称为decomposition by subdomain，这是一种自上而下的方法，基于您系统的bounded contexts。

一旦确定它们，您就可以找出合适的数据访问模型（每个微服务应使用哪些表）。

所以我建议遵循该模型，而不是自下而上，从数据库到微服务的定义方式。

【讨论】：

根据我的经验，对于失败的微服务迁移，没有什么比采用关系数据库模式（尤其是已经标准化的模式）并将表分配给微服务更可靠的方法了。

那有什么建议呢？

@LeviRamsey 完全同意自上而下的方法可能并非一直都是最好（或最快）的选择。如果自下而上更有意义，那么我认为这没有任何问题。

如果我想自下而上开始，我应该怎么做？