《云集的全链路压测之路》

其实说句实话，我们的全链路压测之路走的还是比较艰辛的，从最初纠结用什么压测工具开始，到压框架、压单接口、压压测环境，到线上环境一步步摸索，并结合其它友商的经验和方案，直至今天，将近耗时一年多的漫长时间，我们才最终在黑暗中摸索出了一条属于我们鸡场人自己的全链路压测之路，我们就是在不停的试错过程中逐步成长和成熟起来的。

 

一、究竟什么是全链路压测

流量不大的时候，开发人员、测试人员随便在线下做一把功能测试，只要功能能够正常跑通就行了，但随着用户规模线性上涨，流量越来越大，我们逐渐会意识到，光靠常规的功能测试似乎是远远不够的，流量上来了，必须重视系统性能了，毕竟谁也不希望自己的系统被流量无情击垮，要做到心中有数(清楚系统的容量水位，有指导的进行容量规划)。因此到了这个阶段，大多数企业都会选择在线下对框架、中间件、存储层实施压测，明确其吞吐量，但是这样的压测结果数据，离线上还是有很大差距，毕竟绝大多数企业的压测环境并不会与生产环境1:1(至今我也未曾见过这种土豪企业)，所以压测环境的压测结果数据纯粹是仅供参考，并不能够作为线上环境的指导数据，只有直接在线上环境实施压测才是唯一的明道。

 

在线上环境直接进行压测，说来轻松，但其背后却影藏着极大的风险。大多数情况下，我们的系统都是有用户在进行访问的，尤其是峰值流量时绝不能因为压测流量导致系统故障从而影响用户下单，甚至更不能够污染线上数据。试想一下，用户A的订单信息中，突然多出来10台IphoneX，你是送还是不送？或者余额突然变少了，都是用户绝对不能够容忍的(除非变多了，闷声发大财)，并且线上环境往往还会伴随着各种定时任务，统计的时候如果把压测数据也计算进收益中，运营部门的老大估计会请研发同学喝茶。

 

尽管困难重重，但是要探测系统的真实容量水位，有指导的在大促前进行容量规划，以及给出合理的限流水位，只有此路通罗马。因此系统需要能够智能化到准确无误的区分哪些数据是真实用户流量，哪些是压测流量，然后引流到隔离环境中落盘，后面我会讲到如何区分压测流量。

 

那么究竟什么是全链路压测呢？单接口压测相信大家都清楚，比如对网站A接口进行压测，假设其QPS是10W/s，但在压测网站A接口的时候，同时也在对B接口进行压测，这时网站A接口的QPS必然不会再是10W/s。这是因为系统中任何一个接口都不会单独存在，都会或多或少受到一些公共资源的制约，当公共资源成为瓶颈时，系统全局都会受到影响。简单来说，所谓全链路压测指的其实就是对系统的所有核心链路都同时实施压测，当系统整站流量都被打上来的时候，才会暴露出系统的性能瓶颈，才能够探测出系统整体的真实容量水位，这就是全链路压测以及实施全链路压测的意义。