线上流量对比应用实践

一、流量比对提出背景

我们在进行代码重构以及需求迭代时，在上线之前需要进行一轮、二轮以及回归测试，如果业务场景比较复杂，那么就会存在以下几个方面的问题：

（1）测试的周期就会相应的拉的比较长；

（2）随着业务功能的不断迭代，测试案例不一定能够覆盖全，一些冷门的隐藏比较深的问题不一定可以及时发现，回归测试难度逐渐增大；

（3）影响发布频率；

（4）开发以及测试人员消耗在测试阶段时间比较长，不利于腾出时间进行下一步的业务迭代、技术改造等工作；

（5）代码质量很多时候依赖人为的code review，迭代代码行较多，code review占用时间较多；

为此，我们能否解决这些痛点，使得我们的工作效率得到一定的提升，以及我们代码的质量得到一定的保证，是我们需要思考的一个问题。业内的做法一帮将线上的流量引入对比机器，将生产结果和对比机器进行实时对比，及时暴露问题，开发和测试能够及时发现并进行修改。

二、和流量回放平台的对比

目前业内的流量回放平台基本都是基于流量的录制，将流量引到测试环境进行回放，回放后分析系统存在的问题，在一定程度上只能释放一些回归测试的资源，并不能使我们开发中存在的问题在提测之前可以及时暴露，提前让开发人员解决问题，提高代码提测的质量，我们的目标是要做到即使没有测试参与，也要保证我们的代码质量，如果对线上存量业务的有影响，能够及时得到反馈，形成一个闭环处理，一个实时性的比对方案是很有必要的。

三、流量比对方案

对于一般的业务系统，我们比对的维度一般包括数据库落地数据、mq消息、接口调用请求参数以及输出四个维度，一般情况下在对比流量是整个生产流量50%情况下，基本可以覆盖生产案例场景，在此基础上针对这三个维度对比结果一致率接近100%，那么我们的上线的迭代版本对存量业务的影响是可以得到保证的。主要思路是构建请求报文，执行请求再到分析比对结果。

（1）整体架构

当生产应用处理完对应请求时，所有涉及接口的调用，mq消息的发送等埋点信息都会被记录到ES（鉴于ES是分布式、高扩展、高实时的搜索和数据分析引擎，通过其提供的接口，可以很方便的获取埋点信息），这时候会发出一条mq消息，对比工具监听mq消息进行消费，根据对应的订单信息，查询生产订单数据并进行mock，然后调用对比应用，对比工具延迟一定时间后，根据需要对比的内容进行对比，将比对结果发送ES，可以根据ES对比结果埋点查看对比一致率以及不一致的具体原因。

注：生产应用：实际的生产应用集群

对比应用：我们的迭代版本部署集群

对比工具：单独专门用来跑对比的一个应用

（2）数据埋点

数据买点是比对的前提，包括接口请求的埋点、q消息的埋点，输入请求的埋点，后续对比工具读取数据进行比对

（3）数据mock

对比应用不能实际操作db以及和上下游系统进行交互，所有数据需要进行mock，mock的数据主要是调用下游接口的应答数据，mock的数据可以写入redis，对比应用在处理业务逻辑时，可以直接读取redis相应的mock数据作为返回。

（4）对比配置+数据对比

对比配置一般配置在配置中心，可以根据实际对比的维度进行配置化管理,对比表字段的对比，比如一些时间，可以配置成忽略字段，接口和mq里面的一些参数也可以进行配置化忽略对比，比如订单号、发送时间之类。

（5）结果一致率分析

对比工具可以将对比结果发送至ES，我们可以通过ES根据具体的埋点actionType筛选对应的比对结果，一致率和不一致原因。

四、总结

线上流量对比方案总体是基于基本的业务埋点，对一个业务流程里面所涉及到的具体接口，mq消息都需要有一个全面的梳理，需要指出的是，想要真正利用实时对比方案提前知道迭代风险的前提时，我们可以随时发布对比应用，这一点上面应该不要做限制。 我们的愿景是在即使没有测试参与的情况下，开发也可以保证上线代码的安全性，开发自己可以形成闭环。此对比方案存在一些优缺点如下：

优点

（1）可以及时发现代码重构以及版本迭代改动中存在的问题，并及时修复，不必等到提测之后再由测试发现，潜在问题可以提前暴露。不必过度依赖测试来发现问题；

（2）一定程度上释放回归测试的资源；

（3）保证整个研发过程的质量；

（4）可以提升发布频率；

（5）对比应用不需要单独搭建一套对比数据库用于对比，降低对比成本；

（6）对比应用和对比工具作为非核心应用，随改随发，有一定的灵活性；

（7）对比内容灵活化配置；

缺点

（1）对代码有一定程度的入侵，需要发出一个对比的mq消息

（2）对于增量业务，因为其没有对比参考对象，目前还没有有效的方式确保代码质量，只有通过ut单元测试、代码code review等手段进行辅助。

文/HUZHIMIN

关注得物技术，做最潮技术人！