全链路压测落地和演进之路

​前言

笔者所在的公司是一家快速发展的互联网电商公司,在保证业务快速稳定发展的同时,对于系统稳定性、可用性和扩展性的要求,也在不断提高。

特别是互联网电商企业每年的两次大考:618&双11,更是对服务的三大特性有更多的要求。在大促活动开启之前,无论是前期的核心业务梳理、线上流量评估、场景建模,

还是测试实施阶段的监控分析、调优验证,乃至线上的容量规划,每个环节都需要做很多工作。且这些工作都需要运维、开发、测试、产品甚至数据分析团队的协同配合,才能保质高效的完成。

全链路压测,作为电商大促的稳定性保障利器,也在不断的迭代演进。

这篇文章,为大家介绍下全链路压测在我司的落地和实践演进史。

当然,其中的某些敏感部分已脱敏,请谅解(图片水印为本人微信公众号水印)

 

落地

挑战

去年双十一,为了应对零点的峰值流量冲击,我们在八月下旬启动了第一次全链路压测。由于是从零开始,因此单独的搭建了一套和生产1:1的环境。

2个月的时间,环境成本就高达几百万。从项目KO到双十一活动开始,第一次双十一大促,我们面临着下面几点挑战。

全链路压测落地和演进之路

核心链路梳理

电商业务本身比较复杂,且当前阶段我们微服务架构下,各个服务间依赖高,调用关系复杂,且没有较为清晰的链路梳理。

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

全链路压测落地和演进之路

如上图所示,梳理核心链路前一定要考虑清楚上面三个问题:

1)我们在梳理什么?

梳理核心链路,实际上是对我们的业务场景、数据场景和逻辑场景的梳理。

2)什么是核心链路?

从实践来说,核心链路主要有这几个特点:它是核心业务聚集区域、牵一发而动全身、影响导购下单支付。

3)为什么要梳理它?

梳理核心链路最重要的目的是让团队的每个人都清晰的知道:谁会影响我的服务,我会影响谁的服务,以及梳理过程中发现潜在的风险。

 

环境成本高昂

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

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

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

 

流量评估困难

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

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

全链路压测落地和演进之路

流量评估从我个人角度来说,最大的难点实际上在于找到切入点。

而最好的切入点,除了前面讲到的核心链路梳理,其次就在于完善的监控体系。其中,核心链路梳理是前置项,而监控工具则是流量评估的提效工具。

1)评估流量

完成核心链路梳理后,可以依据核心链路的请求调用关系进行上下游分析。相关工具的话,开源的有jaeger、skywalking、pinpoint等。

2)模型分析

模型分析主要关注三点:入口流量、内部流量和出口流量。它们各自的区别如下:

      • 入口流量:主要指到达网关入口的预估峰值流量;

      • 内部流量:微服务架构下,内部服务间调用会出现单个接口被多次调用的情况,这是需要重点关注的;

      • 出口流量:这里指的是核心链路之外的下游调用以及一些外部调用;

3)安全水位

所谓的安全水位,即服务能在保证自身比较稳定的情况下支撑业务的能力,一般以CPU%为基准。业内目前的安全水位,大多以40%——50%为安全水位。当然,安全水位的设定需要明确如下三点:

      • 最大处理能力:即服务器资源耗用达到超过90%时的处理能力;

      • 稳定处理能力:服务在安全水位线时候的处理能力;

      • 水平扩容能否提高能力:服务集群能否通过快速的水平扩容来提高处理能力;

 

任务多线开展

在双十一启动到活动开始这段时间,需要同时开展的任务较多。比如服务拆分、小红点迁移、DB&Redis垂直拆分、全链路压测及性能优化,以及新的业务线不断拓展,这些都是我们需要面对并且克服的困难。

 

过程

全链路压测落地和演进之路

启动阶段

任务拆分

项目kickoff后,在负责人牵头下确定了本次双11的TODO项。主要是如下几项:

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

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

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

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

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

 

准备阶段

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

核心链路梳理

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

流量模型梳理

梳理了首页、商品、交易、支付等关键场景的下游依赖。将商品+交易+支付绘制了对应的依赖大图,并粗估双十一峰值数据,作为接下来压测、性能优化的技术目标。

镜像环境准备

由于本次全链路压测是在和生产等配的镜像环境进行,相当于一切从零开始搭建一套环境,无论是资源准备、服务部署还是服务联调验证,都耗费了较多的时间。

运维同学投入了很大的精力做support,从中也发现了我们之前的一些不足,累积了很多经验。

压测数据准备

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

在数据脱敏和可用性验证这点,安全团队、DBA以及功能测试的同学给予了很大支持。

专项预案沟通

专项预案主要包括如下几项:限流、降级、熔断、脉冲、资损五种场景。

大促指标沟通

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

线上链路监控

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

 

实施阶段

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

单机单链路基准测试

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

单机混合链路水位验证

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

全链路压测演练

全链路压测是大促的保障。在整个实施阶段,需要不断的压测、排查定位分析问题并进行优化,最终拿到结果。

专项演练

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

      • 验证预案是否生效;

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

      • 验证预案生效时服务本身的稳定性;

稳定性测试

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

每日问题复盘

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

 

发布阶段

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

 

演进

全链路压测落地和演进之路

从19年双十一,到今年双十一及双十二,全链路压测在我司的演进,总体可以从如下几个阶段来介绍,这几个阶段分别有大事件发生,也正好推动了全链路压测的迭代演进。

五彩石

时间

2020年3月

环境准备

混部环境(测试+预发+生产):特殊的环境导致了19年双11沉淀的一些经验几乎无法复用,环境问题也是五彩石全链路压测过程中,最大的难点和挑战。

最终的解决方案是接入流量标框架fusion+生产部分服务mock+生产DB创建影子库表的方式来解决了这个问题。

数据准备

通过生产数据定时同步到影子库+数据清洗的方式,准备了千万量级的压测相关数据。

整体耗时

从前期链路梳理到框架接入、影子库表创建、可用性验证、以及压测优化完成,共耗时24个自然日。

当然,由于当时整个环境是业务测试+产品验收+数据迁移+压测共用,实际耗时其实是很少的。

方法论

19年双11沉淀的没法复用,业内也没有这种特殊环境下的压测方法论,对压测团队而言,是一次重新探索实践

覆盖范围

由于五彩石项目主要是交易体系重构,当时全链路压测的覆盖范围也仅限于核心交易+搜索链路。

 

618大促

时间

2020年5月

环境准备

从今年618开始,我们的全链路压测开始在生产环境开展。关于环境的前置准备,主要是表结构同步检查+ECS规格巡检以及其他比如SLB、CDN、带宽的资源的日常巡检。

数据准备

数据准备主要分两个方面:

用户数据:专门准备了100W的虚拟用户数据,通过逻辑身份绑定和替换的方式,按序打通整体用户数据可用性。

业务测试数据:同步生产真实数据,针对敏感数据进行脱敏处理,然后业务数据绑定虚拟用户数据。

整体耗时

618阶段相比于五彩石,环境相对来说没那么复杂,且五彩石本身有一定的适合我们自己的技术沉淀,因此整个压测全阶段的耗时,相比五彩石少了不少,耗时为15天。

方法论

由于五彩石已有了一定的探索实践经验,在618全链路压测阶段,进行了补充完善。

20年618的全链路压测,可以说是我们全链路压测方法论从0到1落地的重要实践

覆盖范围

618相比于五彩石,压测的核心链路覆盖范围扩大了不少,主要包括交易+搜索+社区+客户端部分核心链路。

 

五周年活动

时间

2020年9月

环境准备

生产环境:表结构同步检查+ECS规格巡检以及其他比如SLB、CDN、MQ、带宽等资源的日常巡检。

数据准备

数据准备策略基本和618保持一致,虚拟用户数据保持不变,由于版本迭代的原因,只变更了部分业务测试数据。

整体耗时

从需求提出到开始压测,耗时仅用三天!

方法论

基本参照了618沉淀的技术文档以及一些实践经验,做到了快速复用

覆盖范围

由于五周年活动主要是一些营销相关的玩法,本次覆盖范围为交易+搜索+无线平台部分核心链路。

 

双十一大促

时间

2020年10月

环境准备

到今年双十一,生产环境已经成了全链路压测的标配环境。

数据准备

用户数据:由于业务快速增长,考虑到数据分布和业务逻辑缓存的问题,这次虚拟用户从100W增加到了700W;

业务测试数据:重新将生产环境的数据同步到影子库,针对性进行脱敏处理。

整体耗时

由于版本迭代和业务逻辑的不断变化,在准备阶段,重新梳理了核心链路以及强弱依赖,对流量模型进行了重构。迭代优化了主动/紧急预案、新增了缓存预热+客户端限流浮层。

容量巡检方面,新增了ToB的慢SQL梳理、MQ堆积告警等事项。且在今年双十一,我们接入了Zeus压测平台,对整个压测过程进行了规范提效。

整个准备阶段耗时15天,通过6次通宵压测,完美的达到了预期指标并留有一定冗余空间。

方法论

如果说19年双十一是从零开始,五彩石是重新探索触发,618是从零到一落地,五周年是快速复用,那么20年双十一的全链路压测,可以用从一到十来概括。

覆盖范围

相比于之前,本次双十一打通了风控链路。风控研发团队通过接入fusion框架+dubbo改造,让我们整体的压测流量能一直透传到风控服务,这样对整体的稳定性来说,提升是潜移默化并且巨大的。

覆盖范围:交易+搜索+无线平台(社区+客户端+增长)+风控。

 

大促方法论

全链路压测落地和演进之路

通过这几次大的技术项目,全链路压测,从零开始探索实践,到从零到一的能快速复用的方法论,以及从一到十的完善优化,我们也渐渐找到了适用于我们得物的全链路压测方法论。

 

性能指标提升

全链路压测在我司的不断演进,对应的是我们核心链路的性能不断突破新的领域。相信明年的618和双十一,我们的服务稳定性和性能表现,会达到一个更高的高度,不断超越自己。

 

未来

关于未来的工作规划,实际上还有很多方向等待我们去探索实践。比如:

全链路压测落地和演进之路

技术优化

在技术优化规划方面,我们主要集中在针对Dubbo、gRPC等协议的压测组件扩展支持,流量录制回放,全链路压测SOP等方面。其中全链路压测SOP、多协议压测组件支持,已经在路上。

场景覆盖

场景覆盖方面,考虑到后续业务场景的越发复杂,以及大促营销玩法的不断变化,我们会不断拓展核心链路的覆盖范围,探索深度组合场景在全链路压测中的实践,尽可能贴近真实的业务场景。

数据预埋

目前的数据预埋方式相对来说效率还是比较低的,后续规划中,会尝试自动化数据预埋的方案接入,以及缓存预热的方案梳理以及在针对深度组合场景的数据构造方面,有新的探索和实践。

流程提效

通过不断实践和团队的大量演练,后续的大促保障和生产全链路压测,我们希望通过SOP的方式,使其标准化,从经验复用过度到有法可循。

自动化和常态化方面,更多的是技术上的不断创新和落地实践,相信在不久的将来,我们能将这些一一落地,对生产稳定性保障,大促全链路压测,有更好的支持。

 

发表评论

评论已关闭。

相关文章