前言
随着团队微服务改造的深入，我们遇到了一个很棘手的问题：我们更换了全新的数据源/Mybatis版本/FastJson版本，天知道会出现什么奇怪的问题。（居然真就出现了），所以我们想出了比对结果来灰度的办法，大致思路如图： 
即将Application Resource的请求复制到Application Target，通过两次请求的结果比对来验证接口的正确性，因为本质上覆盖了用户的操作请求，原则上是比测试接入更有保障的。这边作为文档即说用法也说思路，由于不是很官方就写的很随意了。
简介
如果你的spring项目正在重构或使用新的中间件，但是在访问中间件后您没有有效的方法来确认系统原始查询API的正确性，此时，您只需要使用Copy Http RequestAndCompare来确认您的更新是正确的。 复制Http请求并比较具有以下功能：
- 可复制GET / POST请求
- 比较请求结果
- 保存结果并生成图表
快速开始
1.打包核心组件
项目由于是单独立项，这样其他项目只要依赖jar包就可以使用切面的方法。项目由于没有推送中央仓库，所以需要单独打包或者推送私服：
cd compare-core
mvn clean packagemvn clean deploy2.为你的项目添加依赖
<groupId>com.kelovp</groupId>
<artifactId>compare-core</artifactId>
<version>0.0.1-SNAPSHOT</version>3.填写必要的属性
由于这次的插件从很多维度控制了复制的配置，如果是自己接入可以通过引入自用的配置中心来动态配置，这样更加灵活
4.为需要复制的RequetMapping 添加切面
@RequestMapping(value = "/query", method = RequestMethod.POST)
@CompareApi(name = "Class#query",excludeFields={"code","message"})
public String query(String queryId){}至此，有关客户端的接入就完成了，剩下就是控制台Dashboard的打包和部署了，控制台的功能主要包括： - 生成报表 - 检索不一致结果次数并举例 - 提供建议的Mango的查询 - 应用切换 - 清空历史比对数据 由于控制台的Db基于Mango，如果对于性能要求高，建议配置MangoDB集群，使用多线程模式进行查询。 控制台接入： 填写Mango地址配置后：
cd compare-dashboard
mvn clean package
java -jar compare-dashboard.jarExp： 
性能影响
请求复制在Application Resource 机器开启线程池，使用阻塞丢弃策略，以下是压测结果： 单接口QPS 70下 无特别巨大差别 
线程池情况基本一直吃满，并未影响到主线程 
注意事项
- 项目添加了全局Filter和线程池，请注意对项目的影响
- 有写入操作的GET/POST 请评估影响再加入复制
- 配置比较繁杂，请认真阅读代码参数说明