思维导图
0. 前言
本文意在提供服务迁移的完整思路，将思考题变成填空题，只需要按照本文提供的思路填空，服务迁移至少可以做到 80 分。
本文的服务迁移指：将老服务的代码迁移至新服务。
1. 服务资源梳理
服务资源，我总结为以下 4 个大类
- 程序对外暴露资源
- 正常如：http、dubbo
- 需要梳理调用量、使用场景、影响点、重要性（重要性的评估需要和产品、使用方一起确定）
- 程序侧使用的资源
梳理这部分资源是为了能够知道，如果迁移至新服务，老服务使用的资源是否可下线？从而实现降本。例如：Mysql、Redis，等 - 运维侧资源
包含 jenkins、maven、历史镜像、k8s 相关、代码资源，配置中心等等。 - 上下游资源
要梳理老服务使用到的上下游资源。一般来说老服务下线后，上下游的资源都可以释放掉了。
常见的如：运营后台管理界面，以及数据组使用到的统计任务，等等…
2. 接口逻辑梳理
建议使用流程图或者时序图整理接口的逻辑。
3. 下线方案
下线方案包含以下 4 个部分。
-
接口逻辑如何处理？
例如，迁移至新接口后，默认返回空；例如，从查询老表转换为查询新表，并将老表下线 -
接口如何下线？
对于将老服务迁移至新服务，一般采用的是在 ingress 层面配置新老服务的灰度处理。
重构完毕后。我们可以配置灰度比例，慢慢将老服务的流量切到新服务上。
这里提供流量切换参考。
新服务 1% 流量 -> 最低风险验证新服务是否正常
新服务 20% 流量
新服务 50% 流量
新服务 80% 流量
新服务 100% 流量 -
资源如何下线？
如果资源可以下线，一般会牵扯到多个不同的团队，这里做好沟通即可 -
迁移失败可能带来的问题，这些问题如何处理
需要做好方案，并提前演练，降低迁移风险。
4. 功能验证方案
功能验证包含以下几个内容：
- 压测
- 新老接口的下发是否一致？
以上 2 个点，我们都可以通过流量回放来实现。
那么流量回放如何做呢？这里提供一个简单的方案
压测：
- 抓取线上真实用户请求日志
- 数据清洗，将数据转换为 jmeter 需要的格式
- 通过 jmeter 进行压测
新老接口下发是否一致：
- 抓取线上真实用户请求日志
- 通过脚本，分别请求线上和 QA。借用第三方 diff 功能，对比返回值。
- 如果有不正常的返回值，则将请求打到另外一个文件
5. 回滚方案
对于服务迁移，一般都是通过 ingress(网关) 来做。
在 ingress(网关) 层面做流量切换。
6. 开发计划
作为服务迁移、重构负责人，应该将大任务拆分为小任务，并对每个小任务进行工时评估。
每周需要对整个计划进行总结，梳理卡点，有可能延迟的地方，并进行相应调整。（可以在固定的时间，拉会对齐）
最重要的一点，进度要汇报给你的上级！！！
7. 成本核算汇总
做成本核算是为了能够更清楚的知道，本次服务迁移的总投入，以及带来的收益。
成本核算一般包含以下内容：
- 人力成本
- 下线资源成本
- 新增资源成本
