微服务最佳实践 -- 如何拆分

对于一个大系统，应该从什么角度进行微服务拆分？

首先我们要确定出微服务的大致数量，数量很关键，因为数量越多，维护成本越大，一定不要超出团队的承受范围。确定了数量，我们再考虑怎么拆。

服务粒度

最好是基于团队的规模进行拆分，以1个微服务由3个人开发最佳，例如团队开始有6个人，就可以划分为2个微服务，随着业务的发展，功能越来越多，团队扩充到了12个人，就可以把原来的2个拆为4个。

3个人的好处：

• 3个人负责一个微服务，每人对系统的理解程度、分工的粒度、系统的效率都是非常合适的。
• 从管理的角度来看，3个人是非常稳定的结构，即使1个人休假或者调走，剩余2个人还可以支撑。如果一共是2个人，走一个剩一个的话压力就很大了。
• 从技术提升的角度，3个人能够有效的讨论，快速达成一致，提升很快。如果是2个人，可能互相坚持自己的意见。如果是4个人，可能有的人不会认真参与讨论。

拆分方法

1. 基于业务逻辑拆分

将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。

例如，做一个电商系统，可以划分为商品、交易、用户3个服务，也可以划分为商品、订单、支付、发货、买家、卖家6个服务。

这2种划分都没问题，差异就是数量不同，这时就要根据上面拆分粒度的原则了，根据团队规模来决定。所以，我们要先计算大概的服务数量，然后再确定合适的“职责范围”。

2. 基于可扩展拆分

将系统中的业务模块按照稳定性排序，将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。

稳定服务的粒度可以粗一些，即使逻辑上关联不强的也可以放在一个服务中，例如日志服务、升级服务放在一个子系统中。

变动服务的粒度可以细一些，但要注意服务的数量。

这种拆分方式是为了提升项目快速迭代的效率，避免变动服务的改动升级影响了成熟的功能。

3. 基于可靠性拆分

将系统中的 可靠性要求高的核心服务 和 可靠性要求低的非核心服务 拆分开来，然后重点保证核心服务的高可用。

好处：

• 避免非核心服务故障影响核心服务

例如，日志上报是非核心服务，某一段时间内上报量可能会非常大，如果没有拆分出来，那么就可能严重影响核心服务。

• 核心服务高可用方案更简单

核心服务单独拆分出来后，涉及的数据、组件等都会更少，对其做高可用方案就简单很多，需要考虑的点较少。

• 降低高可用成本

拆分后，核心服务占用的机器、带宽等资源比不拆分要少很多。

4. 基于性能拆分

将对性能压力大的模块拆出来，避免影响其他服务，而且对其做性能提升、高可用等优化都更简单高效。

例如电商的抢购，排队功能的性能压力很大，就可以将其独立为一个服务。

小结

注意，这几种拆分方式不是多选一，可以根据实际情况自由组合，例如一个系统X，可以基于可靠性拆分出服务A，基于性能拆分出B，基于可扩展性拆出 C/D/F，最后共 A/B/C/D/F/X 6个服务。

内容整理自《从0开始学架构》