1 需求背景

　　随着转转业务规模和复杂度不断提高，业务服务增加，服务之间依赖关系也逐渐复杂。在开发和测试中遇到如下问题：

　　参数构造：转转接口测试平台可以很方便调用SCF（转转RPC框架），但是接口的参数很多是复杂model，手动构造参数成本不小，希望能够录制稳定测试环境流量，从流量中抽取接口参数，方便使用者选择参数进行接口测试。

　　压测流量构造：转转是二手电商平台，有许多促销活动的压测需求，人工构造压测流量既不能模拟真实访问，又成本高昂。所以有录制线上流量的需求，然后压测平台通过策略二次加工形成压测case。

　　自动化回归测试：业务迭代速度很快，每次迭代会不会影响原有逻辑？希望有一个平台能够提供筛选保存case，自动化回归，case通过率报告通知等能力。

　　这些问题每个互联网公司都会遇到，如何才能优雅解决这些问题呢？首先定义一下优雅：不增加业务成本，业务基本无感，对业务性能影响要足够小。阿里开源的jvm-sandbox-repeater（简称Repeater）正是为解决这些问题而生，能够做到业务无感，但是性能问题需要特别定制处理。本文重点介绍：

　　Repeater流量录制和回放业务无感实现原理（第2、3章节）

　　线上服务流量录制时，如何减少对正常业务的性能影响（第4章节）

　　希望能够揭秘Repeater如何做到业务无感的流量录制和回放，进而让使用流量录制的同学对Repeater内部做了哪些工作以及对性能有哪些影响做到心中有数，最后介绍在流量录制时，为了保证对线上服务的性能影响相对可控，我们做了哪些工作，让大家会用敢用。

　　2 流量录制和回放概念

　　2.1 流量录制

　　对于Java调用，一次流量录制包括一次入口调用(entranceInvocation)（eg：HTTP/Dubbo/Java）和若干次子调用(subInvocations)。流量的录制过程就是把入口调用和子调用绑定成一次完整的记录。

　　getProductPrice流量录制图解

　　以获取产品价格方法为例，流量录制的内容简单来说是入口调用（getProductPrice）的入参和返回值，远程子调用（redis.get,daoRpc.getProductCount,redis.set,logicRpc.process）的入参和返回值，用于流量回放。注意并不会录制本地子调用（process）。

　　下图是转转流量回放平台录制好的单个流量的线上效果，帮助理解流量录制概念。

　　2.2 流量回放

　　流量回放，获取录制流量的入口调用入参，再次发起调用，并且对于子调用，直接使用流量录制时记录的入参和返回值，根据入参（简单来说）匹配子调用后，直接返回录制的数据。这样就还原了流量录制时的环境，如果回放后返回值和录制时返回值不一致，那么本条回放case标记为失败。还以getProductPrice为例，假设录制时入口调用参数productId=1，返回值为1；redis.get子调用参数productId=1，返回值为1。那么回放时，redis.get不会访问redis，而是直接返回1。假设该函数有逻辑更新，回放返回值是2，与录制时返回值1不相等，那么次此流量回放标记为失败。

　　下图是转转流量回放平台的流量回放的线上效果，帮助理解流量回放概念

　　明白流量录制和回放概念后，下面看看业务无感实现流量录制和回放的实现原理。

　　3 Repeater实现原理　

　　Repeater架构图

　　Repeater Console模块

　　流量录制和回放的配置管理

　　心跳管理

　　录制和回放调用入口

　　Repeater agent plugin模块：Repeater核心功能是流量录制和回放，其实现核心是agent插件，开源框架已经实现redis、mybatis、http、okhttp、dubbo、mq、guava cache等插件。由于录制和回放逻辑是以字节码增强的方式在程序运行时织入，所以无需业务编码。换句话说，agent技术是业务无感的关键。

　　下面我们就进入无感的关键环节，介绍Repeater如何织入流量录制和回放逻辑代码，以及梳理流量录制和回放的核心代码。

　　3.1 流量录制和回放逻辑如何织入

　　用一句话来说，Repeater本身并没有实现代码织入功能，它依赖另一个阿里开源项目JVM-Sandbox。详细来讲，Repeater的核心逻辑录制协议基于JVM-Sandbox的BEFORE、RETRUN、THROW事件机制进行录制流程控制。本质上来说，JVM-Sandbox实现了java agent级别的spring aop功能，是一个通用增强框架。JVM-Sandbox的基于字节码增强的事件机制原理见下图：

　　上图以add方法为例，揭示JVM-Sandbox增强前后的代码变化，方便大家理解。下面的代码是对图中增强代码相关重点的注释

　　由上可知，Repeater是利用jvm agent字节码增强技术为目标方法织入BEFORE、RETRUN、THROW逻辑。

　　3.2 流量录制和回放的核心代码

　　既然Repeater利用JVM-Sandbox aop框架编写流量录制和回放逻辑，那么让我们看看它的核心代码doBefore。先来一张流程图。　　

再重点介绍doBefore和doMock的核心代码，它们是实现录制和回放的关键，注意阅读注释。为了方便理解，我对开源代码做了大量删减，只保留核心逻辑。

　　4 Repeater落地实践

　　4.1 改造点

　　Rpeater开源管理后台仅仅是个Demo，需要重新设计和实现。

　　SCF（转转RPC框架）插件扩展，支持SCF应用的流量录制和回放。

　　DB由MySQL改造为ES，Repeater原生使用MySQL作为流量录制和回放的数据库，仅用于Demo演示，性能和容量无法满足实际需求。

　　Docker环境下频繁更换ip时不中断录制。

　　回放结果Diff支持字段过滤。

　　大批量回放。

　　线上环境录制。

　　4.2 线上环境录制

　　流量录制很大一部分应用场景在线下，但是线上也有录制场景。从流量录制的原理可知，由于要记录入口调用和各种远程子调用，开启流量录制后，对于该请求占用内存资源会大大增加，并且会增加耗cpu的序列化操作（用于上报流量录制结果）。既然流量录制是一个天然的耗内存和性能操作，对于线上服务的录制除了保持敬畏之心之外，还有设计一种机制减少录制时对线上服务的性能影响。下面开始介绍如果做到录制时减少对线上服务性能的影响。

　　线上录制减少性能影响的方案：

　　从流程上，线上录制需要申请。

　　从技术上，与发布系统联动，为录制服务增加专门的节点进行录制，并且设置权重为正常节点的1/10，正常节点不会挂载流量录制代码。

　　从回滚上，如果线上录制节点遇到问题，可以从发布系统直接删除录制节点。　　

　　线上录制效果

　　5 总结

　　本文旨在介绍Repeater流量录制和回放的实现原理，以及在落地过程中改造点，希望达到让大家懂原理、会使用、敢使用的目的。