微服务的拆分规范和原则

微服务拆分没有一个绝对正确的方案，服务拆分的粒度完全要根据业务场景来规划，而随着业务的发展，原先的架构方案也需要做调整。

拆分方案

压力模型拆分

压力模型简单来说就是用户访问量，我们要识别出某些超高并发量的业务，尽可能把这部分业务独立拆分出来。这么做的原因非常简单，高并发业务相当于前线战场，战况非常激烈，如果我方部署兵力不够（服务器资源），而敌方攻势又过于猛烈（剁手族们疯狂的流量），万一战线失手了服务器压力抵挡不住，我们不希望让这种情况影响到其他用户场景。

我这里举两个例子：

• 秒杀：秒杀是一个典型的低频突发流量的场景，参加秒杀的商品的数量一般不会很多，但是在秒杀开始的时候，尤其是对爆款商品来说（比如新发布的苹果手机），会有一个很明显的突发流量

• 商品详情页：商品详情页毫无疑问是电商场景中并发量最大的业务，一笔成功达成的订单背后，可能会调用几十次商品详情页接口（同学们买东西都要货比三家么不是）

我在做具体规划的时候，会尽量把压力模型拆解为三个维度

• 1）高频高并发场景：比如商品详情页，它既是一个高频场景（时时刻刻都会发生），同时也是高并发的场景（QPS - Query per seconds极高）
• 2）低频突发流量场景：比如前面提到的秒杀，它并不是高频场景（偶尔发生），但是它会产生突发流量。再跟大家举