全场景流量验证系统-京东云开发者社区

### 1 业务背景

随着百川项目的启动，中台需要对订单流量收口，将ECLP、各BP的接单入口全部切换至百川统一接单系统。且各个接单入口调用方式各异，有JOS请求（外部商家）、JSF请求（如TC），也有MQ异步消息（如POP）。为了确保各系统平稳切量，最大程度降低切量风险，需要在切量前做充分的流量验证（包括功能验证和性能验证）。为此，设计了一套全场景流量验证系统，支持基于线上流量的AB验证（功能验证）、压测（性能验证），为各业务线接单切量工作提供了可靠的基础支撑。

### 2 名词解释

- 引流：把各个接单入口所在系统的线上流量引入到流量验证系统。
- 录制：复制线上流量并做持久化存储。
- 回放：把录制的流量打到待验证系统。
- 切量：把接单流量从ECLP等老的接单系统切换到新的百川统一接单系统中。
- AB验证：线上流量同时打到正式环境和AB环境，对两个环境的结果做对比分析，验证AB环境的正确性。

### 3 设计思路

**如何引流？**
可以在业务系统中引入流量代理的方式实现引流。

**如何录制？**
考虑需要支持大数据量以及复合查询，选择使用ES作为持久化存储方案。

**如何回放？**
为避免对各业务系统Jar包依赖，选择使用JSF泛化调用实现流量回放。

**是否有类似的系统可用？**
月光宝盒（jcase）：由京东零售开发的一款流量录制回放系统。其支持流量录制、回放功能，但是并不能满足一些个性化的需求，比如按自定义业务规则录制、切量控制等。

### 4 系统设计

#### 4.1 总体设计

流量代理：通过拦截、过滤、上报将流量引流到验证系统中。
录制服务：接收流量代理引入的线上流量并做持久化存储。
回放引擎：使用录制的线上流量请求待验证目标接口。
压测引擎：使用录制的线上流量向待验证目标接口实现多线程发压。

![](//img1.jcloudcs.com/developer.jdcloud.com/bd3f8d4a-55c6-4843-8dbe-779d81893e6020220215141044.png)

#### 4.2 详细设计

##### 4.2.1 流量代理

###### 1）通用流量代理

![](//img1.jcloudcs.com/developer.jdcloud.com/858f5eef-a9f0-4d17-85ab-8b21e49e361d20220215141107.png)

在业务系统中引入流量代理，通过流量代理拦截（JSF Filter或AOP）线上流量，并将流量通过异步MQ方式上报给录制服务做持久化存储。

###### 2）JOS流量代理

![](//img1.jcloudcs.com/developer.jdcloud.com/5371a296-16fc-498d-86b7-b545eae925b220220215141139.png)

外部商家通过HTTP方式调用JOS平台，JOS平台内部转JSF调用接单服务。为使外部商家无感，发布一个和业务系统接口完全相同的JSF服务（虚服务），不同的是提供一个新的别名，通过JOS平台配置切换到新的别名，这样就把JOS流量引入到了录制代理，然后再由录制代理通过异步MQ方式将流量上报给录制服务做持久化存储。

##### 4.2.2 流量存储

录制的流量持久化存储到ES，按照[接口:方法]维度创建录制任务，同一个录制任务下的记录主键均以录制任务编号为前缀，后缀为数字递增，最大后缀（缓存到Redis中）即该录制任务下录制的记录总数。

![](//img1.jcloudcs.com/developer.jdcloud.com/58811148-cabc-4c83-b434-eb3c7acf1b3620220215141208.png)

##### 4.2.3 流量回放

支持单条、批量、按录制任务维度批量回放。回放调用采用JSF泛化调用方式，避免了对业务系统Jar包的依赖。

流量回放的同时，支持配置对比服务，对比服务接收入参以及新老接口的出参结果，可以对新老接口处理结果进行对比分析，以验证新接口功能的正确性。

##### 4.2.4 流量压测

为了实现发压的效果，需要采用多机、多线程并发的方式请求目标接口。但是多机、多线程共用了同一份录制数据作为压力数据源。因此，在真正发压之前，需要为每个执行线程分配好数据，各个线程只取自己的数据，互不干扰。

发压策略（主从架构，Master分配，Slave执行）

![](//img1.jcloudcs.com/developer.jdcloud.com/828c2ced-bd86-48ac-b154-0f7adc4bf70c20220215141243.png)

压测引擎采用主从架构，压力机分主从节点，主节点负责接收压测请求并分配压测任务；从节点负责执行压测任务。

数据分配策略（按量平均，余数轮询，滑动窗口）

![](//img1.jcloudcs.com/developer.jdcloud.com/b1f0ec4f-b785-4d77-8f80-7eb4cce04e5920220215141258.png)

###### 1）计算窗口

按录制任务中录制总量，平均分配到各个线程，余数再按轮询方式分配给每个线程，分完为止，这样可以确定出每个线程分配的记录条数（窗口大小）；

###### 2）按窗口滑动

将所有录制任务从左到右水平平铺，每个线程按照自己窗口大小从左到右依次占用录制记录。

### 5 业务实践

#### 5.1 切量验证

以仓配POP接单接口切换为例，我们需要用新的订单中心替换原来的ECLP-SO系统。在正式切换之前，仍然由ECLP-SO系统提供线上接单服务，但同时会通过流量验证系统录制线上流量并回放到新的订单中心。通过对比新老系统对相同接单请求的处理结果，验证新的订单中心的接单功能。经过充分功能验证后才会将接单流量切换到新的订单中心，从而极大降低了切量的风险。

![](//img1.jcloudcs.com/developer.jdcloud.com/35c840b1-3da3-409c-8e86-87646f01a48e20220215141451.png)

#### 5.2 需求迭代

产品校验服务是产品中心对外提供的一个核心接口，接口逻辑复杂，每一次需求迭代上线都面临极大挑战。即便是经过了测试环境、预发环境验证，依然不能百分百保证上线后对线上业务没有影响。毕竟测试环境、预发环境的验证请求参数单一且有限，无法反映线上请求的多样性和复杂性。因此，产品中心接入了流量验证系统，每次有新的需求迭代上线前，首先录制线上流量，使用线上真实流量在预发环境进行充分验证后再做上线操作。这样极大降低了由于验证不充分，导致线上业务受损的几率，为线上业务提供了一层安全保障，提高了线上系统稳定性。

------------

###### 自猿其说Tech-京东物流技术发展部
###### 作者：朱永昌