腾讯开源微服务压测利器，贡献进TARS开源基金会

TarsBenchmark（简称tb）旨在帮助开发和测试同学快速debug线上TARS服务，复现逻辑接口bug，支持灵活修改测试用例，同时也可以很轻松完成服务接口的压力测试，帮助开发同学清楚掌握TARS服务性能数据基准。具备如下特性:

易用性: 在管理端轻松点几下就可以完成测试和压测，操作非常简单。

高性能: 基于事件驱动和多线程，8核的机器可以产生40wTPS的的输出能力。

可伸缩: 压测机采用分布式部署，可以自动扩所容，管理端自动发现和灵活调度。

支持动态随机: 在网络后台服务器如今一般都是分布式部署，如果压测请求发包的数据都是一致的，容易触发业务机器热key效应，即大部分请求压到后端服务的某一台单机上(典型比如存储机)，从而引起单机高负载，不能反映分布式服务真实能力情况，tb注意到这个问题，设计了一个随机因子产生函数，可以极大可以改善这个情况，管理端配置一下数据格式即可完成。

数据实时反馈: 压测过程中最难受的不掌握当前服务在高并发的表现，本工具提供周期显示给到WEB页面，当前已支持反馈成功率，速率，平局耗时，最长/最短耗时，P90/P99/P999耗时分布情况。

为了实现一个好用TARS服务压测组件，tb主要解决下面几个重大难题:

协议可扩展

采用TARS框架的服务在实际网络传输过程中是binary传输，要在管理平台编辑二进制协议，使用门槛就太高，不利于使用；除此之外，TARS协议自身具备很强的拓展性，每个服务和接口都长的不一样。测试插件在协议这块要解决可扩展性。可读性方面是通过json来做可视化，扩展性方面是通过IDL工具完成bin2json互转。具体方案如下

压测高性能

为支持高性能的并发，需要注意避免IO阻塞，另外现在服务器都是多核超线程，因此也要发挥CPU多核并行处理能力。tb采用事件驱动，工具采用多进程设计，在64核机器上能轻松生产100W/S的输出能力。此外如果不能分布式压测，性能的天花板永远受限于单机网口和CPU，因此必须要支持分布式压测，采用如下方案，让插件可以轻松做到压测性能的动态伸缩，突破理论上的上限，主要是如下两个服务完成。

压测节点服务: 压测Node作为实际发起方，采用无状态部署，根据CPU核心数动态压测线程，一个线程负责一个压测实例，在协议处理这块，根据descritptor信息将case还原成二进制。

压测管理服务: 管理压测节点，接收处理CGI指令，根据用户输入速率计算所需的压测节点，分发任务到压测节点上，完成启停和查询操作。

工具服务化

工具的服务化的目标是完成后台到前台的切换，使用tb工具可以获得高性能，但尝试成本略高，将压测搬到线上极大地降低使用门槛，除了2.2节提供的2个服务完成压测功能，我们还需要借助TARSWeb帮我们进行接口文件管理和用例管理，将接口文件转化(2.1节)放到后台自动完成，同时提供一个简单的入口启停压测和观察压测数据。

支持动态随机

如果压测每次发的应用层报文都一样，非常容易造成目标服务器依赖的后端服务器（常见例如存储机）的过载，因为同一个uid的请求都最终都跑到同一台存储机器上，造成单机过载。目前包括ab/wrk/jmeter等常用压测部件都没能很好解决这个难题，我们在tb上做了一点改进，支持两种方式动态生成随机内容，覆盖到常见的基本类似数据，使用起来比较方便，编辑一下JSON的值就可以实现。

范围随机值: 形式为[数字1-数字2]，表示数字1到数字2内随机出现；

枚举随机值: 形式为[内容1, 内容2, 内容3]，以英文逗号分隔，表示内容1，内容2以及内容3随机出现；

目录结构

tb开发语言主要是cpp，依赖TarsCpp框架，两个主要服务也是基于TARS协议开发。

服务部署

tb编译要依赖TarsCpp环境。

tool编译出来可以直接运行，使用参考官方文档（点击【阅读原文】即可查阅）。

server编译出来之后，采用install.sh可以实现一键部署到TarsWeb，然后在TarsWeb上实现线上TARS的服务接口测试和压测，参考3.3 节说明。

接口测试

在TarsWeb上进行接口测试和压测的时候，用例可以半自动生成，只需要填写一些参数内容，用例可以保存，下次测试可以轻松回归。

接口测试/压测:

tb在实现的过程中，也借鉴了一些开源压测组件的设计思路，在协议支持方面具备更好的扩展性，并形成自己的一些特色，总结如下:

TARS基金会是Linux基金会下的非营利性、微服务基金会，致力于建设一个强大而灵活的微服务生态系统。无论你在哪个行业，无论你使用什么技术栈，这里能助你快速实现你的创意。