一、流量比对提出背景
咱们在进行代码重构以及需要迭代时，在上线之前须要进行一轮、二轮以及回归测试，如果业务场景比较复杂，那么就会存在以下几个方面的问题：
（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
关注得物技术，做最潮技术人！