微服务拆分策略
当不断从单体架构中抽象服务的时候，哪些服务优先被拆分，哪些服务不需要被拆分？以下几个策略可以帮助解决拆分中的这些问题。
· 比较独立的新业务优先采用微服务架构。从成本角度考虑，新业务采用新的架构是最合理的，因为这样做对老业务的影响最小。
· 优先抽象通用服务。因为通常通用服务的边界比较明显，耦合度低，比较容易分离。
· 优先抽象比较容易识别的、边界比较明显的服务。如果原有包结构比较清晰，可以基于原有包结构中有明显边界的、比较完整的业务进行划分，这是从成本角度考虑。如果已经基于单体架构开发了一段时间，对业务的理解程度已经非常高，那么开发及架构人员能够比较容易地提炼出一些边界比较明显的服务。
· 优先抽象核心服务。因为微服务的开发及运维成本比较高，并不是所有的地方都需要划分很小的粒度。往往一些比较边缘的运营、管理的系统甚至不会考虑拆分。另外，随着时间的推移，有一些业务可能会发生改变，因此应该先抽象出核心服务。
· 优先抽象具有独立属性的服务。应根据功能的变更频率、资源占用、技术栈等属性划分服务。
· 采用绞杀者模式，在遗留系统外围，随着时间的推移，让新的服务逐渐“绞杀”老的系统。在这种情况下，复杂度往往体现在如何灰度发布、迁移数据，以及如何保障服务不中断，后面的章节会详细描述。
如何衡量服务划分的合理性
每个产品在实施微服务架构最初的动力都不一样，目标也有所区别，所以判断是否划分合理，首先要看是否达成了目标。其次，可以参考以下几种衡量方式。每种衡量方式不能单独作为一个判断标准，需要综合考虑。
· 一个小功能的修改从需求到上线需要多长时间？正常情况下的微服务架构交付周期应该是以天为单位的。如果一个小功能的修改需要几周到几个月的时间，可能意味着服务划分粒度过大，存在太多的冲突，要等待合并代码。
· 大多数功能修改是否可以在一个服务内完成？如果经常需要跨服务团队的联合开发组才能完成一个新功能的开发或者旧功能的修改，则说明服务划分存在问题。
· 是否要频繁修改接口？频繁修改接口有可能是接口设计不合理导致的，也有可能是服务划分的问题导致的，说明服务之间的边界并不是特别明确和稳定。
· 响应时间是否能满足要求？在某些追求极致性能的场景中，对响应时间要求较高，服务划分的层次太多、粒度太小都可能导致响应时间不能满足要求。
· 是否存在大量的跨服务更新？是否存在大量的跨服务的关联查询？出现这两个问题，可能是因为划分不合理。
微服务划分反模式
前面我们介绍了如何划分服务，在此之上，我们希望通过微服务划分的反模式来帮助大家少走弯路。
根据代码行数划分服务
代码规模太大会导致沟通效率、交付效率低下，耦合度高，以及比较笨重。代码规模可以作为一个参考，但是不能作为一个绝对标准，微服务架构中存在一个“大服务”是很正常的。基于代码行数拆分服务很难衡量服务的完整性，容易导向更小的拆分粒度，引起不必要的复杂度。
划分粒度越小越好
服务的大小并不是特别重要，可以根据团队规模、代码规模、业务复杂度、技术领域、重要程度、成本等因素综合考虑。关于服务粒度的大小，业界并没有统一标准，也很难衡量，最接近的衡量标准是研发团队规模。粒度小意味着更高的维护成本。后端管理、辅助系统通常粒度较大。
一次性划分服务
拆分服务有如下两种方式。
第一种，先拆分业务代码再拆分数据库。如图2-9所示，数据库并没有拆分，只是从单体中抽象出部分服务。
采用第二种方式拆分服务时，根据服务将数据库彻底拆分为多个独立的数据库，每个服务独享数据库服务，服务之间只能通过接口调用。这看起来非常美好，但需要为此做大量的数据迁移。当业务处于初期，需求不是非常确定，开发人员对业务理解不是特别透彻的时候，可能拆分后发现拆分得并不合理，只能再进行合并，又要进行一次数据迁移。相对来说，业务代码拆分成本更低，而数据迁移的成本更高，频繁、大量的数据迁移并不可取。
更好的做法是把第一种方式作为过渡阶段，当业务逐步稳定后再彻底进行数据迁移。注意，处于过渡阶段时数据库并没有彻底分离，一切依赖都通过接口访问。但是这只是口头上的约定，对于业务开发人员直接在数据库中进行关联查询。需要通过Code Review的方式避免。
服务划分是一个长期的过程，需要积累大量的领域知识，以此来理解核心流程。最好是和领域专家一起组成联合团队，在理解核心问题的情况下，持续拆分服务并验证拆分合理性，随着时间的推移，还可以重新划分。可见，服务拆分是一个持续性的过程。
服务划分一旦完成，不能改变
由于业务的不断变化，以及开发人员对领域知识和其他影响因素的理解等问题，很难一次性做出一个完美的解决方案。通常在划分后会发现，某个问题是不可忍受的，例如划分后导致响应时间降低，增加了更多的成本，有可能需要重新合并服务；由于业务的变化，原本的依赖关系发生了变化，有可能面临需要重新划分服务等类似的问题。
先实施组件化，再实施微服务架构
很多技术人员试图先通过组件化逐步过渡到微服务架构，这是一种错误的思路。微服务架构划分更强调业务领域的完整性，因此垂直划分优先，而组件化往往通过抽象出稳定的部分形成组件共享，对调用次数和依赖关系并不强调。因此，组件化之后再转化到微服务架构的方式，通常是错误的。
