生产全链路压测实践之道

前言

每年的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-压测方案

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

image.png

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大促。

 

posted @ 2020-07-04 22:29  老_张  阅读(652)  评论(3编辑  收藏