对于一个大系统,应该从什么角度进行微服务拆分?
首先我们要确定出微服务的大致数量,数量很关键,因为数量越多,维护成本越大,一定不要超出团队的承受范围。确定了数量,我们再考虑怎么拆。
最好是基于团队的规模进行拆分,以1个微服务由3个人开发最佳,例如团队开始有6个人,就可以划分为2个微服务,随着业务的发展,功能越来越多,团队扩充到了12个人,就可以把原来的2个拆为4个。
3个人的好处:
将系统中的业务模块按照职责范围识别出来,每个单独的业务模块拆分为一个独立的服务。
例如,做一个电商系统,可以划分为商品、交易、用户3个服务,也可以划分为商品、订单、支付、发货、买家、卖家6个服务。
这2种划分都没问题,差异就是数量不同,这时就要根据上面拆分粒度的原则了,根据团队规模来决定。所以,我们要先计算大概的服务数量,然后再确定合适的“职责范围”。
将系统中的业务模块按照稳定性排序,将已经成熟和改动不大的服务拆分为稳定服务,将经常变化和迭代的服务拆分为变动服务。
稳定服务的粒度可以粗一些,即使逻辑上关联不强的也可以放在一个服务中,例如日志服务、升级服务放在一个子系统中。
变动服务的粒度可以细一些,但要注意服务的数量。
这种拆分方式是为了提升项目快速迭代的效率,避免变动服务的改动升级影响了成熟的功能。
将系统中的 可靠性要求高的核心服务 和 可靠性要求低的非核心服务 拆分开来,然后重点保证核心服务的高可用。
好处:
例如,日志上报是非核心服务,某一段时间内上报量可能会非常大,如果没有拆分出来,那么就可能严重影响核心服务。
核心服务单独拆分出来后,涉及的数据、组件等都会更少,对其做高可用方案就简单很多,需要考虑的点较少。
拆分后,核心服务占用的机器、带宽等资源比不拆分要少很多。
将对性能压力大的模块拆出来,避免影响其他服务,而且对其做性能提升、高可用等优化都更简单高效。
例如电商的抢购,排队功能的性能压力很大,就可以将其独立为一个服务。
注意,这几种拆分方式不是多选一,可以根据实际情况自由组合,例如一个系统X,可以基于可靠性拆分出服务A,基于性能拆分出B,基于可扩展性拆出 C/D/F,最后共 A/B/C/D/F/X 6个服务。
内容整理自《从0开始学架构》