聊聊服务拆分与迁移

系统的复杂度，会随着业务的发展而越高。当业务发展到一定的阶段，原本单一的业务系统可能无法支撑或者出现瓶颈时，就需要对此进行重新规划和设计。

最近就碰到这个问题，原本业务的下的一些子业务最近发展比较快速，经过大家的讨论后，决定将这些子业务重新规划，拆分出单独的业务系统，目的也是为了方便日后的迭代和扩展。

具体情况具体分析，由于我们涉及拆分的业务，在业务量上比较大，并且面向C端用户，需要确保可用性。所以整体的迁移方案复杂度也会比较高。

我们是将拆分迁移分为两个阶段：应用拆分、数据拆分。

应用拆分

应用拆分，目标是将需要拆分的业务代码剥离出来，独立的应用系统，并且将拆分业务的流量都访问到这个新服务上。

当然，我们第一步必须要进行业务梳理。这里我将工程拆分迁移的内容划分为是三个部分：API、消息队列、定时任务。

API

一般来说，工程里的入口都是以 API 的形式提供出去，所以我们最容易想到的就是 API ，但同时这也是最比较复杂和繁琐的。

从类型层面可以分为：

• 外部接口：一般是前端调用，比如H5、小程序、APP客户端等。

• 内部接口：指服务之间的调用，提供给其他业务系统调用的。提供的方式通常是 HTTP 或者是 RPC。

外部接口一般都是通过统一网关透出去的 HTTP 接口，如果有接入统一网关，并且统一网关提供切流功能，我们可以平滑的把流量迁移到新的服务中。

这操作对于前端来说都是无感知的，甚至都不需要改动任何的接口。这一点很重要，因为对于一些前端没办法更改接口的情况，比如 APP 客户端，用户使用的旧版本 APP ，你肯定是没办法对其做任何修改，这种情况是需要兼容的。

内部接口，如果是 HTTP 接口并且也接入统一网关那好说，跟外部接口同样的切流方式是一样的。如果是 RPC 接口的话，要做到平滑切流，理论上有点麻烦。因为目前项目还没有 RPC 接口，所以暂时没有好的更具体的落地方案。

从业务层面可以分为：

• 独立接口：只有