微服务拆分

 

微服务拆分

对在线教室业务来说，包括用户服务、在线教室服务、行为牌服务、回放服务、课件服务、信令服务、监课服务、在线教室反馈等等

电子商务：用户服务User、商品服务Info、交易平台Trade、搜索服务Search、推荐引擎等

1、垂直拆分

拆不拆分主要看业务是物理关系还是逻辑关系 用户与商品是业务关系、商品与交易是业务关系等
用户与在线教室是业务关系、商品与交易是业务关系等

物理关系就是在同一个数据库，一般一个微服务都是独立部署、单进程、独立数据库

拆分粒度问题：假如用户服务有注册、登陆、查询等功能，
注册是写服务、登陆和查询都是读服务。
读写比例是1:10 ,有的是1:1万 1:10万 比如腾讯登陆、读写比能达到1:10万以上的是博客系统，比如简书的文章阅读人数几十万。
读写比超过1:10，或者QPS达到1000以上 可以考虑拆分注册服务、登陆查询服务
登陆查询会影响到写服务注册。
拆分到API层 应该是最小粒度的拆分了。

商品的发布和查询服务，当商品的访问量比较大的时候，也是要考虑去拆分。

光垂直拆分是不够的，比如搜索访问DB或者Cache,当访问量大的时候就需要水平拆分

2、水平拆分

 

微服务的拆分规范和原则

拆分方案

• 压力模型拆分
• 业务模型拆分
  --主链路拆分
  --领域模型拆分
  --用户群体拆分
  --前后台业务拆分

高频高并发场景

比如商品详情页，高频场景 时时刻刻都会发生，商品详情页 并发量最大的业务
一笔成功达成的订单交易背后，可能会调用几十次商品详情页接口 货比三家

低频突发流量场景

比如前面提到的秒杀 突发流量 商品发布 新零售业务

低频低流量场景

这一类多为后台运营团队的服务接口，比如商品图文编辑，添加新的优惠计算规则，上架新商品。它发生的频率比较低，而且不会造成很高的并发量

通常我们建议将高频高并发的场景隔离出来，单独作为一个微服务模块，典型的就是商品详情页的后台服务。对低频突发流量的场景，如果条件允许也可以剥离出来独立组成模块，如果必须和其他业务包在一个微服务下，那一定要做好流控措施（最典型的就是削峰策略），而且还要考虑到异常情况下的补偿机制，对于低频流量场景，我们根据业务模型切分就好了

业务模型拆分 业务模型拆分的维度有很多，我们在实际项目中应该综合各个不同维度做考量。我这里主要从主链路、领域模型和用户群体三个维度来讲一下

2.1 主链路拆分

在电商领域“主链路”是一个很重要的业务链条，它是指用户完成下单场景所必须经过的场景。按照我们平时买买买的剁手经验，可以识别出很多核心主链路，比如商品搜索->商品详情页->购物车模块->订单结算->支付业务

电商领域背后还有很多隐藏的核心主链路，比如下单之前的营销优惠结算，它会影响订单的最终价格；再比如用户地址模块，它会影响下单前的配送地址选择。如果这两个模块出了问题，大部分用户恐怕都要放弃下单了。尤其是双十一我们添加了一篮子购物车，结果结算的时候发现所有优惠组合都失效了，或者是无法选择配送地址，那要果断放弃，甚至卸载了。

核心链路拆分的目的：

1、异常容错

为主链路建立层次化的降级策略（多级降级），以及合理的熔断策略

2、调配资源

主链路通常将都是高频场景，自然需要更多的计算资源，最主要的体现就是集群里分配的虚拟机数量多。将主链路服务单独隔离出来，这样有利于根据需要指定资源计划（比如双十一阶段为每个主链路服务拟定不同的扩容计划）

3、服务隔离

主链路是主打输出的C位，把主链路与其他打辅助的业务服务隔离开来，避免边缘服务的异常情况影响到主链路

2.2 领域模型拆分

领域驱动设计DDD（Domian-Driven Design 领域驱动设计）

领域的合并：淘宝系的营销优惠服务，曾经天猫和淘宝各有一套营销服务，如果不考虑底层技术，从业务层面来说，他们做的事情是一样的，都属于营销优惠计算的领域范围，因此后面两条技术线整合成一套UMP营销优惠服务；

领域的拆分：微服务的规划需要确保各个领域之间有清晰的界限，比如商品服务、订单服务，尽管他们之间有交集，都围绕商品主数据，但是毕竟是服务于不同领域：商品域和订单域，所以我们将它们拆分成独立的服务

2.3 用户群体拆分

根据用户群体拆分，需要了解自己系统业务有哪些用户，比如说电商领域，我们有2C的小卖家，也有2B的大客户，在集团内部有运营、采购、还有客服小二等等。对每个不同的用户群体来说，即便是相同的业务领域，也有该群体其独有的业务场景

用户群体相当于一个二级域，建议先根据主链路和领域模型做一级域的拆分，再结合具体的业务分析，看是否在用户领域方向上做更细粒度的拆分

2.4 前后台业务分离

网约车业务不仅仅有一个乘客app,也有一个司机端app

电商领域：手淘app买买买(前台业务场景)，商家通过后台的业务系统管理商品信息（后台业务场景）。

在实际项目中通常也会将前台业务和后台业务做一个隔离，这也符合高频业务（前台）和低频业务（后台）的隔离策略