基于TCPCopy的Dubbo服务引流工具-DubboCopy

TCPCopy顾名思义,就是一个可以将tcp流量复制的工具(其实也可以复制UDP)。有了这样一个工具,我们就可以真实的复制线上流量,然后将这些流量复制到我们的测试服务器上。这样就可以很容易模拟线上真实用户的访问,做一些功能上的,性能上的测试。而且经过实际测试发现TCPCopy对线上机器的资源消耗也是极低的。

借助这么一个工具,我们可以比较容易的实现一些比较有意思的功能。比如我们现在我们的应用都已经服务化了,那么我们在一次需求变更之后,或者一次性能优化之后,我们如何最快的知道该服务功能是否正确,性能优化是否达到期望呢?当然,我们可以使用一些性能压测工具模拟大量请求,但是有的时候来自线上真实的流量或许能最真实的反应实际情况。

OK,那我们可以使用TCPCopy将线上流量复制到线下测试环境。在我们使用这种方式的时候,又发现另外一个问题。我们很多时候进行引流的时候,只希望复制部分服务的流量。比如我们想将下单服务的引入进来,但并不想将支付订单的流量也引入进来,因为这样我们可能需要搭建一个很复杂的环境。另外, 有的时候我们只想针对单个服务进行测试,这样的话只复制单个服务或符合条件的流量,可以更好的隔离我们的测试,隔离其他服务对我们测试期望的影响。基于这些原因,我们就不能直接的将TCPCopy的所有流量全部直接的引入测试环境。为此我们开发了一个proxy -- DubboCopy(因为我厂的服务框架是基于Alibaba开源的Dubbo)。

下面第一个图是使用TCPCopy的原始结构:

使用DubboCopy之后的结构:

DubboCopy的目的主要有:

1. 降低服务流量复制的使用门槛

2. 基于多重维度的服务流量复制

3. 监控各种性能指标,收集服务响应结果

那么下面我们就分几个部分介绍我们是如何实现的。

降低服务流量复制的使用门槛

其实TCPCopy的使用还是有一些门槛的,有一些网段的限制,需要添加一些路由表等。并且TCPCopy没有提供rpm包等,如果从零搭建一套流量复制环境,还是要费一番周折。而我们想达到的是一键引流,对使用方透明。首先我们自己build了TCPCopy的RPM放入公司的仓库。然后我们请求OPS协助提供了在线上机器启停TCPCopy的HTTP接口。这样一来用户使用该功能的时候,就基本上感受不到TCPCopy的存在。这里说点题外话:『基础设施服务化,流程API化』是提高生产效率非常有效的办法,感谢兄弟部门的协作让整个流程畅通起来。

另外一点是,因为TCPCopy直接面对的是我们提供的这个proxy,不会直接跟线下测试服务器交互,所以一些配置在proxy上配置,也对使用者透明,继续降低了使用的复杂度。

可以基于多重维度的服务流量复制

这一点是我们的主要目的。用户使用该功能的时候,只需要在界面上选择需要复制的服务,并且指定目标机器。这时DubboCopy就会使用调用接口在线上机器启动TCPCopy。需要注意的是,我们复制的流量可能来自线上多台机器,而我们的DubboCopy也是部署有多台。那么在调用启动接口的时候,会使用类似一个负载均衡的方式发送不同的命令到不同的线上机器,将流量均衡的复制到各个DubboCopy。

当TCPCopy将流量复制到proxy后,我们可以部分解析Dubbo的协议,从中提取出服务,方法等信息。有了这些信息我们就可以根据预先配置好的信息选择要将数据包复制到哪些测试机。DubboCopy是使用Netty开发的,接收到TCPCopy复制过来的流量之后,我们部分的解析出所需信息,然后了解到该请求的长度,读取指定长度的数据,然后发送到目标机。但是,如果我们想提供这样一个通用服务,我们需要承载大量线上机器复制过来的流量,但是基于成本考虑我们的DubboCopy不能扩展特别多。那么我们怎么更有效率的处理这个转发呢?对于这样一个网络转发应用而言,我们的资源消耗主要在网络,内存和CPU。内网里,一般来说网络不会成为一个特别大的问题,而且大部分业务服务,数据量并不是特别大(当然也有一些是需要获取大量的数据)。CPU主要用于处理网络和协议解析部分。而使用Java编写这类服务,我最担心的是内存上。因为该服务需要处理大量的请求数据,GC会不会成为一个很大的问题呢?不过进一步分析我们发现,可以做到几乎不使用堆内存。Netty读取的数据可以使用DirectByteBuffer,这样就分配在堆外了,然后我们也是部分解析请求的数据,这只会占用很少的字节。另外,我们提取的信息其实都是类似服务名,方法名等元数据信息。对于这类信息我们都是可以缓存的。而数据呢?其实我们只需要确定一个请求的数据大小,然后将这个大小的数据原样的复制过去即可。我们使用Netty的ByteBuf的readSlice,甚至都无须将数据读取出来,就可以直接将所需数据写入到发送通道。这样整个过程,基本上是不怎么消耗堆内内存的,所以GC基本上没有压力。而对于堆外内存,Netty 4提供了pool,也能大大降低分配的开销。在我们的实际测试也表明了堆内存占用极低,GC也不怎么频繁。

另外,我们将接受数据的Netty Server的worker线程与发送数据的Netty Client的worker线程进行共享,这样进一步降低了上下文切换的频率。

监控各种性能指标,收集服务响应结果

实际上,我们进行复制的目的无非就两点:性能测试和功能测试。

那么对于性能测试来说就是各种性能指标,而服务的RT是否有变化可能是其中最关键的一点。

对于功能测试,最直接的可能是服务的响应数据是否有异常等,不过也可以进一步做到响应数据与线上服务的响应数据进行对比(这一点目前还未实现)。

有了这两方面的数据,我们就覆盖了服务流量复制到结果收集两个环节,能做到一个比较有效的线上环境模拟的工具了。

那么问题来了,大家的线上模拟环境是怎么实现的呢?或者对这个工具感兴趣,有什么新需求的都欢迎来聊聊。

时间: 2024-09-29 18:17:55

基于TCPCopy的Dubbo服务引流工具-DubboCopy的相关文章

基于注解的Dubbo服务配置

基于注解的Dubbo服务配置可以大大减少dubbo xml配置文件中的Service配置量,主要步骤如下: 一.服务提供方 1. Dubbo配置文件中增加Dubbo注解扫描 <!-- 开启dubbo注解支持 --> <!-- 扫描注解包路径,多个包用逗号分隔,不填pacakge表示扫描当前ApplicationContext中所有的类 --> <dubbo:annotation package="com.bounter" /> 2.Service实现

真刀真枪压测:基于TCPCopy的仿真压测方案

郑昀 基于刘勤红和石雍志的实践报告 创建于2015/8/13 最后更新于2015/8/19 关键词:压测.TCPCopy.仿真测试.实时拷贝流量 本文档适用人员:技术人员 提纲: 为什么要做仿真测试 TCPCopy是如何工作的 实作:仿真测试的拓扑 实作:操作步骤 可能会遇到的问题 ip_conntrack 少量丢包 离线重放 不提取7层信息 观测的性能指标 0x00,为什么要做仿真测试 线下的传统压力测试,难以模拟真实流量,尤其难以模拟正常流量混杂着各色异常流量.所以,线下压得好好的系统,上线

超大用户流量从哪里来?酷客多引流技巧教你低成本高效率的引流方式

做一款小程序并不难,尤其是使用酷客多搭建一款商家自己的小程序更是方便快捷. 如何将小程序的作用和功能发挥到极致.引流拓客以及会员转粉成为了商家非常困扰的事,针对商家的这些疑问我们特地做出了解决方案,解决商家拓客难留客难的两大主要问题. 今天我们主要关于引流拓客的话题展开讨论,为商家介绍一些引流拓客的方式. 01引流目的 获取新客,拓客渠道引流的目的最主要的还是为了获取客源,得到更多的顾客,很显然大范围渠道撒网是必要的先行动作.所以第一步明确目的肯定是为了获客和拓客. 商业转型,模式升级传统行业可

利用 tcpcopy 引流做模拟在线测试

一.工具介绍 Tcpcopy是一个分布式在线压力测试工具,可以将线上流量拷贝到测试机器,实时的模拟线上环境,达到在程序不上线的情况下实时承担线上流量的效果,尽早发现bug,增加上线信心. Tcpcopy是由网易技术部于2011年9月开源的一个项目,现在已经更新到0.4版本. 与传统的压力测试工具(如:abench)相比,tcpcopy的最大优势在于其实时及真实性,除了少量的丢包,完全拷贝线上流量到测试机器,真实的模拟线上流量的变化规律. 二.Tcpcopy的原理 1.流程 现在以nginx作为前

基于Spring开发的DUBBO服务接口测试

基于Spring开发的DUBBO服务接口测试 知识共享主要内容: 1. Dubbo相关概念和架构,以及dubbo服务程序开发步骤. 2. 基于Spring开发框架的dubbo服务接口测试相关配置. 3. spring test+junit和spring test+TestNG两种测试框架脚本编写方法. 一.        DUBBO与DUBBO架构 1.          什么是dubbo?DUBBO是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,是阿里巴巴SOA服务化治

构建基于CXF的WebService服务(2)-- 利用CXF提供的wsdl2java工具创建客户端

1.环境配置 将CXF_HOME/bin加入到环境变量path中,如我的是D:\Java\Jar\apache-cxf-2.7.7\bin 打开cmd输入 wsdl2java -v 出现如下信息表示配置成功 2.wsdl2java的使用 (1)创建一个"Java Project"项目,暂且命名为client,将CXF用到的jar包引入进来,去掉jetty相关包,加入geronimo-jaxws_2.2_spec-1.1.jar包 (2)打开命令行工具,将目录切换到client项目中的s

Visual Studio2012 添加服务引用时,生成基于任务操作不可用原因

今天在添加服务引用时,发现 单选按钮 ”生成基于任务操作“不可用,原因项目选择的.net frame是3.5,调整为.net 4.5或.net4.6即可. 原因:.net4.5以下的环境不支持. 原文地址:https://www.cnblogs.com/todayhero/p/10337889.html

性能测试之线上引流测试--让性能测试更真实更丰富

为什么要做引流测试 目前为止大部分的测试是在测试环境下,通过模拟用户的行为来对系统进行验证,包括功能以及性能.在这个过程中,你可能会遇到以下问题: 用户访问行为比较复杂,模拟很难和用户行为一致,模拟不够真实; 线下模拟场景有限,会出现业务覆盖不全的情况.引流测试就是为了解决以上问题,通过把线上的真实流量复制到线下环境,解决测试环境模拟不够真实,或覆盖不够全面的问题. 引流的做法 目前不少公司对引流测试进行了实践,主要有以下4种引流方式: 以上几种办法各有利弊,有的是需要自己开发相应的工具来支持.

通过dubbo暴露接口调用方法,及基于zookeeper的dubbo涉及配置文件【转】

现在很流行的Dubbo很多朋友都听说过吧,最近我也在看这方面的东西,分享先我的心得笔记. 先说说我们团队要做的项目框架,很简单重在实现基于zookeeper的dubbo注册. 框架:springmvc+spring+zookeeper+dubbo 项目分三层,model存放数据,view页面展示.controller下面具体逻辑实现.通过dubbo消费方和供应方注册,供应方给消费方暴露接口,供消费方调用. 工程部署需要配置文件有: applicationContext-dubbo.xml {--