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

当不断从单体架构中抽象服务的时候，哪些服务优先被拆分，哪些服务不需要被拆分？以下几个策略可以帮助解决拆分中的这些问题。

比较独立的新业务优先采用微服务架构。从成本角度考虑，新业务采用新的架构是最合理的，因为这样做对老业务的影响最小。

优先抽象通用服务。因为通常通用服务的边界比较明显，耦合度低，比较容易分离。

优先抽象比较容易识别的、边界比较明显的服务。如果原有包结构比较清晰，可以基于原有包结构中有明显边界的、比较完整的业务进行划分，这是从成本角度考虑。如果已经基于单体架构开发了一段时间，对业务的理解程度已经非常高，那么开发及架构人员能够比较容易地提炼出一些边界比较明显的服务。

优先抽象核心服务。因为微服务的开发及运维成本比较高，并不是所有的地方都需要划分很小的粒度。往往一些比较边缘的运营、管理的系统甚至不会考虑拆分。另外，随着时间的推移，有一些业务可能会发生改变，因此应该先抽象出核心服务。

优先抽象具有独立属性的服务。应根据功能的变更频率、资源占用、技术栈等属性划分服务。

采用绞杀者模式，在遗留系统外围，随着时间的推移，让新的服务逐渐“绞杀”老的系统。在这种情况下，复杂度往往体现在如何灰度发布、迁移数据，以及如何保障服务不中断，后面的章节会详细描述。