全场景流量验证系统
![]()
Tech
导读
本文介绍了一种基于线上流量实现对重构系统进行功能和性能验证的实践方案。针对线上流量如何拦截、如何录制、如何存储、如何回放以及如何发压均作了详细说明，为具有类似需求的读者提供了一种可供参考的思路。
![]()
Tech
导读
本文介绍了一种基于线上流量实现对重构系统进行功能和性能验证的实践方案。针对线上流量如何拦截、如何录制、如何存储、如何回放以及如何发压均作了详细说明，为具有类似需求的读者提供了一种可供参考的思路。
随着百川项目的启动，中台需要对订单流量收口，将ECLP、各BP的接单入口全部切换至百川统一接单系统。且各个接单入口调用方式各异，有JOS请求（外部商家）、JSF请求（如TC），也有MQ异步消息（如POP）。为了确保各系统平稳切量，最大程度降低切量风险，需要在切量前做充分的流量验证（包括功能验证和性能验证）。为此，设计了一套全场景流量验证系统，支持基于线上流量的AB验证（功能验证）、压测（性能验证），为各业务线接单切量工作提供了可靠的基础支撑。
引流：把各个接单入口所在系统的线上流量引入到流量验证系统。
录制：复制线上流量并做持久化存储。
回放：把录制的流量打到待验证系统。
切量：把接单流量从ECLP等老的接单系统切换到新的百川统一接单系统中。
AB验证：线上流量同时打到正式环境和AB环境，对两个环境的结果做对比分析，验证AB环境的正确性。
如何引流？可以在业务系统中引入流量代理的方式实现引流。
如何录制？考虑需要支持大数据量以及复合查询，选择使用ES作为持久化存储方案。
如何回放？为避免对各业务系统Jar包依赖，选择使用JSF泛化调用实现流量回放。
是否有类似的系统可用？月光宝盒（jcase）：由京东零售开发的一款流量录制回放系统。其支持流量录制、回放功能，但是并不能满足一些个性化的需求，比如按自定义业务规则录制、切量控制等。
04 系统设计
4.1 总体设计
流量代理：通过拦截、过滤、上报将流量引流到验证系统中。
录制服务：接收流量代理引入的线上流量并做持久化存储。
回放引擎：使用录制的线上流量请求待验证目标接口。
压测引擎：使用录制的线上流量向待验证目标接口实现多线程发压。
图1 流量验证系统架构图
流量验证系统整体由流量代理、录制服务、回放引擎以及压测引擎四个模块组成。
4.2.1 流量代理
通用流量代理
图2 通用流量代理
在业务系统中引入流量代理，通过流量代理拦截（JSF Filter或AOP）线上流量，并将流量通过异步MQ方式上报给录制服务做持久化存储。
JOS流量代理
图3 JOS流量代理
外部商家通过HTTP方式调用JOS平台，JOS平台内部转JSF调用接单服务。为使外部商家无感，发布一个和业务系统接口完全相同的JSF服务（虚服务），不同的是提供一个新的别名，通过JOS平台配置切换到新的别名，这样就把JOS流量引入到了录制代理，然后再由录制代理通过异步MQ方式将流量上报给录制服务做持久化存储。
4.2.2 流量存储
录制的流量持久化存储到ES，按照[接口:方法]维度创建录制任务，同一个录制任务下的记录主键均以录制任务编号为前缀，后缀为数字递增，最大后缀（缓存到Redis中）即该录制任务下录制的记录总数。
| 属性名 | 示例值 | 示例值 |
| id | RT7625109167934456_1 | 主键标识 |
| recordData | { "args":[{"fakeNo":"fakeNo001"}], "argsType":["cn.jdl.baichuan.router.replay.contract.domain.fake.FlowFakeRequest"], "attachments":{"traceId":"8112206384546625","type":"1"}, "clazzName":"cn.jdl.baichuan.router.replay.contract.service.RouterFlowFakeService", "methodName":"match", "resultObj":true } | 录制的body体 |
| recordTaskNo | RT7625109167934456 | 所属录制任务编号 |
| timestamp | 1636719778929 | 时间戳 |
4.2.3 流量回放
支持单条、批量、按录制任务维度批量回放。回放调用采用JSF泛化调用方式，避免了对业务系统Jar包的依赖。
流量回放的同时，支持配置对比服务，对比服务接收入参以及新老接口的出参结果，可以对新老接口处理结果进行对比分析，以验证新接口功能的正确性。
4.2.4 流量压测
为了实现发压的效果，需要采用多机、多线程并发的方式请求目标接口。但是多机、多线程共用了同一份录制数据作为压力数据源。因此，在真正发压之前，需要为每个执行线程分配好数据，各个线程只取自己的数据，互不干扰。
发压策略（主从架构，Master分配，Slave执行）
图4 压测引擎发压原理图
压测引擎采用主从架构，压力机分主从节点，主节点负责接收压测请求并分配压测任务；从节点负责执行压测任务。
数据分配策略（按量平均，余数轮询，滑动窗口）
图5 数据分配示例
计算窗口
按录制任务中录制总量，平均分配到各个线程，余数再按轮询方式分配给每个线程，分完为止，这样可以确定出每个线程分配的记录条数（窗口大小）；
按窗口滑动
将所有录制任务从左到右水平平铺，每个线程按照自己窗口大小从左到右依次占用录制记录。
05 业务实践
5.1 切量验证
以仓配POP接单接口切换为例，我们需要用新的订单中心替换原来的ECLP-SO系统。在正式切换之前，仍然由ECLP-SO系统提供线上接单服务，但同时会通过流量验证系统录制线上流量并回放到新的订单中心。通过对比新老系统对相同接单请求的处理结果，验证新的订单中心的接单功能。经过充分功能验证后才会将接单流量切换到新的订单中心，从而极大降低了切量的风险。
图6 流量验证系统在POP切量中的应用
5.2 需求迭代
产品校验服务是产品中心对外提供的一个核心接口，接口逻辑复杂，每一次需求迭代上线都面临极大挑战。即便是经过了测试环境、预发环境验证，依然不能百分百保证上线后对线上业务没有影响。毕竟测试环境、预发环境的验证请求参数单一且有限，无法反映线上请求的多样性和复杂性。因此，产品中心接入了流量验证系统，每次有新的需求迭代上线前，首先录制线上流量，使用线上真实流量在预发环境进行充分验证后再做上线操作。这样极大降低了由于验证不充分，导致线上业务受损的几率，为线上业务提供了一层安全保障，提高了线上系统稳定性。