测试开发技术：推荐一款国内首个开源全链路压测平台

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

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

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

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

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

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

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

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

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

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

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

1. 微服务很复杂

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

2. 业务系统也很复杂

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

3. 服务与服务之间的调用关系也很复杂

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

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

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

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

1.需求驱动压测阶段

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

2.性能回归体系阶段

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

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

• 很多公司线下做了性能测试，但到了线上还是存在很多问题，以测试环境的压测结果来评估线上环境，效果不佳。
• 业务增长、营销活动增加使测试工程师对活动保障心里没底，每逢营销活动问题频发影响公司形象。