转转流量录制与回放的原理及实践

百年笑料

1需求背景2流量录制和回放概念2.1流量录制2.2流量回放3Repeater实现原理3.1流量录制和回放逻辑如何织入3.2流量录制和回放的核心代码4Repeater落地实践4.1改造点4.2线上环境录制5总结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)。流量的录制过程就是把入口调用和子调用绑定成一次完整的记录。    /**     * 获取商品价格，先从redis中获取，如果redis中没有，再用rpc调用获取，     * @param productId     * @return     */    public Integer getProductPrice(Long productId){ //入口调用        //1.redis获取价格        Integer price = redis.get(productId); //redis远程子调用        if(Objects.isNull(price)){            //2.远程调用获取价格            price =  daoRpc.getProductCount(productId); //rpc远程子调用            redis.set(productId, price); //redis远程子调用        }        //3.价格策略处理        price = process(price); //本地子调用        return price;    }    private Integer process(Long price){        //价格策略远程调用        return logicRpc.process(productId); //rpc远程子调用    }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不相等，那么次此流量回放标记为失败。下图是转转流量回放平台的流量回放的线上效果，帮助理解流量回放概念明白流量录制和回放概念后，下面看看业务无感实现流量录制和回放的实现原理。3Repeater实现原理Repeater架构图RepeaterConsole模块流量录制和回放的配置管理心跳管理录制和回放调用入口Repeateragentplugin模块：Repeater核心功能是流量录制和回放，其实现核心是agent插件，开源框架已经实现redis、mybatis、http、okhttp、dubbo、mq、guavacache等插件。由于录制和回放逻辑是以字节码增强的方式在程序运行时织入，所以无需业务编码。换句话说，agent技术是业务无感的关键。下面我们就进入无感的关键环节，介绍Repeater如何织入流量录制和回放逻辑代码，以及梳理流量录制和回放的核心代码。3.1流量录制和回放逻辑如何织入用一句话来说，Repeater本身并没有实现代码织入功能，它依赖另一个阿里开源项目JVM-Sandbox。详细来讲，Repeater的核心逻辑录制协议基于JVM-Sandbox的BEFORE、RETRUN、THROW事件机制进行录制流程控制。本质上来说，JVM-Sandbox实现了javaagent级别的springaop功能，是一个通用增强框架。JVM-Sandbox的基于字节码增强的事件机制原理见下图：上图以add方法为例，揭示JVM-Sandbox增强前后的代码变化，方便大家理解。下面的代码是对图中增强代码相关重点的注释public int add(int a, int b) {        try {            Object[] params = new Object[]{a, b};            //BEFORE事件            Spy.Ret retOnBefore = Spy.onBefore(10001,                    "com.taobao.test.Test", "add", this, params);            //BEFORE结果可以直接返回结果或者抛出异常，是实现mock（阻断真实远程调用）的关键            if (retOnBefore.state == I_RETURN) return (int) retOnBefore.object;            if (retOnBefore.state == I_THROWS) throws(Throwable) retOnBefore.object;            a = params[0];            b = params[1];            int r = a + b;            //RETRUN事件            Spy.Ret retOnReturn = Spy.onReturn(10001, r);            if (retOnReturn.state == I RETURN)return (int) retOnReturn.object;            if (retOnReturn.state == I_THROWS) throws(Throwable) retOnReturn.object;            return r;        } catch (Throwable cause) {            //THROW事件            Spy.Ret retOnIhrows = Spy.onThrows(10001, cause);            if (retOnThrows.state == I RETURN)return (int) retOnThrows.object;            if (retOnThrows.state == I THROWS) throws(Throwable) retOnThrows.object;        throws cause;        }    }由上可知，Repeater是利用jvmagent字节码增强技术为目标方法织入BEFORE、RETRUN、THROW逻辑。3.2流量录制和回放的核心代码既然Repeater利用JVM-Sandboxaop框架编写流量录制和回放逻辑，那么让我们看看它的核心代码doBefore。先来一张流程图。再重点介绍doBefore和doMock的核心代码，它们是实现录制和回放的关键，注意阅读注释。为了方便理解，我对开源代码做了大量删减，只保留核心逻辑。    /**     * 处理before事件     * 流量录制时记录函数元信息和参数，缓存录制数据     * 流量回放时，调用回放逻辑，直接返回录制时的数据，后面会对processor.doMock进行展开讲解     * @param event before事件     */protected void doBefore(BeforeEvent event) throws rocessControlException {        // 回放流量；如果是入口则放弃；子调用则进行mock        if (RepeatCache.isRepeatFlow(Tracer.getTraceId())) {            processor.doMock(event, entrance, invokeType);            return;        }        //非回放流量，进行流量录制，主要元信息、参数、返回值        Invocation invocation = initInvocation(event);        //记录是否为入口流量        invocation.setEntrance(entrance);        //记录参数        invocation.setRequest(processor.assembleRequest(event));           //记录返回值        invocation.setResponse(processor.assembleResponse(event));    }         @Override    public void doMock(BeforeEvent event, Boolean entrance, InvokeType type) throws rocessControlException {          try {                    //通过录制数据构建mock请求           final MockRequest request = MockRequest.builder().build();          //执行mock动作          final MockResponse mr = StrategyProvider.instance().provide(context.getMeta().getStrategyType()).execute(request);          //根据mock结果，阻断真实远程调用          switch (mr.action) {              case SKIP_IMMEDIATELY:                  break;              case THROWS_IMMEDIATELY:                  //直接抛出异常，映射到JVM-Sandbox的事件机制原理的add函数                  //也就是代码走到if (retOnBefore.state == I_THROWS) throws(Throwable) retOnBefore.object;                  //而不再执行后面的代码(JVM-Sandbox框架机制，调用如下代码会触发阻断真实调用)                  rocessControlException.throwThrowsImmediately(mr.throwable);                  break;              case RETURN_IMMEDIATELY:              //直接返回录制结果，映射到JVM-Sandbox的事件机制原理的add函数,同理,也不再执行后面的代码(阻断真实调用)                  rocessControlException.throwReturnImmediately(assembleMockResponse(event, mr.invocation));                  break;              default:                  rocessControlException.throwThrowsImmediately(new RepeatException("invalid action"));                  break;          }      } catch (ProcessControlException pce) {          throw pce;      } catch (Throwable throwable) {          rocessControlException.throwThrowsImmediately(new RepeatException("unexpected code snippet here.", throwable));      }    }通过上面的2、3章节介绍了Repeater流量录制和回放业务无感的实现原理，下面说一下应用过程中需要哪些改造点。4Repeater落地实践4.1改造点Rpeater开源管理后台仅仅是个Demo，需要重新设计和实现。SCF（转转RPC框架）插件扩展，支持SCF应用的流量录制和回放。DB由MySQL改造为ES，Repeater原生使用MySQL作为流量录制和回放的数据库，仅用于Demo演示，性能和容量无法满足实际需求。Docker环境下频繁更换ip时不中断录制。回放结果Diff支持字段过滤。大批量回放。线上环境录制。4.2线上环境录制流量录制很大一部分应用场景在线下，但是线上也有录制场景。从流量录制的原理可知，由于要记录入口调用和各种远程子调用，开启流量录制后，对于该请求占用内存资源会大大增加，并且会增加耗cpu的序列化操作（用于上报流量录制结果）。既然流量录制是一个天然的耗内存和性能操作，对于线上服务的录制除了保持敬畏之心之外，还有设计一种机制减少录制时对线上服务的性能影响。下面开始介绍如果做到录制时减少对线上服务性能的影响。线上录制减少性能影响的方案：从流程上，线上录制需要申请。从技术上，与发布系统联动，为录制服务增加专门的节点进行录制，并且设置权重为正常节点的1/10，正常节点不会挂载流量录制代码。从回滚上，如果线上录制节点遇到问题，可以从发布系统直接删除录制节点。线上录制效果5总结本文旨在介绍Repeater流量录制和回放的实现原理，以及在落地过程中改造点，希望达到让大家懂原理、会使用、敢使用的目的。关于作者梁会彬，架构部，资深开发工程师。负责云平台、配置中心、权限系统、Repeater等基础组件。