流量录制回放在京东促销中台的应用实践
在《月光宝盒助力全自动高覆盖回归测试》一文中，我们重点对月光宝盒流量录制与回放平台在回归测试方面的核心功能以及设计原理进行了详细介绍。本文将在此基础上，结合促销中台的具体实践案例，进一步介绍如何运用月光宝盒满足各种回归测试需求场景。这些场景有简单的读接口场景，也有复杂的写接口场景；有常规的需求迭代回归测试，也有典型的系统重构场景下，如何结合流量切换进行回归测试，以及接口发生变化新老不兼容的场景。
本文是月光宝盒在促销中台诸多实际运用的探索思考与经验总结，场景方案也都是经过实践检验的，特别是在组件化、PaaS化等重大项目中发挥了巨大作用。下面我们将对这些需求场景以及落地方案一一展开论述，大家可作为参考案例借鉴，根据自身实际需求情况灵活选择运用。
简单正向读回放，指的是从生产环境录制流量，直接实时在线回放到预发环境中，具体的拓扑架构如图1。
方案特点：
仅录制服务入口方法，不录制子调用
流量录制来源为生产环境老版本，回放目标为预发环境新版本
回放目标版本部署于预发环境，与生产环境底层共享数据源以及外部依赖接口数据
录制接口与回放接口兼容
部署简单，成本较低
流量即时回放，不可复用
适合场景：
只读接口
日常需求迭代上线前的回归测试
PaaS 化改造场景，因为PaaS 化原则上对外接口是不变的，改动的是系统内部
简单反向回放，指的是从灰度环境录制流量，直接实时在线回放到生产环境中。根据切量方式不同，可以细分为两种方式。
第一种是，直接通过外部负载均衡切量。例如，对于 JSF 协议，直接在生产分组别名中追加灰度分组的实例，就可以实现将流量分流到灰度分组。对于 HTTP 协议，可以在 VIP 下追加灰度分组实例实现类似功能。具体的拓扑架构如图2。
方案特点：
仅录制服务入口方法，不录制子调用
流量录制来源为预发环境新版本，回放目标为生产环境老版本
录制来源与回放目标均为生产环境，底层共享数据源以及外部依赖接口数据
录制接口与回放接口兼容
部署简单，成本较低
流量即时回放，不可复用
适合场景：
只读接口
上线过程中灰度切量阶段的实时验证，对于复杂项目的新增功能一般需要较长周期的灰度切量。通过此方案，可确保新版本灰度分组承接的流量与老版本逻辑若还有不一致，可在第一时间发现，及时关闭切量。
需要注意的是，此时用于回放的生产分组与线上生产分组 JSF 别名应该是两个，因为线上分组与灰度分组已经共享一个别名，如果回放分组再跟他们共享，就会有部分录制流量又回放到灰度分组，等于自循环回放，达不到对比效果。
另一种是，在应用层切量，基本原理是代理转发。相对于外部负载均衡，在应用层，可以根据业务特性进行细粒度的切量控制，例如用户黑白名单、用户比例、调用方先后顺序、调用方比例等等，具体的拓扑架构如图3。
此时，回放方案整体上与前一种没有太大区别。值得一提的是，此时回放目标的生产分组可以和线上分组是一个JSF分组，但需要在切量层增加回放流量识别判断，即对于回放请求，不执行切量，直接执行老版本代码逻辑，这样回放流量就不会回流到录制来源的灰度分组了。
正反结合回放，指的是在从生产环境录制流量，回放到预发环境，同时从灰度环境录制流量，回放到生产环境中，如下图4，其拓扑架构以应用层切量为例。
方案特点：
仅录制服务入口方法，不录制子调用
录制来源与回放目标均为生产环境，底层共享数据源以及外部依赖接口数据
录制接口与回放接口兼容
生产分组与灰度分组双向互相录制回放对比
拓扑架构较复杂
适合场景：
读接口
既期望用老版本结果对比新版结果，又期望用新版结果对比老版结果，能够利用所有场景流量最大程度提高回归覆盖率
我们可能会注意到，此时灰度分组上来自正向对比的回放流量是否会被重复录制通过反向对比回流到生产分组，导致最终死循环录制回放？实际上不会！月光宝盒录制器会自动检测，默认会过滤掉回放流量，不会再对其录制，防止出现死循环流量。当然，可以将新版分组一拆为，切量使用灰度分组，正向对比使用测试分组，通过分组隔离解决。
简单写回放，指的是录制时包含服务入口方法以及子方法，回放时可对子方法使用录制数据进行 Mock，消除外部依赖，消除非幂等函数和瞬时函数的影响。拓扑架构如下图5。
方案特点：
同时录制服务入口方法以及子方法
回放时，子方法可用录制数据 mock
对于Mock 子方法可开启入参对比，因为，此时结果是录制数据或者写方法无返回值，比结果无意义，或者写方法是叶子方法，例如插入数据库
回放目标一般为隔离的测试环境，防止回放写接口时，意外情况下对生产环境引入脏数据
录制报文比较大，开销相对较大
生产环境与测试环境是隔离的，无法互通，需要先存储流量，通过中转服务访问
测试环境建设成本较高
适合场景：
写接口
读接口，存在外部依赖难以在预发环境中提供相应的回归测试环境
读写结合回放，指的是在前述的“写回放”基础上，增加对读请求的回放对比，此时内部持久化子方法就不能进行 Mock，需要准备好数据库环境支持实际存储，为后续读请求做准备。拓扑架构如下图6。
方案特点，基本同“写回放”，主要区别在于，前者对依赖进行“完全 Mock”，本方案对持久化方法不再进行 Mock。实际上，促销中台在组件化切量中，其后端写服务基本上采用的是此方案。
本方案是主要为了解决系统重构场景下，新老接口不兼容，录制接口与回放接口需要进行适配，包括接口名称、接口请求参数以及接口响应结果可能都发生了变化。
从接口版本演化以及架构演进上来说，作为服务提供方，是有责任优先保证新老接口的无缝切换的，解决方案就是前述的在服务端老版本中增加切量层，同时增加适配层。是不是应了那句——计算机科学中的每个问题都可以加一间接层来解决？！。除非适配层也无法兼容，那才选择下策：协同客户端去切量。实际上，从项目与工程角度考量，选择服务端兼容方案，在推进新版本切量上，在质量与进度上也更加可控。因此，业务切量所需的适配层也可复用到回放调用中。
那么，第一种方案就是，在回放对比服务中引入业务层的适配器，在回放调用前，将流量从录制来源的老接口协议转为回放目标需要的新接口协议。具体如下图7：
而第二种方案就是，可以再部署一套老版的生产分组，作为回放目标分组，这样对于录制回放来说都是老接口，而此分组直接切量到新版本上，在此分组上实现新老接口适配，具体如下图8。
图8
实际上，仔细一想，图8中的生产分组2与被测分组之间的链路，就是最终切量拓扑结构。如果我们结合前述的反向回放，就可以得出如下图9中的切量拓扑架构。如果再进一步，结合图7和图9或者图8和图9就可以得出前述”正反向回放“。此外，本方案同时适用于读接口和写接口，这里也不再赘述。实际上，促销中台在组件化切量过程中，其前端读服务在前期纯回归测试阶段采用的是图7，中期采用的是图8，而在开始进入灰度切量阶段之后就是采用的是图8和图9结合。
图9
本文主要对月光宝盒流量录制与回放平台的使用场景以及最佳实践进行归纳总结，为大家提供了丰富的成功案例，可作为快速参考手册，以便快速解决实际问题。篇幅有限，无法列举所有场景，实际上前述场景方案并不是一成不变的，可以进一步组合优化从而演化出更多的解决方案。
下一篇，我们将针对MQ、Worker类场景的录制回放方案以及压测场景运用进行介绍。同时，我们可以再次看到月光宝盒在架构上具有高度的灵活性、良好的扩展性，核心功能也比较丰富，能够满足不同场景的录制回放需求。过去月光宝盒1.0以及2.0版本主要聚焦在基础能力建设，在接入方式、在线管理、可视化、友好性方面比较薄弱，618之后启动了3.0新版本开发，预计在两个月内发布首个预览版，敬请期待。
如果大家对流量录制与回放话题、对月光宝盒原理与使用感兴趣，可与我们联系：wangxiaofeng3@jd.com，期望本文对大家有所帮助。