线上流量对比应用实践
我们在进行代码重构以及需求迭代时，在上线之前需要进行一轮、二轮以及回归测试，如果业务场景比较复杂，那么就会存在以下几个方面的问题：
测试的周期就会相应的拉的比较长； 随着业务功能的不断迭代，测试案例不一定能够覆盖全，一些冷门的隐藏比较深的问题不一定可以及时发现，回归测试难度逐渐增大； 影响发布频率； 开发以及测试人员消耗在测试阶段时间比较长，不利于腾出时间进行下一步的业务迭代、技术改造等工作； 代码质量很多时候依赖人为的code review，迭代代码行较多，code review占用时间较多；
和流量回放平台对比
目前业内的流量回放平台基本都是基于流量的录制，将流量引到测试环境进行回放，回放后分析系统存在的问题，在一定程度上只能释放一些回归测试的资源，并不能使我们开发中存在的问题在提测之前可以及时暴露，提前让开发人员解决问题，提高代码提测的质量，我们的目标是要做到即使没有测试参与，也要保证我们的代码质量，如果对线上存量业务的有影响，能够及时得到反馈，形成一个闭环处理，一个实时性的比对方案是很有必要的。
流量比对方案
对于一般的业务系统，我们比对的维度一般包括数据库落地数据、mq消息、接口调用请求参数以及输出四个维度，一般情况下在对比流量是整个生产流量50%情况下，基本可以覆盖生产案例场景，在此基础上针对这三个维度对比结果一致率接近100%，那么我们的上线的迭代版本对存量业务的影响是可以得到保证的。主要思路是构建请求报文，执行请求再到分析比对结果。
整体架构
当生产应用处理完对应请求时，所有涉及接口的调用，mq消息的发送等埋点信息都会被记录到ES（鉴于ES是分布式、高扩展、高实时的搜索和数据分析引擎，通过其提供的接口，可以很方便的获取埋点信息），这时候会发出一条mq消息，对比工具监听mq消息进行消费，根据对应的订单信息，查询生产订单数据并进行mock，然后调用对比应用，对比工具延迟一定时间后，根据需要对比的内容进行对比，将比对结果发送ES，可以根据ES对比结果埋点查看对比一致率以及不一致的具体原因。
注：
生产应用：实际的生产应用集群
对比应用：我们的迭代版本部署集群
对比工具：单独专门用来跑对比的一个应用
数据埋点
数据埋点是比对的前提，包括接口请求的埋点、mq消息的埋点，输入请求的埋点，后续对比工具读取数据进行比对。
数据mock
对比应用不能实际操作db以及和上下游系统进行交互，所有数据需要进行mock，mock的数据主要是调用下游接口的应答数据，mock的数据可以写入redis，对比应用在处理业务逻辑时，可以直接读取redis相应的mock数据作为返回。
对比配置+数据对比
对比配置一般配置在配置中心，可以根据实际对比的维度进行配置化管理,对比表字段的对比，比如一些时间，可以配置成忽略字段，接口和mq里面的一些参数也可以进行配置化忽略对比，比如订单号、发送时间之类。
结果一致率分析
对比工具可以将对比结果发送至ES，我们可以通过ES根据具体的埋点actionType筛选对应的比对结果，一致率和不一致原因。
总结
线上流量对比方案总体是基于基本的业务埋点，对一个业务流程里面所涉及到的具体接口，mq消息都需要有一个全面的梳理，需要指出的是，想要真正利用实时对比方案提前知道迭代风险的前提是，我们可以随时发布对比应用，这一点上面应该不要做限制。 我们的愿景是在即使没有测试参与的情况下，开发也可以保证上线代码的安全性，开发自己可以形成闭环。此对比方案存在一些优缺点如下：
优点
1. 可以及时发现代码重构以及版本迭代改动中存在的问题，并及时修复，不必等到提测之后再由测试发现，潜在问题可以提前暴露。不必过度依赖测试来发现问题；
2. 一定程度上释放回归测试的资源；
3. 保证整个研发过程的质量；
4. 可以提升发布频率；
5. 对比应用不需要单独搭建一套对比数据库用于对比，降低对比成本；
6. 对比应用和对比工具作为非核心应用，随改随发，有一定的灵活性；
7. 对比内容灵活化配置。
缺点
*文/志敏