线上流量对比应用实践

见贤思齐

流量比对提出背景我们在进行代码重构以及需求迭代时，在上线之前需要进行一轮、二轮以及回归测试，如果业务场景比较复杂，那么就会存在以下几个方面的问题：测试的周期就会相应的拉的比较长；随着业务功能的不断迭代，测试案例不一定能够覆盖全，一些冷门的隐藏比较深的问题不一定可以及时发现，回归测试难度逐渐增大；影响发布频率；开发以及测试人员消耗在测试阶段时间比较长，不利于腾出时间进行下一步的业务迭代、技术改造等工作；代码质量很多时候依赖人为的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. 对比内容灵活化配置。缺点1. 对代码有一定程度的入侵，需要发出一个对比的mq消息2. 对于增量业务，因为其没有对比参考对象，目前还没有有效的方式确保代码质量，只有通过ut单元测试、代码code review等手段进行辅助。?*文/志敏关注得物技术，一起做最潮技术人