换个角度，聊聊全链路压测

前言

之前自己也写过好几篇关于全链路压测的文章或者博客，最近看了 infoQ 上infoQ-数列科技杨德华的专栏，复盘了下自己以往在全链路压测实施方面的工作，发觉还有很多可以做的更好的地方。就以这篇文章来做个总结，顺带说说我自己实施全链路压测工作方面的一些收获和经验。

18 年初：聊聊全链路压测

19 年初：再谈全链路压测

20 年初：全链路压测探索实践之路

19 年双十一备战：全链路压测第一次实践

20 年 618 大促总结：生产全链路压测实践之道

20 年双 11 大促总结：全链路压测落地和演进之路

观点

很多同学问过我关于全链路压测如何实施落地，如何在生产环境实现的技术问题。这里我想借用上面 infoQ 专栏大佬的一句话：生产全链路压测，表面是一个技术工程，实际上是一个很有难度的组织协调项目。

下面我会从几个方面来谈谈我个人现在对于全链路压测的一些思考和经验总结。

技术

很多同学说起全链路压测，都喜欢深究它的技术细节，这没错。但全链路压测想要成功的在生产环境实施，更多的是考验组织协调能力的一个项目。至于技术层面，能说的有很多，这次我们先聊聊比较核心的一些技术点。

隔离方案

流量隔离

既然我们的前提是在生产环境进行压测，那么无论是趁着业务流量低峰期，还是生产全链路压测常态化，对于压测流量的隔离区分，是一定要首先解决的。如下图所示：

image

目前业内比较常见的方案，有如下两种：

1）中间件改造+流量标透传（业务侵入较多）；

2）agent+字节码增强技术（业务侵入较低）；

这两种方案的选型，需要基于研发团队的整体技术栈以及业务迭代情况等因素综合考虑。比如我司，采用的是第一种方案。基础架构团队基于 spring cloud 全家桶二次开发了一套全链路压测框架的脚手架，由业务研发团队接入。

资源隔离

资源隔离主要指的服务器、Redis、MQ、DB 等资源。一般来讲大部分企业的业务都是白天流量较高，凌晨是流量低谷。在流量低谷期，直接压测生产的服务，风险相对较小且可控。如果生产服务稳定性较好，且能做到按比例资源隔离以及压测流量识别透传，那么第二种方案反而可以考虑。

且如果要采用资源隔离方案，那么核心链路梳理和区分工作是必须要做的。区分核心和非核心业务，核心业务分级（P0/P1/P2），由小及大的不断覆盖。

数据隔离

压测会产生大量的数据，这些数据如何处理是 DBA 团队面临的最大挑战。目前来说，业内比较通用的方式都是采用影子库表或者压测数据带特殊标识进入生产业务库表，以 tag 或者特殊字段做区分。他们的区别如下：

1）影子库+影子表：一般生产库和影子库都是在同一个 DB 实例上，基础数据会脱敏后同步过去；

2）生产业务表标识：在生产业务表中新增压测标识字段，压测数据需要定时清理（饿了么采用这套方案）；

我司采用的方案如下：

DB 路由：①.同 instance 不同 schema（风险大）；②.不同 instance 同 schema（安全性高，成本高）；

Redis 路由：①.key 值加统一前缀；②.Redis-client 做路由；

MQ 路由：采用影子 topic 模式，带压测标识的数据进入影子 topic；

ES 路由：①.index 统一加前缀，提供统一 ES client 做数据访问，由 client 做路由；

日志隔离

压测会产生大量日志，为了便于正常的业务问题跟进排查和压测区分，个人建议还是对带压测标的日志进行前缀处理，这样运维同学也可以快速的清理，以免磁盘写满导致生产故障。

改造工作

监控平台

监控系统需要透明化，且压测监控大盘和业务监控大盘需要单独配置。其中有如下的点需要注意：

1）设定告警阈值、告警降噪、专项业务告警；

2）专项告警，需要覆盖核心接口、监控大盘、业务大盘；

3）优点：问题快速定位，避免不透明影响问题的发现和修复速率；

4）容量规划：借助监控平台的赋能，快速梳理清楚系统架构、拓扑关系，才便于做容量规划；

流控平台

流量发起和服务保护功能是全链路压测成功开展的必要前提。服务保护方面，业内常用的组件有 Sentinel、Hystrix，他们一般都是基于线程池/信号量来进行流控。

预案平台

常说大促时候，服务稳定性有三大利器：限流、熔断和降级。前面介绍了流控（限流和熔断），那么降级是什么呢？按照我个人的经验，降级预案一般分为主动降级和紧急降级。

主动降级：商品首页缓存 &数据兜底、小红点、客户端限流浮层、重试机制等；

紧急降级：收货地址、浮动费率、运费计算、运营位固定等方案；

当然，无论是主动降级方案还是紧急降级方案，都是需要进行业务梳理和细化拆分的，还要和产品运营等团队的同学提前沟通好，避免跨团队沟通的 Gap 产生。

还有些前置事项，比如业务拆分（订单拆分为正逆向），比如不同业务服务集群隔离，比如 DB 垂直拆分、读写分离、分库分表等方案，这些都是需要考虑的。

至于异地多活、故障演练、灾备演练，这些更需要成熟的技术体系建设和多方达成一致，才能更好的保障生产服务的稳定性。总的来说，全链路压测除了技术，更多的还需要沟通与协调。

压测实施

到了压测实施阶段，基本就只能硬着头皮硬上了，特别是第一次搞生产全链路压测，至今记忆深刻。生产全链路压测，需要注意以下几点：

服务扩容

需要注意的是，在生产开始压测前，系统需要进行前置扩容，避免资源不足导致整体容量瓶颈。还需要注意的是，在大促峰值流量来临时，尽可能不要去执行扩容操作。

压测方式

至于压测执行方式，业内能玩的基本就是这几种方式。当然，压测前的预热，是必不可少的。压测执行方式方面，主要有如下几项：

1）阶梯递增：这种方式的目的在于不断递增流量，找到系统的性能拐点；

2）峰值脉冲：有些特殊场景，需要区分流量是逐渐变大，还是骤升后保持高峰；

3）系统摸高：关闭熔断降级限流等 fallback 功能，提高压测流量观察系统性能转折点；

4）预案验证：开启熔断限流等 fallback 功能，功能是否生效，系统是否能扛得住；

5）破坏性测试：主要为了验证预案的有效性，类似于容灾演练时的预案执行演练，验证后手抢救方案。

注意：执行第 4/5 项时，建议进行生产业务的功能正确性验证！

预案评审

在预案评审和演练阶段，进行预案演练的目的主要有如下几项：

1）验证预案是否生效；

2）针对预案设定阈值进行测试调优；

3）验证预案生效时服务本身的性能表现；

4）针对上述专项场景进行实战演练；

建议：按照我个人的实施经验，建议输出对应的全链路压测 SOP&大促作战 SOP。

管理

前面关于全链路压测的观点，已经提到了：生产全链路压测，表面是一个技术工程，实际上是一个很有难度的组织协调项目。从管理的角度出发，下面三项是管理者或者项目推动者应该高度重视的。

目标

大家应该都了解 SMART 体系，在考虑实施全链路压测时候，下面几点 SMART 目标，也是需要重点考虑的。

目标与标准：SMART5 大元素

1）目标必须是具体的（Specific）——业务指标、技术指标、容量指标等；

2）目标必须是可以衡量的（Measurable）——从不同的维度和数据来评估；

3）目标必须是可以达到的（Attainable）——不要设定过高的脱离现实的目标；

4）目标必须和其他目标具在相关性（Relevant）——对业务以及技术团队有什么价值；

5）目标必须说明明确的截止期限（Time-based）——根据日期和任务资源倒排期，保障项目成功；

流程

总结一下，生产全链路压测这个技术项目，可以用三个维度和五个阶段来概括。

五个阶段：准备阶段、执行阶段、故障修复、项目复盘、项目结项；

三个维度：做什么、风险如何处理、事项 review（保持信息同步）。

组织

日常工作中，我们一般有版本迭代的常规需求以及一些特殊的独立项目。非业务或者弱业务的事情，可以通过虚拟的组织架构来明确定义不同岗位的职责，避免混乱。

一般来说，生产全链路压测中，虚拟的组织架构一般有如下几种角色：

Sponsor：发起 &组织人；

PMO：项目管理、项目经理；

Principal：（主）负责人；

Owner：业务 &技术某一领域负责人（领头人）；

image.png

价值

最开始我司推动实施全链路压测时，我画了下面这张图，用来体现全链路压测的价值：

image

从我个人角度来说，全链路压测的最大价值在于：

1）成本：降低环境成本，人力成本（不断实践，投入的人力越来越少）；

2）问题：提前发现大流量下系统潜在的隐患，提升系统稳定性；

3）容量：提升性能，识别短板，机器配比有了明确的数值，避免不必要的冗余；

4）限流：倒逼各个服务 &系统进行限流降级等服务稳定性保障措施，预案验证演练；

5）ROI：降低沟通成本，团队练兵协调组织能力提升，形成自己的一些技术规范和手册；