生产全链路压测实践之道

前言

每年的618&双11，对于电商公司来说都是一次大考。为了应对活动当天的瞬时峰值流量，进行全链路压测是很有必要的一项技术工程。

而且全链路压测除了对核心链路进行性能问题排查优化之外，还能发现很多日常迭代中累积的小问题，对团队协同作战能力，也是一个很好的提升。

 

演进

从去年双11到今年618，我司的全链路压测体系建设，总体来说经历了如下三次演进：

时间节点	环境	压测方式	优点	缺点
19年双11	1:1等比环境	Jmeter分布式压测	1）完全生产等比环境 2）不用担心造成生产脏写 3）不用担心影响正常生产业务	1）环境成本高昂 2）联调部署麻烦耗时 2）无法真实模拟生产环境
核心系统重构	混部环境	Jmeter分布式压测 流量标+影子库+Mock	1）重构服务可以视为生产服务 2）部分业务走生产环境(灰度验证) 3）压测团队精力更加专注&谨慎	1）环境复杂，问题排查困难 2）可能会对生产造成脏写 3）时间紧张，需要做更多取舍
20年618	生产环境	Jmeter分布式压测 流量标+影子库+Mock	1）环境成本几乎为0 2）完全真实环境，请求流转更真实 3）团队协同能力快速提升	1）需要更精细的前期梳理 2）只能流量低峰压测（通宵） 3）无法做到流量&机器隔离

从上可看出，生产环境全链路压测的优点还是很多的，总结下来重点是下面几点：

1）大幅度节省环境成本；

2）完全真实请求场景；

3）快速发现存在问题；

4）推动技术建设落地；

5）团队协同能力提升；

6）故障响应处理提效；

 

准备工作

1、链路梳理

1-业务场景

业务场景的梳理，主要目的是识别核心链路+场景模型；

2-上下依赖

根据核心链路+场景模型的梳理，分析出它们的上下游依赖（强弱依赖、MQ、job）；

3-接口文档

随着业务版本迭代，涉及到接口逻辑变更，信息无法做到及时更新。如果无法提前进行梳理，在服务联调过程中容易出现各种莫名其妙的问题。

4-流量配比

流量配比是个很玄学的问题！

真实的用户请求走哪些链路，各自占比多少？不同的业务场景，日常和周末、大促相比，占比又是多少？

这些数据都是实时变化的，我们能做的，只有针对性的评估计算出一个大体范围，并留有一定冗余空间。

2、模型梳理

1-压测范围

其实压测范围和核心链路梳理很类似，不过范围界定更多的是从业务角度来划分。对电商公司来说，核心的业务永远是商品、库存、订单、支付！

2-压测模型

压测模型，以我个人经验，主要可以从如下几个维度去划分：

1）单机单接口基准（接口级别）

单机单接口的压测，可以通过梯度增加请求的方式，观察接口随着请求的增加，其性能表现&资源损耗的变化。

2）单机混合链路场景（服务级别）

单机混合场景，大多还是通过梯度增加请求的方式，观察服务级别的性能表现，重点关注3个指标：

①.安全水位（CPU50%）

②.告警水位（CPU70%）

③.最大水位（CPU≥90%&Load5≥150%）

3）全链路压测场景（生产集群）

针对生产集群的全链路压测，需要涉及的压测模型较多，一般有如下几种：

①.梯度增加模型：主要为了探测集群模式下系统的最大吞吐量（也避免压垮服务，造成事故）

②.固定并发模型：验证系统长期处于负载下的稳定性；

③.脉冲并发模型：探测系统的健壮性、验证限流熔断等服务保护措施的正确性&可用性；

④.超卖验证模型：对电商业务来说，主要针对一些限时抢购&秒杀的场景；一般这种场景，会涉及到分布式锁、

缓存、数据一致性等技术点；玩不好的话，容易造成客诉、资损、甚至服务异常宕机！

3-流量模型

出于保密原则，流量模型请参考我之前的博客：全链路压测第一次实践

4-压测方案

做完前期的准备工作，建议输出一份压测方案，核心就一句话：任务拆解，设定里程碑！

3、资源准备

1-ECS预购

一般大促前夕，云服务资源都会比较紧张，因此需要进行预购。资源预购需要注意如下几点：

1）保持和生产服务同规格配置，尽可能在同一可用区；

2）预购数量可以根据生产现有服务数量&一轮压测结果&预期指标进行评估，留有一定备用机器；

2-DB升配

大促期间流量会比较高，因此可以提前对核心业务DB进行一定规格的升配，后续根据压测优化结果调整。

3-SLB扩容

目前阿里云SLB，单个最大支持5W的QPS。为了满足峰值流量冲击及预期指标，需要提前对其进行扩容。

4、专项梳理

1-压测check项

由于压测是在生产环境开展，因此在压测开始前，要针对相关服务的Mock配置、影子库表、流量标传递、测试用户数据预热等相关项进行确认排查，确保压测抱回导致脏写。

2-定时job统计

由于部分业务是通过定时job去调度执行的，为了避免压测时job调度对服务的性能影响，因此需要专门梳理相关的定时job等任务，针对性的进行临时关闭或者调度策略调整。

3-降级开关梳理

为了应对活动当天的峰值流量，可以对一些弱依赖或者非关键业务进行降级操作，比如"小红点"、"SQL校验"、

"退款到账时间"、商品推荐等。

PS：建议将相关的降级操作都通过配置或者开发的方式来处理，便于一键启停，降低操作难度。

4-稳定性预案

稳定性预案一般分为如下几种：

1）应用级别：如降级、熔断；

2）系统级别：日志归档、网关防爬、风控；

3）定时任务：常见的定时job如批处理，定时获取数据；

4）缓存预热：如商品信息、费率信息；

5）异常处理：针对一些异常情况，如优惠券不可用、地址信息获取失败（18年淘宝）；

 

优化提效

1、压测方式

目前生产全链路采用的是基于jmeter的分布式压测，但jmeter本身的分布式压测会将压测数据由slave上报给master，这样会带来一定的性能损耗。

针对这点我们将压测数据写入influxDB，然后由grafana进行查询，做聚合计算并展示。由于分布式压测需要将测试数据同步到对应的压测机上，

针对这个问题我们开发了一键上传，压测一键启停的功能，这样既提高了并发调整的效率，对于异常场景，也能做到尽快的流量熔断保护功能。

2、后端优化

1）通讯协议升级：服务内部调用由http升级为dubbo的RPC调用；

2）监控采样频次：降低了监控数据采样率，由100%降低到10%；

3）数据缓存：针对部分非实时强一致性数据，进行了缓存操作；

4）JVM参数：针对JVM启动参数，设置Xms和Xmx保持一致，减少扩堆动作；

5）线程优化：经过多轮压测对比，最终评估得到结果，undertow的work_threads修改为16N；

3、前端优化

CDN、静态资源、大图压缩、资源内置；

 

监控建设

监控体系建设是一个长期的过程，针对大促，我们主要优化了如下几点：

1-实时拓扑图

2-决策系统：核心链路监控大盘若干

3-监控大盘：业务域监控大盘

这样更便于在也测和大促时及时发现和排查问题。

 

其他专项

1-规格自检升级：mq、db、redis、slb、es、MongoDB；

2-数据库巡检：索引、慢SQL、连接数、proxy层check、负载check；

3-架构图梳理：机房、可用区、业务集群分布、slb、网络升级、slb；

4-安全专项：防爬、防DDoS；

针对大促，运维团队也对相关的服务资源进行了规格巡检和升配扩容，保障618大促。