内容来自《持续演进的 Cloud Native》

前面我们介绍了如何划分服务，在此之上，我们希望通过微服务划分的反模式来帮助大家少走弯路。

根据代码行数划分服务

代码规模太大会导致沟通效率、交付效率低下，耦合度高，以及比较笨重。代码规模可以作为一个参考，但是不能作为一个绝对标准，微服务架构中存在一个“大服务”是很正常的。基于代码行数拆分服务很难衡量服务的完整性，容易导向更小的拆分粒度，引起不必要的复杂度。

划分粒度越小越好

服务的大小并不是特别重要，可以根据团队规模、代码规模、业务复杂度、技术领域、重要程度、成本等因素综合考虑。关于服务粒度的大小，业界并没有统一标准，也很难衡量，最接近的衡量标准是研发团队规模。粒度小意味着更高的维护成本。后端管理、辅助系统通常粒度较大。

一次性划分服务

拆分服务有如下两种方式。

第一种，先拆分业务代码再拆分数据库。如图2-9所示，数据库并没有拆分，只是从单体中抽象出部分服务。

图2-9 先拆分业务代码再拆分数据库

第二种，业务代码和数据库同步拆分。如图2-10所示，部分业务服务被拆分出来的同时，数据库也被同步拆分出来。