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

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

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

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

 

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

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


ITeye推荐

• —软件人才免语言低担保 赴美带薪读研！—