码迷,mamicode.com
首页 > 其他好文 > 详细

全链路压测第一次实践

时间:2019-12-02 01:10:02      阅读:111      评论:0      收藏:0      [点我收藏+]

标签:数据脱敏   资源   经验   优先   熬夜   tps   图表   时间   针对   

每年双十一,对买家来说是一场买买买的剁手之旅,但对于电商公司的技术人员来说,却是一次严峻的技术期末考。如何保证系统在预估的流量洪峰来临时,既能保证用户的买买买不受影响,

促进业务及营销活动的目标达成,又能用尽可能少的成本投入保障系统的稳定可用性,是技术童鞋必须面对的挑战。我司在双十一来临的最后关口完成了整个核心链路的全链路压测,

大幅提高了核心链路的服务性能,并发布了最终优化版本。在双十一期间,也取得了一定的成果,期间包括技术、运营、产品、行政等各部门都为之付出了很多努力。

下面的内容,是从启动到双十一这段时间,我们在双十一项目上所做的关于全链路压测的一些实践。

 

一、面临的挑战

从项目kickoff到双十一活动开始,第一次双十一大促,我们面临着巨大的挑战。

挑战一:核心链路梳理

电商业务本身比较复杂,且当前阶段我们微服务架构下,各个服务间依赖高,调用关系复杂,且没有较为清晰的链路梳理,理论上来说,只有一部分系统才是核心链路。

所以,面临的第一个挑战,就是从错综复杂的系统中梳理出核心业务链路。

挑战二:环境成本高昂

按照业内的实践经验和方案,全链路压测都是在生产环境进行,这样测试的结果才能更贴近实际的生产场景。

但由于我们是第一次进行全链路压测,因此只能选择折中方案——按照生产环境当前的配置,搭建一套等配镜像环境

镜像环境从资源准备到服务部署联调都比较耗时,且成本高昂,这逼迫我们必须拿到更好的结果,才能提高ROI。

挑战三:流量评估困难

为了尽可能使压测场景更贴近真实的生产场景,需要对核心链路的流量模型进行比较准确的评估和模型确认。

由于各服务间依赖较高,且调用关系复杂,这对我们提出了新的挑战——如何评估出更接近真实场景的流量模型。

挑战四:任务多线开展

从双十一启动到结束,需要同时开展的任务较多。比如服务拆分、耦合任务迁移、DB&Redis垂直拆分、正常版本迭代、全链路压测及性能优化,以及新的业务线不断拓展,这些都是我们需要面对并且克服的困难。

 

二、压测的过程

启动阶段

1、任务规划

项目kickoff后,在技术负责人牵头下迅速确定了本次双十一大促的TODO项。主要是如下几项:

前端:降级点确认、容错保护、监控数据接入;

后端:核心链路梳理、监控&服务保护接入、专项预案、

测试:资源准备、压测模型梳理、压测方案、全链路压测、预案演练、线上功能验证;

基础架构:架构优化、网关替换、DB垂直拆分、基础设施接入(链路追踪、监控、报警......);

资源保障:容量规划、镜像环境搭建、服务部署联调、线上扩容;

2、估时排期

确认任务规划后,各个技术团队迅速组织协调资源投入了各自的工作。由于双十一迫在眉睫,且待办事项较多,故按照时间进行任务估时倒排。

准备阶段

在准备阶段,按照任务规划拆解出来的细化任务进行同步开展,下面是准备阶段我们开展的主要事项。

1、核心链路梳理

各业务研发团队的owner对我们目前的核心业务链路进行了梳理,主要包括:首页、商品、订单、支付、用户、风控、优惠券、大促活动、基础服务。下面为示意图表:

技术图片

2、镜像环境准备

由于本次压测是在和生产等配的镜像环境进行,相当于从零开始搭建一套环境,无论是资源准备、服务部署还是服务联调验证,都耗费了较多的时间,从中也发现了我们之前的一些不足,累积了很多经验。

3、压测任务排期

根据大促任务规划,性能测试同学从中拆解出了较为详细的压测任务,并进行排期,同时积极主动的推动了整个压测任务的开展实施。

4、专项预案沟通

专项预案主要包括如下几项:限流、降级、熔断、脉冲、破坏性验证五种场景。在服务治理这一项,基础架构的同学接入了sentinel进行相关管理。

5、大促指标沟通

为保证压测流量和生产预估流量对齐,由技术负责人牵头,和运营产品同学进行了多次沟通,确认了本次双十一大促活动相关的活动场次、时间段、优惠券投放量、预估DAU等相关关键指标。

6、压测模型梳理

压测模型的梳理,主要包括核心业务链路的优先级、调用依赖关系、流量模型转化(漏斗模型)等,限于保密措施,这里不过多介绍。

7、流量模型梳理

关于流量模型,建议梳理出核心交易链路对应的依赖大图,并粗估双十一峰值数据,作为接下来压测、性能优化的技术目标。

8、线上容量评估

为了在压测开展前对目前线上的服务容量有一个初步的了解,需要对各个核心服务、消息队列、缓存以及DB的容量进行了梳理汇总。

9、线上链路监控

监控就是我们的眼睛,有了监控,才能快速发现问题并定位修复问题。这一点,基础架构的同学为此做了很多工作。比如:链路追踪监控的Cat、可视化监控大盘Grafana以及更多的监控组件。

10、压测数据准备

为了尽可能保证压测数据的真实性,我们的解决方案是复制生产库的数据,进行脱敏和可用性验证,用来做压测的基础数据。在数据脱敏和可用性验证这点需要高度重视。

11、资损防控梳理

由于现在双十一大促活动主要玩法都是优惠券以及满减相关,且涉及到订单支付业务,因此资损防控也是准备阶段的重中之重。

12、确定性能水位

为了精确测定各服务单机的水位性能,并留存一定的buffer作为流量高峰时刻的缓冲,结合业内经验和我们当前的系统情况,最终确定以单机40%的水位性能作为线上扩容和容量规划的验收标准。

13、输出测试方案

前期做了相当多的准备工作,在正式开展全链路压测之前,性能测试同学输出了本次双十一全链路压测的测试方案,通过评审后,全链路压测工作就可以正式开展。

 

实施阶段

在全链路压测实施阶段,根据测试场景和采用的测试策略,我们主要进行了如下的工作。

1、单机单链路基准测试

在目前的微服务架构下,整体链路的性能瓶颈,取决于短板(木桶原理)。因此,单机单链路基准测试的目的,是在全链路压测开始前进行性能摸底,定位排查链路瓶颈。

2、单机混合链路水位验证

单机混合链路压测的目的,是排查上下游调用依赖的瓶颈,并以此测试结果作为限流预案的基准值。

3、全链路压测演练

全链路压测作为备战双十一的重中之重,是今年双十一大促项目的基础保障。在整个实施阶段,需要不断的压测,排查定位分析问题并进行优化,对最终的线上发布和容量规划提供了支持。

4、专项演练

专项演练主要是针对服务限流降级熔断以及高可用、服务扩容进行验证。进行演练的目的主要有如下几项:

①、验证预案是否生效;

②、针对预案设定阈值进行测试调优;

③、验证预案生效时服务本身的性能表现;

④、针对上述专项场景进行实战演练;

5、稳定性测试

稳定性测试的目的,是验证系统处于负载情况下,能否长时间提供稳定可用的服务能力。

6、每日问题复盘

在备战双十一期间,会针对每天压测发现的问题进行复盘追踪,尽可能让性能问题及时解决。

发布阶段

经过闭关作战半个月,针对我们的核心业务链路,进行了多轮的压测和性能优化,各系统qps已经基本达到了预定的目标(等比例),TPS整体提升3倍以上。

在双十一峰值流量期来临之前,做最终的线上扩容和优化版本发布。针对双十一,我们还做了预案的梳理并提前执行、服务降级、缓存预热、job任务降级错峰处理。

 

三、收获与思考

整个过程中,大部分同学都是没有全链路压测实战经验的,但每个人都迸发出了巨大的能量。整个过程中发现了很多存在的问题,但还是有很多是值得改进的地方,比如:

时间紧促,留给性能瓶颈定位和优化的时间太少,后续可以考虑测试左移;

对一些问题定位排查工具的使用姿势应该熟练,对流量的预估应该更加准确;

项目的推进方面得积极主动,大家都应该有owner意识;

总之,生产的稳定性是服务的基石,尤其对我们性能来说稳定压倒一切!

 

四、未来的规划

为了保障明年的618大促、双11大促,同时为了应对业务快速发展,访问流量的剧增,我们已经开展了全链路压测平台的建设工作,后续会不断投入精力去完善,希望可以将压测变成:

轮询化:线上链路测试机器人,实时监控,检测生产服务;

常规化:减少人力成本投入;

日常化:尽可能白天完成压测工作,毕竟熬夜不利于身体健康;

图形化:链路压测规划图形化展示,与业务结合,一键完成数据准备工作。

 

以上就是我经历的一次从零开始的全链路压测过程中的一些经验和收获,内容仅供参考。。。

 

全链路压测第一次实践

标签:数据脱敏   资源   经验   优先   熬夜   tps   图表   时间   针对   

原文地址:https://www.cnblogs.com/imyalost/p/11811142.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!