服务迁移 - RPC 服务迁移

关注公众号【1024个为什么】，及时接收最新推送文章！

前两篇文章总结了数据库服务迁移、Redis 服务迁移，今天继续看一下 RPC 服务的迁移。

如果单纯从节点迁移考虑，就相当于扩容、缩容。

但实际操作过程中会有很多坑，还是先看一下示例图。

（一）假设我们要迁移 userService 服务，从 10.0.0.1、10.0.0.2 的机器迁到 10.0.0.3、10.0.0.4 的机器上。userService 调用了数据库 和 orderService。

（二）先扩容，在 10.0.0.3、10.0.0.4 上部署 userService 服务，这样就有 4 个节点提供服务。

（三）通过服务治理把流量切到新的节点上，观察老节点没有流量后，下掉 10.0.0.1、10.0.0.2 上的 2 个节点

踩过的坑

1、直连服务调用

由于种种历史原因，有些服务没有走服务治理，而是直接调用的 userService，可能是在搭建服务治理之前就有的老服务，也有可能是 job 服务等特殊场景，写死调用了某个 IP 的节点。

如果老节点直接下掉了，调用方又没做修改，下次请求就找不到服务了。

这种情况就需要在前期梳理服务调用方的时候仔细梳理，至少统计一个多月以内调用 userService 服务的所有 IP、端口，排除掉服务治理上的，就是直连调用的。

大多 RPC 框架都会有调用方的 IP、端口的日志文件，比如 dubbo 的 dubbo-access-provider.log 文件，写个小脚本统计一下。

扩容之后，需要等调用方改调新节点后，且老节点没有任何调用和 TCP 连接了，才能下掉老节点。

2、IP 白名单

IP 白名单包含 内网服务 IP 白名单、外网服务 IP 白名单、数据库 IP 白名单。

如果下游服务 orderService 对调用方有 IP 限制，orderService  就需要在扩容前先加上新节点的 IP 白名单。

外网服务 IP 白名单、数据库 IP 白名单也是同样的道理。

3、数据库最大连接数

加入数据库服务限制了最大连接数为 100，原来 2 个节点各占 40 个连接。当扩容 2 个新节点后，每个节点还向数据库各申请 40 个连接，就会超过数据库的最大连接数限制。

所以要提前调高数据库的最大连接数，等老节点下掉后，再调回来。

4、特殊资源文件

系统设计时可能图方便，会在本地保存一些临时文件、模板文件、证书文件 ...

这些本地的文件也需要原样拷贝到新的节点

原创不易，多多关注，一键三连，感谢支持！