在ToC业务里，往往需要在不影响客户体验的情况下进行系统迁移（还是国企好，说停机就停机）。不停机迁移分为两个阶段。第一阶段是通过流量测试验证新系统的功能正确性、可伸缩性和性能问题，确保新系统的弹性。第二阶段就是逐步将流量迁移到新系统，并监控各种指标：包括客户设备级别的体验质量(QoE，Quality-of-Experience)度量、服务级别协议(SLA，Service-Level-Agreement)和业务级别的关键性能指标(KPI，Key-Performance-Indicator)。
为了沿验证新系统的正确性和性能，要进行重放流量测试（Reply Traffic Testing）——生产流量复制和分发一份到新系统运行，并对比新旧系统返回结果的一致性。
重放解决方案
重放流量测试解决方案有俩组件：
- 流量复制和关联: 复制一份流量给新系统的路径上，并记录新老系统的结果
- 对比分析和报告: 对比新老系统的结果并进行分析报告。
有三种方案去进行流量复制，
第一种是设备驱动，就是用户的客户端去进行两次相同请求给新老系统，缺点是浪费客户端资源，影响QoE（客户体验），并且分发逻辑依赖客户端代码，客户端迭代周期满，会影响服务发布周期导致迁移瓶颈，此外，允许设备执行未经测试的服务端代码路径可能会无意中暴露潜在攻击面。
第二种是服务端驱动，在后端的业务逻辑进行流量重放，把复杂度放在了后端。但是会要在业务逻辑里耦合流量重放测试功能，重放逻辑中的bug也有可能影响产品代码和指标，同样增加了风险。
第三种是专用服务，加一个中间层ReplyService，类似插件接口，重放流量打到ReplyService上，新服务可以像插件一样注册ReplyService。
重放流量分析
归一化：要对结果进行预处理，例如无序的列表，时间戳，都要化作可比较的数据。
比较：对双方响应结果和关键数据进行比较。
追溯：生成响应所涉及所有依赖项数据版本或校验和的综合摘要，称为追溯。例如随机数和依赖数据生成的响应。
还要比较实时流量、进行压力测试。
重放测试之后，就要开始正式的迁移了。迁移过程需要逐步将流量切换到新集群中，就需要一个流量分发组件，能将流量按权重分给旧系统和新系统，这叫灰度发布也叫金丝雀组。A/B测试则是把用户分几个组，控制变量去评估结果。
迁移有状态服务
实际上数据库也是一个有状态的服务，所谓无状态服务，就是可以随意kill掉然后创建一个新的。数据库不能这样，所以需要进行迁移。迁移有状态比无状态麻烦，可以分为同步初始数据、双活/双写进行数据同时写入新旧系统，然后加大新系统使用，然后实时监控正确性。
