微服务设计和拆分的原则

领域驱动设计 专栏收录该内容
4 篇文章 1 订阅


1.微服务的接口粒度应该多大?
完成一个用例的作为服务服务接口的粒度是合理的,拆的太细面临事务问题。
2.微服务到底应该如何拆分和设计?
业务模型拆分:前后台业务拆分、主链路查费、领域模型拆分、用户群体拆分
压力模型拆分:对于高并发量的业务,尽可能独立成微服务拆分

1.压力模型拆分
压力模型拆分,就是说根据用户对业务的访问量的高频进行拆分,假如存在某些服务的调用量特别巨大,我们可以将此服务独立出来单独部署。
对于压力模型我们还可以细分三个维度
1.高频高并发的情况。
例如:商品详情页查询。他是一个高频高并发场景。
2.低频突发流量情况。
例如:秒杀。他是一个低频高并发场景。
3.低频低流量情况。
例如:商品的维护、上下架等操作。
对于高频高并发、低频突发流量这两种情况,可以独立组成模块。而低频低流量情况这个根据业务属性进行拆分,后边心签到会在说明。

2.前后台业务分离拆分
我们在网约车业务中会有一个乘客端、司机端、管理员端。同样在商城系统里,我们也会有
买家手机端(前台业务场景)、商家后台(后台业务场景)。在实际的开发过程中我们会将前台
后台独立拆分开来做一个隔离,这其实也符合高频场景(手机端)、低频场景(后台)的拆分原则的。

3.根据用户群体进行拆分
根据用户群体进行拆分,第一我们首先要需要知道我们系的目标用户有谁,例如ERP系统,有公司员工、有财务人员、HR等参与者。
对于不同的用户,他们都有自己特有的业务场景,用户的参与者具有分明特性的业务特别适合作为一个模块。我觉得首先会需要根据领域模型、主链路流程进行拆解,
然后在根据用户的领域方向和使用场景在进行细粒度拆分,根据用户群体进行拆分可以作为,领域模型、主链路流程拆解的一个补充。
具体领域模型拆解、主链路流程拆解后边在细化。

4-根据主流程拆分
在商城系统里有一个重要的主流程,那就是用户商品搜索-》商品详情-》购物车-》订单模块-》支付模块。
主流程是我们这个商城系统的核心业务,使我们需要固守的一个流程。
当然在这后边我们还隐藏这很多核心流程,比如:优化结算、收货地址、物流模块等,这当中里面的任意模块
奔溃、错误都可能导致用户放弃购买。
所以我们可以根据核心主流程模块进行拆分,主要能够带来以下几个好处:
1.服务隔离:当用户下单完成时,需要通过淘宝手机客户端推送一个消息给用户,消息推送服务的问题,不应该
到用户下单的操作。我们可以通过领域事件的走异步的策略解决这个问题。避免边缘的服务异常,影响到主流程。
2.异常容错:主流中的模块需要合理的设计降级策略、熔断策略。防止因为部分程序问题导致服务器雪崩的情况。
3.资源调配:针对主流程中的模块,在需要的时候我们可以分配更多的服务器资源。独立分拆主链路模块独立部署。

5.根据领域模型拆分
领域模型拆分,首先我们需要理解什么是领域。领域即问题域、问题空间、领域是一个边界范围。一个东西在售卖的时候他叫商品,当进行运输的时候叫做货物,他们处在不同的问题域里,所有我们在划分领域的时候,通用语言的作用域就可以做为微服务拆分的依据的。

6. 基于技术异构等因素

领域模型中有些功能虽然在同一个业务域内,但在技术实现时可能会存在较大的差异,也就是说领域模型内部不同的功能存在技术异构的问题。由于业务场景或者技术条件的限制,有的可能用.NET,有的则是 Java,有的甚至大数据架构。对于这些存在技术异构的功能,可以考虑按照技术边界进行拆分。

7.基于组织架构和团队规模

我们一个团队可能就10个人,当我们面对一个小商城系统时,我们可能会噼里啪啦一下拆了20多个微服务出来,这个是很恐怖的。因为一旦微服务化很多问题都会接踵而来,事务、超时、熔断、限流、服务监控、排错等问题。我们有限人员可能一下都耗费在这与业务无关的上面去了,这个是很严重的问题,过渡服务化。我觉得根据人员配置情况进行模块划分会是一个很合理的方案。首先我们粗粒度的形式进行划分。各领域之间还是遵循DDD的设计方法论,该怎么拆分模块就怎么拆,虽然他们可能都在一个大的模块里,但是这个不影响。当那天我们项目成功了,用户上来了,我们再把这些模块拆分出去也是简单的。因为我们已经划分好限界上下文,划分好领域,代码之间也不存在耦合和强引用关系。
不知道大家有没发现这里面其实还隐藏了一个问题就是人员的问题。服务边界我们虽然划分好了,人员那到底应该怎么去配比呢?
例如:我们按照业务来划分,根据粒度大小,一般会存在以下两个情况。
1.分为商品、交易、用户3个服务;
2.分为商品、订单、支付、物流、买家、卖家6个服务。
但是我们只有10个人的情况下,我们该如何选择以上两种方案。
我们可以依据“三个火枪手”原则。三个人分配一个服务的原则进行人员配比。具体什么是"三个火枪手原则"看下图

除非有意识地优化组织架构,否则微服务的拆分应尽量避免带来团队和组织架构的调整,避免由于功能的重新划分,而增加大量且不必要的团队之间的沟通成本。我们可以仿照管理学关于一个一层管理团队的理想大小,其答案不一定,但一般是不要超过10个,我个人比较舒服的数目是3到7个,拆分后的微服务项目团队规模保持在5+-2 人左右为宜。

8.基于安全边界

于安全边界有特殊安全要求的功能,应从领域模型中拆分独立,避免相互影响。

9. 基于业务需求变化频率

识别领域模型中的业务需求变动频繁的功能,考虑业务变更频率与相关度,将业务需求变动较高和功能相对稳定的业务进行分离。这是因为需求的经常性变动必然会导致代码的频繁修改和版本发布,这种分离可以有效降低频繁变动的敏态业务对稳态业务的影响。

 

 

 

 

 

 

  • 0
    点赞
  • 3
    评论
  • 3
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页

打赏作者

damon2636

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值