得物流量录制回放实践

流量回放的思路

得物流量回放实施模式

在得物的整体QA体系中，流量回放短期更加聚焦回归性质的提效，未来希望探索更多新功能测试维度的提效。 

• 提测阶段卡点：聚焦核心场景，低成本验证每次提测对于核心场景的影响； 

• 测试阶段回归卡点：全量场景，重点追求覆盖场景全面性，验证新功能对历史功能的影响； 

• 预发环境回归：目前得物预发跟生产同库，未来会推动落地基于预发&生产环境的流量回放，尽可能拉近录制时环境和回放时环境的仿真差异，从而降低回放阶段的噪音影响；

得物迭代&项目时间轴

当前市面上的录制回放工具主要分两类，一类是诸如go replay之类通过网络抓包，录制流量，并提供回放功能。另一类如阿里开源的jvm sandbox repeater, 在应用进程内录制，可以录制到更精细的信息。例如某次数据库访问操作，某次对外的redis读写操作，等等。根据这些工具的特性分析，不难发现，go replay这类工具更适合做压测，jvm sandbox repeater这类工具能更好地支持测试回归工作。 

jvm sandbox repeater在回放时提供了两大类check点，一个是入口的返回数据，一个是子调用的多调用和少调用，包括子调用参数不一致等问题都能发现出来。后面这一点特性对得物业务来说是十分需要的功能，能够检测出一些潜在的风险。例如某个接口里面有一次数据库调用进行转账，某次迭代业务开发引入了bug造成两次数据库调用操作进行了两次转账，而入口的返回数据还是跟原来一致。这个例子中，如果业务幂等没做好极可能造成资损。这类问题可以通过jvm sandbox repeater发现出来。 

jvm sandbox repeater跟其他录制回放方案相比，最大的局限性在于只支持java程序。得物当前的后端服务是以java为主，因此这一点对我们来说不是一个阻碍点。 

综上所述，我们最终选择了以阿里开源的jvm sandbox repeater为基础，进行得物流量录制回放平台的建设。

结合得物的实际情况，我们目前的技术架构如下图所示：

得物流量录制回放平台架构图

沙箱&repeater module版本更新：通过oss发布 

管控面后台：springboot程序，承载录制回放平台核心功能 

录制流量存储：写入ES

录制环境：通常在生产环境录制，其他环境也支持录制 

回放环境：得物专门构建了一个容器环境用于流量回放。目的是为了解决业务配置在录制和回放时不一致导致失败噪音的问题（得物大部分业务配置是通过中间件ark实现，ark是得物的配置中心）。当前暂时由测试同学进行业务配置一致性check，后续平台会提供自动check功能

我们在平台建设中也遇到了技术上的挑战，下面列举了部分我们在平台建设中踩过的坑和我们想到的解法。包括我们目前还没有很好解决的挑战性问题。

在平台建设过程中，我们发现开源的的jvm sandbox存在一些bug。对于这些问题，我们在使用过程中进行了修复。这里仅举两个例子。 

1. 录制采样率不均衡 

开源版本的采样率算法不均衡，会造成一段时间内流量都采集，一段时间都采集不到的情况。跟我们的预期不符。因此我们在使用过程中修改了采样率算法，使得每笔流量是否录制是否采样的判断逻辑都符合我们设置的采样概率。 

2. java入口插件JavaEntrancePlugin bug导致java入口的配置动态变更时无法rewatch

上述第6-7行部分代码位置应该移动到第10行代码上方，否则无法在运行时重新监听配置变化。

开源的jvm sandbox repeater提供了最基础的一些插件能力支持。但是在得物业务应用上使用后我们发现尚有很多能力缺失。因此我们梳理了得物当前需要的插件能力，按使用率排了优先级进行了插件能力的扩展，让更多得物应用可以使用这套方案进行回归。下图得物当前未支持的插件能力，我们也计划在未来一到两个月内补齐。 

注：下图部分插件能力开源版本只支持部分功能，例如mq入口不支持，dubbo只支持录制，回放不支持, http只支持入口不支持子调用，等等。部分支持的图中均设置为N。

得物流量录制回放平台jvm sandbox repeater插件能力扩展现状

得物的一些服务接口，调用频率会比较低。而这个服务的其他接口调用频率很高。这种情况下，开源版本的统一采样率就满足不了我们需求了，因此我们对采样逻辑进行了改造，用户在管控面上可以为每个接口单独设置采样率。这样就可以单独为调用频率低的接口设置百分百采样。

支持不同接口不同采样率功能

在平台第一版上线后，用户反馈筛选流量比较耗时。因此我们设计了流量打标的功能，用户可以设置流量打标规则，如果录制的流量符合设置的规则，就会打上一个标签。在筛选的时候可以按标签过滤，进行用例的筛选和沉淀。 

如下图所示，用户可以根据入口调用的请求，响应，也可以根据子调用的请求，设置打标规则。

支持流量打标功能

当前，这部分的打标规则创建目前还是靠人工完成，并且依赖用户对业务的理解经验，还是半自动化的。后续我们希望通过一些大数据分析，特征提取，聚类算法，进行全自动打标的尝试，希望能进一步降低用户在这块工作上的投入成本。

在真正实现全自动化用例沉淀之前，我们同时也在思考能否用一些自动化功能替换部分用户人工筛选流量沉淀用例的操作。我们设计了一个自动沉淀的功能。用户在设置打标规则后，可以指定希望沉淀的标签和希望沉淀的用例集。平台检测到符合条件的一条流量后就会作为用例自动放入指定用例集中沉淀下来。 

新用例自动沉淀功能

回放失败排查提效是一个流量回放最难解决的问题。一方面因为原版repeater上报的信息不够丰富，很多情况需要看日志才能排查，另一方面目前业界也没有比较好的，公开的方法论。我们对此进行了一些初步的探索。当前我们的方法可以一定程度上提效。当然，后面还需要结合实际使用情况进行持续地探索。

我们对回放失败的场景自动进行了以下分类，帮助排查人员聚焦定位问题，同时通过上报更丰富的数据信息提供排查指引。下表从上往下按优先级从高到低排列。界面展示以优先级高的为准，避免冗余无效信息干扰排查。 

回放轨迹帮助排查

根据我们一段时间的实际使用，我们发现在回放失败的用例中，有很大一部分是因为业务代码正常变更导致。这类问题导致的回放失败是正常现象，我们会认为这个用例失效需要等发版后重新录制。其相关的业务代码逻辑应当由本次迭代的新功能的测试用例覆盖。

对于这些失效的流量回放用例，一开始我们是通过业务测试进行人工替换的。但是我们发现这部分工作量比较大。因此我们开发了自动化替换功能。业务测试只需要指定需要自动替换的用例，后续工作都可以通过平台自动完成。 

异步线程的录制回放，我们主要遇到了两个问题：

• parallelStream ttl不支持问题, 我们使用jvm sandbox通过对 java.util.concurrent.ForkJoinTask的动态切面进行了解决。

• 入口主线程不等子线程执行完就返回的异步场景，我们当前的策略是用户可配置对异步子线程的多调用忽略，只关注主线程的执行情况。这一方式虽然可以提升这种异步线程场景的回放成功率，但是损失了异步子线程业务逻辑的回归能力。我们思考的另外一个思路是把子线程作为一个新的入口。但是这个方案对原有repeater体系破坏较大需要较多的改动量。我们目前依然在探索一个比较好的方案去解决这个异步场景的问题。

异步线程的短期解决方案能让平台问题不成为业务推进的阻碍点，但是依然需要进一步研究更好的解决方案，让异步线程的回归覆盖率能够提升上去。

因为在得物预发/灰度环境是联通生产环境的数据库和下游应用，因此对于预发进行不mock的回放，特别是对只读接口进行不mock的回放能够在上线前的最后阶段进行一次兜底的回归校验。但是这个方案存在一定的风险。最难解决的问题是，当前是只读的接口难以保证后续的变更不会引入写操作。在当前阶段开放这一功能会引入额外的资损类风险敞口。对此问题，每次回放前都进行人工校验可能可以解决，但是又引入了极大的效率问题。如何高效地保证在预发/灰度环境进行不mock流量回放不会产生资损风险，是一个难度颇高的问题。当前得物在这一领域还处于探索阶段，有一些初步的想法，但是距离真正落地还有一段距离。 

流量录制回放作为测试领域的一个新生事物，在诞生初期就吸引了广大测试同仁的关注，各个公司也对此进行了一些实践。得物对流量录制回放的实践还属于比较初期的阶段，一些问题的解法也在探索中 (例如如何在预发/灰度回放而不引入资损)。但是通过一段时间的滚动运行，目前已经看到了一些流量录制回放在业务迭代中产生了价值，发现了一些隐藏bug。期望我们能在不断的实践中把得物的流量录制回放体系建设得越来越完善，产生更多的业务价值。