为什么要做引流测试
目前为止大部分的测试是在测试环境下，通过模拟用户的行为来对系统进行验证，包括功能以及性能。在这个过程中，你可能会遇到以下问题:
用户访问行为比较复杂，模拟很难和用户行为一致，模拟不够真实;
线下模拟场景有限，会出现业务覆盖不全的情况。
引流测试就是为了解决以上问题，通过把线上的真实流量复制到线下环境，解决测试环境模拟不够真实，或覆盖不够全面的问题。
引流的做法
目前不少公司对引流测试进行了实践，主要有以下4种引流方式：
以上几种办法各有利弊，有的是需要自己开发相应的工具来支持。在做URS产品性能测试过程中，考虑到都是HTTP类型的请求，且大部分的请求为读请求，使用tcpcopy工具可以满足要求，且成本比较低。在介绍基于tcpcopy的引流测试在项目中怎么应用之前，我们先来介绍下tcpcopy这个工具。
tcpcopy介绍
tcpcopy是一种请求复制(基于tcp的packets)工具，其应用领域较广。tcpcopy主要有如下功能：
分布式压力测试工具，利用在线数据，可以测试系统能够承受的压力大小,同时提前发现一些bug;
对于后端的短连接，请求丢失率非常低(1/10万)，可以应用于热备份;
普通上线测试，可以发现新系统是否稳定，提前发现上线过程中会出现的诸多问题，让开发者有信心上线;
对比试验，同样请求，针对不同或不同版本程序，可以做性能对比等试验;
利用级联tcpcopy，构造无限在线压力，满足中小网站压力测试要求。
图1 tcpcopy工具流量复制过程
在线服务器启动tcpcopy进程，在IP层捕获数据包，通过数据链路层发包;
复制的包到了被测试服务器，经过协议栈的处理，到达应用进程，进程处理完，响应的包通过路由转发给辅助服务器;
辅助服务器捕获到路由过来的响应包，去掉包的body，返回给在线服务器。
整个过程是一个闭环，引流的过程不会干扰用户的请求，复制的请求的响应，也不会返回给用户。
URS引流测试实践
接下来讲述下tcpcopy是怎么在URS这个产品中运用起来的，通过下面的案例来分享下整个引流测试的过程。
案例：本人经历过一个项目主库的性能验证，优化及替换
背景介绍：
该产品的线上数据库服务器年限比较长，配置比较老，另外数据库服务器在瞬时访问量比较大的时候，会出现性能下降的问题。为了提高数据库服务器的稳定性，以及对数据库的参数进行一些优化，产品方计划采用新的数据库服务器来代替线上服务器，且在上线先进行一轮优化，保证新的数据库满足目前的性能需求的情况下，再替换掉线上的数据库。
测试的难点
新数据库的数据量基本要和线上是一致的，否则测试的意义不大；
仅仅依靠线下的请求模拟是不够的，需要线上真实的流量来验证；
需要提供突发流量，高于线上的流量等场景来验证新的数据库服务器是否能够处理突发情况。、
测试方法
利用tcpcopy工具，搭建引流测试环境，利用线上真实流量，倍数流量，突发流量，验证新的163主库的性能，并与DBA协作，进行参数优化和验证。
测试成果
通过复制真实流量，有效验证了现有数据库的性能，并且通过调整流量，对数据库造成多样的负载，进而对数据库进行参数优化，保证了数据库的性能和稳定性
引流测试方案
为确保引流测试顺利实施，先制定一个详细的方案，方案主要包括业务选取，环境搭建，结果分析和验证等，接下来逐一介绍这些部分。
测试环境搭建
需要先根据线上环境部署架构来确定我们的引流测试环境应该搭建成什么样子。下面为引流环境架构示意图。先简单介绍下：
环境部署如下：
图2 测试环境部署
线上Nginx服务器上安装部署tcpcopy，负责把指定的流量复制到测试环境；
引流环境的数据库通过导入线上的数据库的备份初始化数据，同时通过做成线上的备库，保持和线上数据库的同步。每次要开展引流测试的时候，先剥离出来，做完测试之后再和线上数据库进行同步；
为了避免引流操作更新部分缓存，导致弄脏了线上的缓存数据，同时为了控制穿透到数据库的量，搭建了单独的缓存服务器集群；
搭建mock服务器，把短信，邮件，将军令等服务都mock掉，避免触发到这些操作，影响用户，另外也可以通过在前端Nginx进行请求过滤，来屏蔽可能触发这些操作的请求。
引流业务选取及过滤
环境搭建好以后，需要确定复制哪些请求到测试环境，以下三类请求是不建议引流的， 需要屏蔽掉。
无法处理的请求
测试环境因为缺少数据或者缺少外围系统等，导致这类请求在测试环境执行会报错，因此需要过滤掉。
连续相关的请求，或者有状态的请求
连续相关的请求因为存在状态，请求之间的数据有传递，导致复制过去的话，业务处理会报错，也需要过滤掉。举个简单的例子，比如登录操作，服务端可能会需要填写验证码，复制过来的请求的验证码和原始的请求是不一样的。如果登录操作也复制过去了，验证码是无效的。
写请求
写请求会新增数据，且一般写请求的量比较小，请求大都有状态，不是很适合引流。如果写请求的影响很小，也需要进行写请求的测试，也可以进行复制，但是要特别注意，不要弄脏线上环境的数据，或者对线上的业务有影响。
请求过滤可以通过以下方式实现：
Nginx配置Location进行过滤
location ~* ^/services/(otplogin|onlyotplogin|qrcodeotpauth|onlyotplogin|ticketotpauth) {expires -1;return 200 'request mocked\n';}
把需要屏蔽的请求，直接返回200。这里要经过仔细筛选。上面的配置只是一个示例，实际项目可以按照规则来过滤。
搭建mock服务器进行过滤 请求的处理过程中，如果会调用第三方系统，这个时候可以搭建mock服务进行屏蔽。
引流测试执行
环境准备好之后，就可以执行引流测试了，引流测试过程会包含以下步骤：
配置检查
Nginx的Location配置，避免复制了不合适的请求到测试环境；
应用配置是否正确，一切会影响线上用户的配置都需要调整；
缓存服务器的配置是否正确，确认使用的是测试环境的实例，且能正常访问；
数据库的配置是否正确，确认使用的是测试数据库，且能正常访问；
Mock服务器是否正常，服务的返回是否正常等；
以上检查完成后，在测试的Nginx上利用curl工具手动发送请求验证环境。
启动辅助服务器intercept
启动命令
sudo ./bin/intercept -i 网卡 -F 'tcp and src host ${测试Nginx IP地址} and src port ${测试Nginx端口} ' -p ${intercept的监听端口} -d
可以不指定监听端口使用默认的36524，如果要启动多个实例，端口是必须指定。启动后通过netstat –an | grep 监听端口，检查端口是否正常。
检查error_intercept.log日志文件 检查文件有没error和fatal级别的错误信息。
绑定在不同的CPU上
如果intercept进程的CPU使用率比较高，需要启动多个intercept并且绑定在不同CPU上，可以通过执行taskset -cp ${cpu $pid来设定，其中
cpu为CPU的编号，
pid为intercept的进程号。
配置路由并验证
在测试环境的Nginx上增加默认网关，设置为intercept的地址： 命令：route add default gw ${intercept的IP}设置好路由信息后，可以找一台测试机器，telnet测试环境Nginx的服务端口80，如果能够建立连接，说明路由信息没生效，测试环境Nginx服务器的包没有转发给辅助服务器，可以找SA的同事帮忙协助，确定路由要怎么配置。
启动tcpcopy
在线上Nginx服务器，启动tcpcopy命令：
sudo bin/tcpcopy -F 'dst port ${线上nginx端口} and dst host ${线上nginx IP} ' -i 网卡 –x ${线上nginx端口} -${测试环境nginx的IP}:{测试环境nginx端口} -s ${intercept的IP} -n 1 -d
启动后，检查error_tcpcopy.log日志文件有无error和fatal级别的错误。
请求验证
对线上nginx和测试nginx的日志进行对比，检查请求是不是已经复制到测试环境，请求返回的大小和状态码等是否正常，同时，检查应用服务器是否有错误日志。如果有错误，影响到了线上环境，或者错误很多，先停止引流，解决报错。
系统监控
引流过程中，可以利用哨兵系统对线上Nginx服务器，测试服务器的系统资源，应用服务器、数据库进行性能监控。
调整流量
引流过程中，会根据测试环境的负载，调整复制的流量，通过修改tcpcopy的启动参数来调整。-n 设置复制的倍数，-r 可以设置复制的比例(1<r<100)。
引流测试结果分析
前面的章节介绍了引流的方案和执行过程。引流开始后，我们怎么去分析系统当前的性能呢？在数据库的性能验证的案例中，我们一方面要知道当前的业务负载情况，同时也需要知道应用和数据库的各项资源的使用情况。
如何监控业务指标
业务性能指标，主要是通过对nginx的日志进行分析来完成，分析能够监控到所有请求，以及单个请求的TPS，错误，平均响应时间，最大响应时间4个重要的指标。
图3 业务指标监控
例如在图3中，可以实时监控到***login这个接口的TPS，ERRORS，AVG_RT，MAX_RT四个指标。
如何监控数据库
数据库可以通过在类似于zabbix系统进行配置性能监控。引流过程中，可以实时监控数据库的各项性能指标，观察是否有异常，进而调整复制的流量。系统资源指标：CPU，内存，网络，磁盘等常规资源监控指标。数据库性能指标：数据库各内存池使用率和命中率，Average active session，Database Time Ratio， 会话连接数，IO读写吞吐量，IO读写请求次数，执行次数，资源使用率等。
通过监控这些指标，定位数据库的性能瓶颈，让DBA进行优化和调整，再复测。找出最佳的配置。这些性能指标，我们可以通过哨兵系统来实时监控。
例如，我们在引流过程中监控到的连接数，活跃的会话，内存池的使用情况如图4所示：
图4 内存池大小的实时监控
图4是对内存池大小的实时监控，可以监控到PGA，buffer_cache内存，共享池内存，large_pool内存，java_pool内存的实时使用量。
图5 数据库的会话连接数的实时监控
案例结果分析
引流过程中，通过调整流量，并且实时监控业务性能指标和数据库的各项指标是否正常。在业务性能指标，特别是响应时间在合理的范围内，数据库的各项性能指标也在合理的范围内，得到业务的TPS和数据库的负载情况，作为数据库性能评估的结果。
例如，在数据库的引流测试中，通过线上多台Nginx复制5倍的流量到引流环境，同时disable掉部分缓存，请求直接穿透到数据库，在这样的负载下，得到的数据库的性能数据如下:
本文章为作者原创
?禁止?
其他公众账号转载，若有转载，请标明出处
