闲鱼如何保障交易链路质量

背景

闲鱼作为一款垂直交易社区 APP，拥有复杂多样的业务场景：涉及 c2c、回收寄卖、租房租赁、见面交易、验货担保等，复杂多变的交易模式。比如验货流程：

• 涉及 39 个状态机节点

• 横跨 10+应用系统

• 涉及 6 个业务部门的合作

• 涉及接口几十个

需要保证每个接口、每个场景切实可行，稍微有一点点问题，就会涉及到人民币的味道，实际工作中，我们遇到各种各样的问题，比较棘手的问题如下

问题

业务先赢的快速迭代模式下，全靠人工主力进行测试验证，测完新功能，还得回归老功能，一个小需求也须要好几个人日，版本 PTM 也要回归好几遍，ROI 并不乐观，以下 2 个问题比较突出：

1. 交易业务强依赖中台，沟通成本高，跨团队协作难，迭代效率低，测试环境下如何自洽？

2. 复杂多样交易模式下，如何支撑需求稳步迭代上线以及日常回归验证？

测试策略-自动化

闲鱼质量基建正在快马加鞭进行中，针对闲鱼多样的交易模式，全靠人力是不可行的，累不说，改动、风险漏评估也时有发生。对此，我们根据接口->链路的策略，探索对比了几个不同的方案，在保证每个接口 OK 的基础上，保障全链路。

null

接口层

对于每一个大型应用程序来说，接口数量会不断增加，代码变更频率越来越大、系统不定期重构，这个接口的质量怎么来保障？传统编写脚本来进行的方式，投入的人力、时间成本过大，在实际的测试过程中我们探索了一些接口测试的新想法。目前业界公认的有效方式是基于引流回放的自动化测试，实现方案业内众说纷纭各有其词，但万变不离其中，引用下面这段总结，简单明了

一种是黑盒测试思路，它在线上接口请求时采集线上流量（主要是请求参数和结果），然后使用和线上环境相同的环境（数据库共用等）下用采集到的流量重新触发请求，然后断言被请求的返回值是不是和录制时的一致。这种方法比较适合对 Get 类型的接口进行测试，而对于写操作的请求容易造成数据污染，再加上所采集流量的数据状态（数据时效性）、环境依赖性（各种中间件、接口内部请求的 RPC 调用）等因素，所以这种测试方式具有一些局限性，不能满足实际测试场景中复杂的需求。

另一种思路相对白盒，主要是通过智能化的 Mock 手段，流量采集时采集代码运行过程中所依赖的外部中间件或者 RPC 调用的返回结果，当流量回放时，能够 Mock 本机程序对外的依赖中有可能产生变化的内容，使测试更关注本地接口的代码逻辑。

阿里集团内部，基于流量回放的思想，主要实现了 2 种不同的流量录制回放方案，一种是基于 doom 的天启/暴雪，一种是基于 JVM-Sandbox 的凤凰，两种实现都借力于 JVM AOP。

• 天启/暴雪

天启/暴雪，其底层采用的是 doom 进行流量录制，其原理如下

null

doom 原理图

主要流程是：

1. 通过 Java agent 挂在 JVM 中的 client 以 ASM 的 AOP 方式采集主调用（采集或回放时的入口方法）的入参、返回值、子调用（应用执行过程中的一次方法调用，采集机器会采集该方法的入参和返回值用于回放时执行到该方法进行 mock）的入参和返回值，然后将采集到的数据上传至 server （离线模式）；

2. 回放时，client 收到接口回放请求后，会执行该接口的本地逻辑，对于子调用则用采集的入参和结果进行 mock；

3. 将采集的流量和回放的结果数据进行对比。

doom 方式，业务应用系统需要引入 Jar 包，修改启动类，修改 JVM 挂载 agent，有部分的业务侵入性。

• 凤凰

凤凰，也是采用 JVM AOP 实现的流量录制方案，理念和 doom 差不多，凤凰整体架构底层基于 JVM-Sandbox（阿里开源的一款 JVM 平台非侵入式运行期 AOP 解决方案，通过字节码增强实现方法级别的 AOP 功能）输出模块原子能力。录制时，记录了发生调用的方法，入参、返回值和调用发生的顺序，以链式数据结构存储，回放时进行接口逻辑执行和子调用 mock。

null

凤凰录制回放

凤凰无需代码侵入修改，不需要修改应用启动参数，相对来说，对业务代码影响小，但是有应用结构要求。考虑成本和风险，以及我们的应用结构，闲鱼采用基于 Sandbox 的凤凰流量录制回放进行保障，变更上线流程卡点。

研发过程中，也会遇到各种各样的流量回放问题，比如用例过期，需要人工清除重新录制。我们现在是采用定时任务自动清除重新录制的方式解决。

下面是我们的一个场景例子：

null

链路层

在基于流量录制、回放比对的接口测试过程中，我们发现这种机制对于单应用的质量保障比较实用，但是对于跨应用的链路验证、核心写操作、外调用，以及系统重构类、方案改造等大需求就有些不足，链路级的解决解决方案接踵而至。

• Thub + 微服务

测试环境下，对于全链路上下游的强依赖，措施之一是开发测试服务化能力，建立自洽能力，测试环境下解藕对于外界诸如交易中台、菜鸟裹裹的依赖，测试环境能进行全链路闭环。

落地首要任务是梳理业务全链路节点：

- 主干链路上的每一个MTOP接口，以及接口的上下游依赖- 内部应用、中台应用、外部商家的依赖- 数据流以及TDDL梳理

null

业务梳理完整，进行测试服务化接口开发。下面是我们截取的一部分链路 case：

null

同时，诸如测试环境由于依赖方测试环境不稳定 block 测试的情况，我们提供测试服务化接口进行封装，暴露成下单、验货等服务化能力内置于闲鱼质量平台，用于开发、测试在研发过程中使用。

• 天算平台

天算平台，利用影子库，全链路压测的模式，线上业务数据和测试数据隔离，测试库 copy 线上库一部分数据。主要实现的方式是将线上的场景进行固化仿真，全链路执行，并且在执行的过程中进行所有数据变更的比对，用户可以选择任何代码版本的基线和变更版本进行对比。

null

天算能力基本能满足闲鱼的交易链路，闲鱼建立了主链路相关影子库，影子链路正在调试中，用于交易服务端的全链路巡检。同时，影子链路有诸如业务变更导致影子数据过期的问题，这个方案则主要是用于业务比较稳定的业务，新业务或者不断迭代更新的业务并未 all in 这个方案。

总结

综上，目前闲鱼交易，接口层用基于 jvm-sandbox 的流量录制方案, 日常巡检利用影子链路，研发过程自测、链路自动化用业务编排服务化能力。

展望

在基建完善的基础上，我们将继续探索 flutter 以及服务端的全端智能化方向的测试解决方案，希望让更多技术小二从重复劳动中释放出来，从治、防、控，三层质量网，保障闲鱼交易，让用户在闲鱼放心的卖卖卖、买买买。期待和大家一起交流业内的不同测试方案！同时感谢 doom、sandbox、凤凰、天启、暴雪、全链路压测、Thub 等团队提供的能力支持！

本文转载自：闲鱼技术（ID：XYtech_Alibaba）

原文链接：闲鱼如何保障交易链路质量