干货 | 携程QA-流量回放系统揭秘

作者简介

康猛，携程网站运营中心资深技术支持工程师。在互联网系统架构设计、后端开发、性能测试领域有多年实战经验。喜欢钻研新技术，善于转化研究成果，提升工作效率。

一、背景

众所周知，在产品迭代过程中，功能测试与性能测试是必不可少的两个环节。在产品上线的过程中，做容量预估离不开性能测试，在产品迭代过程中，测试Case覆盖率是功能测试必须要关注重要指标，甚至是一行代码的修改，没有经历过严格的功能与性能测试，都有可能导致大的生产故障。

近年来，携程生产环境应用改造项目逐渐增多，快速构造贴近生产的测试用例，压力可调的功能与性能测试场景，显得越来越不可或缺。

如何输出较大的压力源？

也许你心里已经涌现了很多现成方案，也许是ApacheBench，可是想要用ab模拟生产的上下文顺序会不会有点痛苦？也许你想到了JMeter，或者LoadRunner？暂且不说JMeter和LoadRunner二次开发封装上下文逻辑的复杂度，单就想想需要人工构造海量贴近真实生产场景的测试Case，就够让人头疼的了。

使用生产环境流量回放系统，可以使用生产环境的海量真实场景作为测试Case，天然解决了海量测试Case的构造问题；系统支持录制多倍的生产流量，在回放过程中支持加压多倍进行回放，解决了较大压力源构造的问题；此外，系统天然支持4层与7层协议，可以快速支持各种特殊应用需求；最后，系统跨平台的特性，也决定了系统具有较好的场景适配能力。

二、方案

流量回放系统，利用生产上现有真实流量进行镜像，原始流量依然回到生产环境的真实服务器，流量的镜像拷贝会分发到集群外的测试服务器上，在测试服务器上可以实现不同版本的功能测试，或者加压10倍进行性能压测。

流量回放系统的工作原理如下图：

一般极简的集群模式包含一套专用的负载均衡设备或者承担负载均衡角色的网络设备，以及一组提供具体服务的后端服务器，如上图Server1、Server2。

首先，系统向集群扩容一台机器，我们称之为“采集器”，这台“采集器”实现的基本功能是转发集群正常流量，将全部流经自己的流量，原样输出回到原集群中指定的一台或者多台后端应用服务器，比如Server1，实际上“采集器”可以监听到数倍于单台Server的流量。

同时，“采集器”将监听到的流量制作一份镜像拷贝，可以保存成离线文件的方式，也可以在线实时地将镜像流量转发到生产或者测试环境下任意网络可达的服务器上，保存的离线文件，可以在任意时间重新回放成离线的生产流量，直接转发或者修改后转发到任意网络可达的服务器上，在目标服务器（我们称之为“回放机”）上可以运行有版本差异的测试代码，以观察生产应用与测试应用的表现是否符合预期。

也许你会疑惑，这样难道不会导致Server1承担了两倍的流量吗？其实并不会，原因是在默认情况下，我们的生产环境中集群的Server的权重均为5，机器的权重以及比例，共同决定了集群流量的分配，当流量复制任务开始时，系统向集群中扩容一台“采集器”，其权重默认为5，同时，系统会调整Server1的权重为1，如此一番，则采集器与生产Server之间的权重比例将变成：采集器:Server1:Server2 = 5:6:5，这样既保证了采集器能录制到足量的数据，也保证了生产机器之间流量不会因过分叠加导致容量问题。

既然是在生产环境操作流量拷贝，紧急情况下的容灾恢复就显得非常重要，特别是当宿主机故障，或者应用Full GC导致健康检测踢出等场景下，如果系统不能感知到后端成员已经宕机，而继续将生产流量转发到已经故障的机器，则会导致这部分请求失败，从而导致故障，这就需要一种自我保护机制，在后端应用故障的场景下，引流任务能够自动识别并终止。

但是从另一方面，由于一次偶然的Full GC或者网络抖动等，导致机器被踢出集群，整个任务就立即终止又稍显敏感。在实际系统引流的过程中，当检测到引流目标机Server1宕机，会自动将任务暂停，连续3次探测Server1均失败，则判断Server1短时间内可能无法恢复，立即自动终止任务；这样既保证目标服务器宕机不会对生产环境造成持续影响，又照顾了偶发检测失败造成的任务终止过于敏感的问题。

三、系统

（1）系统总体上包含“引流任务设置”，“回放任务设置”，“任务查询三个模块”；

（2）设置引流任务，需要用户提供的信息主要包含AppID、PoolID以及引流的目标机，也就是要Copy哪台机器的流量；系统会根据APP信息和Pool信息进行各种关联校验，并自动获取服务器信息，供应用选择；

（3）最后设置开始与结束时间，即可快速开始引流任务；

（4）设置一个回放任务。设置回放任务，可以通过在任务列表页的最后一列，点击“去回放”，会自动跳转到回放任务设置页，并将流量复制任务的相关参数自动填充，需要用户填的只有回放系统的主机头HOST，回放目标IP，回放倍率等跟任务本身有关的信息；

（5）查看监控数据。复制/回放任务的全过程，都可以实时的获取到应用的各种维度监控数据，系统已经集成了一些常用的监控指标，比如CPU、内存、连接数等信息，也将ES系统集成到系统中，并自动设置了一些常用参数，用户可以方便的查看在流量复制与回放阶段应用的请求/响应状态码、响应时间等数据。

四、项目

项目1：内网某服务的流量复制

该项目中，系统为内网某服务集群扩容一台采集器，采集器将正常流量，转发回原集群中正常提供服务器的机器上，并将这份流量拷贝两份镜像，一份以抓包文件的方式，保存为pcap格式的抓包文件，另一份以请求报文的形式，保存成离线文本文件。

以应用服务器的视角，可以看到所有通过采集器进入的流量：

项目2：内网某服务流量回放

该项目中，系统将事先录制好的离线流量文件，转换为请求的形式，回放到集群外用于多版本对比的测试服务器上：

五、总结与展望

当前流量回放系统能够比较便捷的获取真实生产环境海量用户请求的流量镜像数据，既有效保存了原集群流量无修改无损耗，又解决了人工构造的测试数据不能拟合生产真实场景的问题；除此之外，系统具有良好的跨平台支持特性，不管是Windows平台的应用还是Linux平台的应用，均能够镜像出完整生产数据；还有一点很重要，系统支持7层协议，支持自定义各种HTTP Header定制与修改。

技术平台的生命力需要不断的打磨才能变得更好。接下来我们也在寻求使用更少服务集群场景侵入的方式，获取生产流量镜像，比如将“采集器”下放到“目标回放机”上共存，以期完美解决直连应用场景。