发布机制-影子测试：百科

ylbtech-发布机制-影子测试：百科

1.返回顶部

 

2.返回顶部

1、

3.3 影子测试

对于一些涉及核心业务的遗留系统的升级改造，为了确保万无一失，有一种称为影子测试的大招，采用比较复杂的流量复制、回放和比对技术实现。下面是影子测试的一个样例架构图：

 实践要点

1. 目标实现老的 legacy 服务迁移升级到新的 experimental 服务。

2. 测试开始前，需要在测试环境部署一份 legacy 服务和 experimental 服务，同时将生产数据库复制两份到测试环境。同时需要将生产请求日志收集起来，一般可以通过 kafka 队列收集，然后通过类似 goreplay附录 6.8这样的工具，消费 kafka 里头的请求日志，复制回放，将请求分发到 legacy 服务和 experimental 服务，收到响应后进行比对，如果所有响应比对成功，则可以认为 legacy 服务和 experimental 服务在功能逻辑上是等价的；如果有响应比对失败，则认为两者在功能逻辑上不等价，需要修复 experimental 并重新进行影子测试，直到全部比对成功。根据系统复杂度和关键性不同，比对测试时间短的可能需要几周，长的可达半年之久。

3. 影子测试因为旁路在独立测试环境中进行，可以对生产流量完全无影响。

4. 影子测试一般适用于遗留系统的等价重构迁移，例如.net 转 Java，或者 SQLServer 数据库升级为 MySQL 数据库，且外部依赖不能太多，否则需要开发很多 mock，测试部署成本会很高，且比对测试更加复杂和不稳定。

5. 当当网有一个比较成功的交易系统.NET 转 Java 迁移项目附录 6.9，采用了影子测试技术，值得参考借鉴。

 优势和适用场合

优势：

• 对生产用户体验完全无影响

• 可以使用生产真实流量进行测试（复制比对）

不足：

• 搭建复杂度很高，技术门槛高，数据库的导出复制是难点

• 外部依赖不能太多，否则测试部署成本很高，且比对测试更加复杂和不稳定

适用场合：

• 核心关键业务，比如涉及资金的

• 具备一定影子测试平台研发能力，包括流量复制、数据库导出复制和分发比对系统。

 流量模式

影子测试对生产流量无影响，图片来自附录 6.1

2、

https://www.cnblogs.com/apanly/p/8784096.html

3、 附录6.1

https://github.com/intuit/wasabi

4、

3.返回顶部

 

4.返回顶部

 

5.返回顶部

1、

https://www.cnblogs.com/apanly/p/8784096.html

2、

 

6.返回顶部

 

作者：ylbtech 出处：http://ylbtech.cnblogs.com/ 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。