一种可灰度的接口迁移方案
作者：腿儿（曾臻）
出品：大淘宝技术
在快速迭代的互联网背景下，系统为了实现快速上线，常常会选择最快的开发模式，例如我们常见的mvp版本迭代。大部分的业务系统对于未来业务的发展是不确定的，因此随着时间的推移，往往会遇到各种各样的瓶颈，例如系统性能、无法适配业务逻辑等问题，这时可能就涉及到系统架构的升级。系统升级往往包含最基础的两个部分： 接口迁移重构和数据迁移重构，在系统架构升级的过程中，最重要的是需要保证系统稳定性，即用户不感知。因此文本的目的是提供一种可灰度、回滚的设计思路，实现稳定的架构升级。
场景
在我们系统迭代过程中，往往涉及到重构、数据源切换、接口迁移等场景，为了保障系统平稳上线，因此在接口迁移过程中应该保证可回滚、可灰度。接口迁移可能也涉及到数据迁移，两者的先后顺序应该不影响到系统的稳定性。总结一下，接口迁移的目标：
- 可灰度，即使用新老接口是能够控制的。
- 可回滚，如使用新接口异常，能够快速回滚到老接口。
- 不入侵业务逻辑，不改动原来的业务逻辑代码，等迁移完毕后再整体下线，防止直接侵入修改造成不可逆的影响。
- 老接口在系统平稳运行后收口，即对老的数据源访问、老的接口能够平稳下线
迁移方案
本文主要为接口迁移和数据迁移提供了一种思路，在第3节里会有实践的核心代码实现。（代码只是提供思路，并不是能够直接运行的代码）
总体迁移方案
下图表示了接口迁移的思路，参考了cglib的jdk的代理方式。假设你有一个待迁移接口类（目标类），那么你需要重 新写一个代理类作为迁移后的接口。目标类和代理类的选择通过开关去控制，开关涉及到两个层面：
- 总开关：用于控制是否全量切换新接口，当接口迁移稳定上线 且 数据迁移完毕（如有）
- 灰度开关：可以设置一个灰度开关列表，用于控制你的那些接口/数据需要走代理接口
针对不同的接口逻辑，代理接口实现逻辑会有差异，具体场景如下文所述。
带你读《2022技术人的百宝黑皮书》——一种可灰度的接口迁移方案（2）https://developer.aliyun.com/article/1339610?groupCode=taobaotech
