首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >微服务如何划分

微服务如何划分

作者头像
方丈的寺院
发布2022-04-12 13:56:34
8990
发布2022-04-12 13:56:34
举报
文章被收录于专栏:方丈的寺院方丈的寺院

摘要

作为团队架构师/技术负责人你该如何进行微服务的划分呢?在以前的文章中讨论过这个话题,可落地的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

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2022-03-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 方丈的寺院 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 摘要
  • 为何要划分微服务
  • 如何划分
    • 流程
      • 服务
        • 功能
          • 人员
            • 服务划分
            • 演进
            • 参考文章
            相关产品与服务
            腾讯云 BI
            腾讯云 BI(Business Intelligence,BI)提供从数据源接入、数据建模到数据可视化分析全流程的BI能力,帮助经营者快速获取决策数据依据。系统采用敏捷自助式设计,使用者仅需通过简单拖拽即可完成原本复杂的报表开发过程,并支持报表的分享、推送等企业协作场景。
            领券
            问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档