2天快速搭建一个互联网电商全链路压测平台

2013 年小红书成立之初，主要是让大家分享自己所购买的商品或者是使用好的商品、好的体验。

小红书的前世今生

很多妹子看到这口红不错、那个包包很好看；很多口红是国外的，没有地方买。由此在 2014 年构建电商平台开始上业务。

目前小红书已经成为国内***的社区跨境电商之一。现在在上海、郑州、宁波和深圳有多个保税仓，为全国提供各类全球的好商品。

快速成长的痛

记得在 2015 年的时候，阿里双十一会场可能有上千号的人来同时进行全链路压测。

小红书因为这三年的成长非常迅速，与阿里、京东这两个大厂曾经遇到的稳定性问题一样，需要去面对、解决。

主要有以下三个方面要解决：

• 随着业务增长，人员、IT 资源的扩张赶不上业务的快速发展。比如说，在负责稳定性保障这块，我们测试团队在构建全链路压测过程中也就两三位同学。相对于阿里、京东来说是数量级的差异。
• 以前基于单体 Python 的系统架构在大促时常常成为瓶颈。
• 缺乏有效的性能和线上稳定性保障策略和实践。

全链路压测系统架构

对于全链路压测，阿里有 PDS、京东有全链路压测平台。大厂这样的压测系统都是经过较长的时间不断迭代出来的。

我们怎么办？我们没有那么的人力和资源；最核心的就是要搞定问题。

在电商高峰期场景下，它的流量可能是平时的 10 倍甚至是几十倍。在这种情况下流量不是均匀地打到各个业务线的。

例如，90% 流量先进到主会场；再由主会场引流到各个分会场，然后是下单等等。整个过程是一个漏斗模型；这个可以用接口的水位对比来表示。

为了保证模拟高峰期线上行为，我们需要基于水位对比对整个业务模型进行全链路压测。

据此，我们的全链路压测系统架构分为四大块：

• 各个链路压测脚本配置管理
• 压测调度
• 统一压测数据管理
• 被测业务系统状态监控

对于压测系统来说，最核心的就是压测脚本；怎么能够快速、方便的开发出来一大批链路的压测脚本。

从 0 到 1 构建全链路压测

从 0 开始

2017 年的 6 月 6 号大促是我们平常比较重要的三个大促之一。我们在 5 月接到需要保障今年大促的任务。

当时整个测试的同学只有两人可以投入，运维同学只有一位可以支持。而开发的同学一直会致力于业务开发直到 6 月 4 号。同时测试系统方面基本上是白纸一张。

压测模型

要进行全链路压测需要构建压测模型，就是要知道压什么、怎么压、压到什么样的水平：

• 首先，我们需要做链路的梳理。我们和开发、运维协作通过运维监控系统将线上接口所有列表获取到。
• 然后，通过调用监控系统获取各个链路之间的配比关系。同时根据去年和日常链路监控的配比得知各个接口平时和去年大促在什么样的水平。
• ***，依据前面两个步骤去计算链路调用、压测脚本以及施压机等情况。

据此，我们任何一个链路压测脚本都一共有四个压测的参数，分别为：

• 输出压力 qps
• 当前水位
• 施压周期
• 压测链路

密切协作

在这样的情况下，对于我们测试的同学来说就简单了许多；我们可以将这个工具打成一个包，方便部署。

这样就可以和运维同学一起合作，一次性生成多台施压机器同时去压一个系统。

目前，我们大概可以在五分钟之内能够创建出来 400 台以上的压测容器也就是说快速输出 5G 以上的压力。

为了区分压测流量和真实线上流量，我们和开发同学全力协作对线上的每个测试数据进行打标。

这样一来在出业务报告或数据报表的时候，我们有统一的框架将测试数据进行剥离；进而保证了测试数据不污染线上数据。

全链路压测目标就是模拟真实的大促情况下，我们的各个链路能够承载多大流量以及各个业务系统的瓶颈点所在。

压测之外

除了前述的全链路压测之外，我们这里还包括容量预估、降级方案、应急预案、大促演练以及值班计划。

我们会通过流量历史监控来做容量的预估；同时，为压测基线和限流熔断提供依据。

当线上业务流量水位超过我们设置的阈值的时候，为了保障线上运行稳定我们会对相关的业务进行功能降级。

另外当线上水位超过我们原来预期的时候，我们会有相应的应急预案以降低容量不足带来的影响。

年中 66 大促全链路实践

2017 年从 5 月 6 日立项，到 8 号开始***条链路施压，只用了两天我们实现了从 0 到 1 的跨越。

对于从 0 到 80% 的这个过程，大家是可以很快做到的，因为对于运维同学来说这些工具、方法基本上是每天都在做的事情。复制从 0 到 1 的构建思路，我们在人员紧缺的情况下实现了预期目标。

对于有兴趣开展线上全链路压测的同学有以下三点建议：

• • 先不要想大而全的平台化。
  • 关注系统的本身，从监控和限流开始做起。
  • 掌握全链路压测方法，快速构建实现从 0 到 1。