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

标签: tcpcopy dubbo 服务 | 发表时间:2017-07-26 13:56 | 作者:
出处:http://m635674608.iteye.com

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是否有变化可能是其中最关键的一点。

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

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

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

 

http://www.cnblogs.com/yuyijq/p/4541660.html



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [tcpcopy dubbo 服务] 推荐:

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

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

dubbo服务降级实现dubbo-plus/circuitbreaker at master · dubboclub/dubbo-plus · GitHub

- -
向注册中心写入动态配置覆盖规则:(通过由监控中心或治理中心的页面完成). 表示消费方对该服务的方法调用都直接返回null值,不发起远程调用. 屏蔽不重要服务不可用时对调用方的影响. 表示消费方对该服务的方法调用在失败后,再返回null值,不抛异常. 容忍不重要服务不稳定时对调用方的影响. Dubbo支持服务降级,并且支持当服务出现异常的时候进行服务降级处理,但是存在一下几个缺陷.

谈Dubbo服务框架

- - 人月神话的BLOG
Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成. 它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合). 从服务模型的角度来看,Dubbo采用的是一种非常简单的模型,要么是提供方提供服务,要么是消费方消费服务,所以基于这一点可以抽象出服务提供方(Provider)和服务消费方(Consumer)两个角色.

dubbo服务化实施整理

- - 企业架构 - ITeye博客
随着快的业务的快速发展,我们逐步按照业务垂直划分,抽象出基础服务层. 基础业务的服务为上游业务的灵活发展提供支持. 服务应用本身无状态化,可以随着系统的负荷灵活伸缩来提供服务能. 服务的稳定性,可用性达到99%. dubbo来作为服务化中间件,dubbo作为一个RPC框架,大致的原理如下图. Registry: 注册中心;和服务的消费者,和服务提供者都建立长连接.

dubbo服务telnet命令 - 秦鹏飞

- - 博客园_首页
dubbo服务发布之后,我们可以利用telnet命令进行调试、管理. Dubbo2.0.5以上版本服务提供端口支持telnet命令,下面我以 Windows为例抛砖引玉一下:.     测试对应IP和端口下的dubbo服务是否连通,cmd命令如下.     正常情况下,进入telnet窗口,键入回车进入dubbo命令模式.

dubbo服务治理(一)降级

- - 企业架构 - ITeye博客
在线网站一般都会有服务器压力剧增的时候,比如说网上商城的促销,这个时候常用的手段就是服务降级,根据当前业务情况及流量对一些服务和页面有策略的降级,以此缓解了服务器资源压力,以保证核心任务的正常运行,同时也保证了部分甚至大部分客户得到正确响应. 页面拒绝服务:页面提示由于服务繁忙此服务暂停. 跳转到varnish或nginx的一个静态页面.

阿里巴巴Dubbo分布式服务框架已开源

- tangfl - ITeye论坛最新精华讨论帖
Serving services with invocations everyday, Dubbo becomes the key part of Alibaba's SOA solution and has been deployed to the whole alibaba.com family:.

Dubbo:来自于阿里巴巴的分布式服务框架

- - 标点符
Dubbo是阿里巴巴SOA服务化治理方案的核心框架,每天为2,000+个服务提供3,000,000,000+次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点. Dubbo是一个阿里巴巴开源出来的一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式.

浅谈SOA面向服务化编程架构(dubbo)

- - ITeye博客
并非淘宝系的技术啦,淘宝系的分布式服务治理框架式HSF啦 ,只闻其声,不能见其物. 而dubbo是阿里开源的一个SOA服务治理解决方案,dubbo本身 集成了监控中心,注册中心,负载集群...等等. 代码和整体的框架还是很优雅滴呀. github地址 https://github.com/alibaba/dubbo.

阿里巴巴分布式服务框架-Dubbo问与答

- - Arccode's blog
Dubbo是阿里巴巴内部的SOA服务化治理方案的核心框架,每天为2000+ 个服务提供3,000,000,000+ 次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点. Dubbo自2011年开源后,已被许多非阿里系公司使用. 项目主页: http://dubbo.io/Home-zh.htm.