之前你维护的一体化架构就像是一个大的蜘蛛网，不同功能模块错综复杂地交织在一起，方法之间调用关系非常的复杂，导致你修复了一个 Bug 可能会引起另外多个 Bug，整体的维护成本非常高。同时，数据库较弱的扩展性也限制了服务的扩展能力
出于上述考虑，你要对架构做拆分。但拆分并不像听上去那么简单，这其实就是将整体工程重构甚至重写的过程。你需要将代码拆分到若干个子工程里面，再将这些子工程通过一些通信方式组装起来，这对架构是很大的调整，需要跨多个团队协作完成。
所以在开始拆分之前你需要明确几个拆分的原则，否则就会事倍功半甚至对整体项目产生不利的影响。
原则一，做到单一服务内部功能的高内聚和低耦合。
也就是说每个服务只完成自己职责之内的任务，对于不是自己职责的功能交给其它服务来完成。说起来你可能觉得理所当然对这一点不屑一顾，但很多人在实际开发中，经常会出现一些问题。
比如，我之前的项目中有用户服务和内容服务，用户信息中有“是否为认证用户”字段。组内有个同事在内容服务里有这么一段逻辑：如果用户认证字段等于 1，代表是认证用户，那么就把内容权重提升。问题是判断用户是否为认证用户的逻辑应该内聚在用户服务内部，而不应该由内容服务判断，否则认证的逻辑一旦变更内容服务也需要一同跟着变更，这就不满足高内聚、低耦合的要求了。所幸我们在 Review 代码时及时发现了这个问题，并在服务上线之前修复了它。
原则二，你需要关注服务拆分的粒度，先粗略拆分再逐渐细化。
在服务拆分的初期，你其实很难确定服务究竟要拆分成什么样。但是从“微服务”这几个字来看，服务的粒度貌似应该足够小，甚至有“一方法一服务”的说法。不过服务多了也会带来问题，像是服务个数的增加会增加运维的成本。再比如原本一次请求只需要调用进程内的多个方法，现在则需要跨网络调用多个 RPC 服务，在性能上肯定会有所下降。
所以我推荐的做法是：拆分初期可以把服务粒度拆得粗一些，后面随着团队对于业务和微服务理解的加深，再考虑把服务粒度细化。比如对于一个社区系统来说，你可以先把和用户关系相关的业务逻辑，都拆分到用户关系服务中，之后，再把比如黑名单的逻辑独立成黑名单服务。
原则三，拆分的过程，要尽量避免影响产品的日常功能迭代。
也就是说，要一边做产品功能迭代，一边完成服务化拆分。
还是拿我之前维护的一个项目举例。我曾经在竞品对手快速发展的时期做了服务的拆分，拆分的方式是停掉所有业务开发全盘推翻重构，结果错失了产品发展的最佳机会，最终败给了竞争对手。
因此，我们的拆分只能在现有一体化系统的基础上不断剥离业务独立部署，剥离的顺序你可以参考以下几点：
1. 优先剥离比较独立的边界服务（比如短信服务、地理位置服务），从非核心的服务出发减少拆分对现有业务的影响，也给团队一个练习、试错的机会；
2. 当两个服务存在依赖关系时优先拆分被依赖的服务。比如内容服务依赖于用户服务获取用户的基本信息，那么如果先把内容服务拆分出来，内容服务就会依赖于一体化架构中的用户模块，这样还是无法保证内容服务的快速部署能力。
所以正确的做法是理清服务之间的调用关系，比如内容服务会依赖用户服务获取用户信息，互动服务会依赖内容服务，所以要按照先用户服务再内容服务，最后互动服务的顺序来进行拆分。
原则四，服务接口的定义要具备可扩展性。
服务拆分之后，由于服务是以独立进程的方式部署，所以服务之间通信就不再是进程内部的方法调用而是跨进程的网络通信了。在这种通信模型下服务接口的定义要具备可扩展性，否则在服务变更时会造成意想不到的错误。
在之前的项目中，某一个微服务的接口有三个参数，在一次业务需求开发中，组内的一个同学将这个接口的参数调整为了四个，接口被调用的地方也做了修改，结果上线这个服务后却不断报错，无奈只能回滚。
这是因为这个接口先上线后参数变更成了四个，但是调用方还未变更还是在调用三个参数的接口，那就肯定会报错了。所以服务接口的参数类型最好是封装类，这样如果增加参数就不必变更接口的签名，而只需要在类中添加字段就可以了。