推荐一款国内首个开源全链路压测平台

前不久国内知名的系统高可用专家数列科技宣布开源旗下核心产品能力，对外开放生产全链路压测平台产品的源代码，并正式命名为：Takin。

目前，该项目已在Github上发布开源，作为国内首款开源的全链路压测平台，Takin的开源将为更多企业提供超低门槛、超低成本、超高效率的性能保障能力。

1.什么是生产环境全链路压测?

全链路压测简单来说，就是基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程，本质上也是性能测试的一种手段。

通过生产环境全链路压测，真实模拟“风险”业务行为场景，实时监控系统表现，提前识别和快速定位系统的中的不确定因素，并对不确定因素进行处理，优化系统资源配比，使用最低硬件成本，使系统从容面对各种“风险”场景，达到预期的系统性能目标。通过这种方法，在生产环境上落地常态化稳定压测体系，实现IT系统的长期性能稳定治理。

全链路压测系统架构设计大体类似如下：

 

2. 我们为什么需要做生产环境的性能测试

可能会有人想，性能测试不应该是在测试环境进行吗，为什么需要在生产环境 上面做性能测试呢？

特别是微服务架构在现代系统架构中已被普遍使用，与此同时，随着业务的扩张和微服务数量的增加，它使系统变得非常复杂以至于人无法理解，而且，很多业务逻辑本身也非常复杂。业务复杂性和系统复杂性使保证和维持整个系统的高可用性非常困难，同时，它对研发效率也产生负面影响。

为了保证系统的高可用性，我们通常对测试环境或生产环境的单一服务进行性能测试，但是，测试环境与在生产环境区别很大，单个服务也不能代表整个服务链路，因此，它们都不能保证系统的高可用，通常也无法给出准确的容量评估结果。

归结起来，主要原因有三：

1. 微服务很复杂 和单体架构相比，微服务架构增加了业务系统的复杂性，因为它的子服务数量更多，并且涉及更多的不同技术栈和框架。

2. 业务系统也很复杂 很多业务本身的业务逻辑也很复杂，其中很多业务涉及比较长的业务流程，例如电商业务。

3. 服务与服务之间的调用关系也很复杂 在微服务架构的系统中，服务之间的调用关系非常复杂，每次服务的发布和更新都可能影响整个系统的可用性，并使开发人员难以频繁发布新版本。

如下这张图中是一张典型微服务调用链路，如果服务数量再扩大几十倍，想象一下，调用关系图又会变成何种样子：

 

2. 性能测试演变的四个阶段

性能测试不同公司的实践程度皆有差异，但整的来说，演进过程主要分为从线下到线上四个阶段：

 

1.需求驱动压测阶段

需求驱动压测，大多采用简单的工具进行单接口或者单系统压测，也能进行一些简单的性能问题分析，但很多时候都没有专门的测试团队，需要开发进行自主压测。这个阶段，虽然有需求驱动，但大多数都是凭靠经验法+人为拍脑袋来决定如何做，做什么。

2.性能回归体系阶段

组建专门的性能测试团队搭建线下性能测试平台，且会结合研发流程形成一些规范化体系，并会利用一些开源工具、商业工具，甚至自主开发性能测试平台。

前两个阶段，主要性能测试开展都是集中在线下环境，如此同时，引出了一些问题，其中比较有代表性：

 

• 很多公司线下做了性能测试，但到了线上还是存在很多问题，以测试环境的压测结果来评估线上环境，效果不佳。
• 业务增长、营销活动增加使测试工程师对活动保障心里没底，每逢营销活动问题频发影响公司形象。
• 性能压测效率无法满足增长的性能压测需求，导致部分项目没有性能压测直接上线，线上故障频发。

为了解决测试环境性能压测的不确定性，性能压测开始向生产环境进行演变，进入生产环境性能压测阶段。

3.生产只读业务压测阶段

在测试环境回归体系阶段上增加了生产只读业务的性能压测，对生产环境压测进行实践，搭建生产环境性能压测回归体系，具备只读业务生产压测的性能问题分析能力。

4.全业务全链路压测阶段

在上一个阶段的基础上增加写入业务的性能压测，进而开展对全业务实行全链路压测，具备全业务的性能压测能力、问题定位能力，做的更好一些还会增加系统防护能力，比如降级、限流、故障演练等。

3. Takin介绍

Takin是一款基于Java的开源系统，可嵌入到各个服务节点，实现生产环境的全链路性能测试，尤其适合面向微服务架构系统。通过Takin，系统中的中间件和应用可以在生产环境识别真实流量和测试流量，保证它们进入不同的数据库，实现真实和测试流量的现网隔离。

 

Takin具备以下4个特点：

• 业务代码0侵入：在接入、采集和实现逻辑控制时，不需要修改任何业务代码；
• 数据安全隔离：可以在不污染生产环境业务数据情况下进行全链路性能测试，可以在生产环境对写类型接口进行直接的性能测试；
• 安全性能压测：在生产环境进行性能压测，对业务不会造成影响；
• 性能瓶颈快速定位：性能测试结果直接展现业务链路中性能瓶颈的节点。

Takin结构

 

项目地址：

https://github.com/shulieTech/Takin
或者
https://gitee.com/mirrors/Takin.git

4. Takin安装及使用

1､准备一台装有docker的服务器，配置尽量要高些。

2､修改 Docker 镜像地址为阿里云：vim /etc/docker/daemon.json,更新为：

{
  "registry-mirrors": ["<https://q2gr04ke.mirror.aliyuncs.com>"]
}

配置生效：systemctl daemon-reload

3､ 下载拉取镜像

docker pull registry.cn-hangzhou.aliyuncs.com/forcecop/forcecop:v1.0.0

 

4、启动镜像

docker run -d -p 80:80 -p 2181:2181 -p 3306:3306 -p 6379:6379 -p 8086:8086 -p 9000:9000 -p 10032:10032 -p 6628:6628 -p 8000:8000 -p 6627:6627 -p 8888:8888 -p 29900-29999:29900-29999 registry.cn-hangzhou.aliyuncs.com/forcecop/forcecop:v1.0.0

-d是后台启动，-p是需要开放的端口，容器运行初始化的时候需要安装一些必要的组件需要十分钟的样子，-d可以忽略后台组件的安装信息，如果想要查看安装信息可以去除-d参数。

 

5、进入容器，更改配置：docker exec -it 9754b1ff1491 bash

 

6、修改serverUrl：vi /data/apps/dist/tro/index.html，，将serverUrl配置成服务器本机IP地址。

7、重启Nginx服务：nginx -s reload。

8、配置sugre-deploy启动命令，其中说明一下，sugre-deploy为大数据平台模块。

[root@30e961d36c91 data]# ps -ef | grep surge
root      4336     1 66 17:48 ?        00:03:20 java -jar surge-deploy-1.0-jar-with-dependencies.jar {"172.17.0.2":"192.168.1.138"}
root      4574    18  0 17:53 ?        00:00:00 grep --color=auto surge
[root@30e961d36c91 data]# kill -9 4336
[root@30e961d36c91 data]# ps -ef | grep surge
root      4582    18  0 17:54 ?        00:00:00 grep --color=auto surge

 

9、更改sugre-deploy的启动命令：vi /data/install.sh,将sugre-deploy的启动命令参数“172.17.0.2”对应的value（192.168.1.138这个）更改为宿主机的IP，保存。

 

10、重启sugre-deploy

nohup java -jar surge-deploy-1.0-jar-with-dependencies.jar '{"172.17.0.2":"192.168.1.220"}' > surge.out  2>&1 &

11、进入压测控制台

输入压测控制台地址：http://docker宿主机IP/tro/#/login 示例： http://192.168.1.220/tro/#/login

 

默认账号密码：账号:admin 密码:pamirs@2020

 

如果能看见如上图，恭喜您，成功安装了Takin，接下来就可以开启压测之旅啦~

利用Takin在压测结束后，系统会自动生成一份压测报告，将本次压测所产生的数据进行记录和存档，可随时通过查看报告来回溯压测时的性能指标变化情况，分析性能瓶颈与定位定能问题。

如下图所示：

 

可查看压测全局或单个业务活动的TPS、RT、成功率、SA的指标趋势。

 

请求流量跟踪：

 

官方快速入手指南：

https://docs.shulie.io/docs/opensource