精准容量、秒级弹性,压测工具 + SAE 方案如何成功突破传统大促难关?

本文涉及的产品
函数计算FC,每月15万CU 3个月
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
简介: 本次课程介绍在 SAE 场景下,如何借助压测工具与 SAE 弹性能力来应对大促的实践。主要包含 3 部分要点:传统大促面临的挑战、SAE 大促方案以及快速压测验证。

头图.jpg

作者 | 代序 阿里云云原生技术团队

本文整理自《Serverless 技术公开课》,“Serverless”公众号后台回复“入门”,即可获取系列文章 PPT。

导读:本次课程介绍在 SAE 场景下,如何借助压测工具与 SAE 弹性能力来应对大促的实践。主要包含 3 部分要点:传统大促面临的挑战、SAE 大促方案以及快速压测验证。

传统大促挑战

1.JPG

一次常见的大促活动,技术人员通常会从下面几个方面着手,进行准备工作:

  • 架构梳理:对参与大促的服务,进行系统性的架构梳理;
  • 容量规划:结合架构梳理,确定系统 SLA 指标,形成容量模型,帮助业务进行评估;
  • 性能测试:核心系统的单机容量评估,与核心链路全链路压测,可以验证容量模型,发现系统存在的问题;
  • 应用/数据库优化:对发现的系统问题,譬如热点、死锁或慢 SQL 等,进行优化,确保系统可以支撑大促;
  • 准备扩容方案:通过容量规划与性能测试,可以确定一套满足活动需求的扩容方案,既保障业务,又降低成本;
  • 应急预案准备:当遇到突发情况如何应对,譬如业务降级,砍掉非核心逻辑,或者限流降级,保障核心链路稳定;
  • 大促在线应急保障:专人专项,对问题进行响应,执行应急预案。

要完成上述准备工作,经常会遇到如下痛点:

  • 系统核心全链路,缺少全局关系视角。需要花大量时间,整理依赖关系。
  • 链路上下游问题、定位问题比较耗时。压测与在线应急保障过程中,汇总链路上下游问题,定位问题比较耗时,缺少快速定位分析工具。
  • 业务开发迭代快,需要常态化压测支持。大量重复性人力投入,给大家造成很大负担。
  • 预留资源成本高,需要频繁扩缩容。需要产品化支持自动弹性伸缩,降低自建机房等高成本高闲置的固定投入。

SAE 大促解决方案

2.JPG

首先,SAE 是一款面向应用的 Serverless PaaS 平台,在传统 PaaS 功能之外,提供了完备的全链路监控、微服务管理等能力,并借助 Serverless 能力,最大程度进行快速扩缩容、降低手工运维成本。

3.JPG

SAE 提供的解决方案,将从三方面入手:

  • 指标可视化:借助应用监控 ARMS 提供丰富的 JVM、全链路 Tracing 、慢 SQL 等功能,便捷地评估水位、定位问题;
  • 应用高可用:借助 AHAS 限流降级能力,流量激增时,保护核心服务,保障可用性不完全跌 0;
  • 性能压测:借助压测工具如 PTS,模拟单机压测或全链路压测,验证容量规划、发现应用问题。

快速压测验证

那么如何通过 SAE ,进行一次快速的大促压测验证呢?下面将进行一次完整的展示:

第一步:观察应用监控指标,大致拟定弹性/压测/限流降级

4.JPG

通过观察应用监控,对日常业务的监控指标,有一个大致的概念。以一个典型的电商类应用为例。

从监控情况看:

  • 该应用为 HTTP 微服务应用;
  • 应用依赖大量 HTTP 微服务调用,少量使用 Redis / MySQL 服务,适合使用单机 + 分布式压测工具,分别进行压测;
  • QPS 指标,相比 CPU、MEM 和 RT 指标,对业务更敏感,更适合作为弹性策略指标。

第二步:选择合适的压测工具

5.JPG

根据业务诉求,可以选择快速使用的工具,或功能完整的压测工具。

  • 譬如单机 HTTP 压测工具 ab、wrk,可以提供简单快速的压测方式,但只支持单机、不支持上下文。
  • 如果我们需要支持 WebSocket 、常态化压测,云产品 PTS 可以提供较为完整的服务,相比自建成本更低。

第三步:配置 SAE 弹性伸缩策略 + AHAS 限流降级策略

6.JPG

无需精准设置,选择一些合适的指标,配置 SAE 弹性伸缩策略,或额外配置 AHAS 限流策略 / ARMS 告警。

  • 对 API 类型,可通过对 API QPS、SQL QPS 等指标进行限流,保障超过系统水位的请求,快速 failover,降低对容量内业务的 SLA;并选择应用监控指标 QPS、RT,配置弹性规则,让系统进行弹性伸缩;
  • 对于计算型应用,则可选择更敏感的指标,如 CPU、Memory 对应用进行扩缩容。

第四步:执行压测 – 观察结果 – 优化代码 – 调整策略配置

7.JPG

1)根据压测与监控结果,看是否有必要优化代码,或调整 SAE 弹性伸缩策略、AHAS 限流策略。
2)执行压测,查看压测结果,发现存在失败请求。
3)查看监控异常,发现存在 GC 异常。通过 SAE 控制台,优化 JVM 参数解决。
4)再次压测,验证问题是否解决。
5)如此重复一两轮,解决其中发现的主要问题,可以更从容地面对大促。

详细演示过程请点击【视频课链接】进行观看。

课程推荐

为了更多开发者能够享受到 Serverless 带来的红利,这一次,我们集结了 10+ 位阿里巴巴 Serverless 领域技术专家,打造出最适合开发者入门的 Serverless 公开课,让你即学即用,轻松拥抱云计算的新范式——Serverless。点击即可免费观看课程:https://developer.aliyun.com/learning/roadmap/serverless

Serverless 公众号,发布 Serverless 技术最新资讯,汇集 Serverless 技术最全内容,关注 Serverless 趋势,更关注你落地实践中的遇到的困惑和问题。

相关文章
|
7月前
|
应用服务中间件 测试技术 Linux
|
7月前
|
Kubernetes Serverless 开发者
阿里云 SAE 2.0 正式商用,极简易用、百毫秒弹性效率,降本 40%
本文主要介绍阿里云 Serverless 应用引擎如何帮助企业跨越技术鸿沟,从传统应用架构无感升级到 Serverless 架构,以更高效、更经济的方式进行转型,快速进入云原生快车道,让 2 人的研发团队享受 2000 人技术团队的红利。
|
监控 负载均衡 Java
SAE极速部署弹性微服务商城
通过SAE快速部署并上线一套网上商城,感受Serverless 免运维、低门槛的魅力。
|
运维 测试技术
千万级乘客排队系统重构&压测方案——总结篇
千万级乘客排队系统重构&压测方案——总结篇
189 1
|
监控 安全 Java
全链路压测(2):方案调研和项目立项
一般来说,像生产全链路压测这种复杂的需要多个技术团队参与的复杂技术项目,在企业内部都会有一个项目申报和评估立项的过程。
全链路压测(2):方案调研和项目立项
|
监控 测试技术 UED
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(1)
304 0
|
域名解析 网络协议 数据可视化
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
《云上业务稳定性保障实践白皮书》——五.行业客户稳定性保障实践——5.3 平台网站业务稳定性保障——5.3.2 全链路压测与容量评估(2)
215 0
|
运维 监控 安全
全链路压测(9):容量评估和容量规划
容量评估我在之前的文章《性能测试从零开始实施指南——容量评估篇》中已做过详细介绍,这里不多做赘述。关于容量评估,参考下面两张思维导图,更容易理解。
全链路压测(9):容量评估和容量规划
全链路压测常态化方案
压测任务正式开始前,设定并检查压测的SLA阈值,确保压测流量不会导致生产服务负载过高出现异常;
全链路压测常态化方案
|
域名解析 缓存 监控
性能测试 性能测试方案设计思路总结
性能测试 性能测试方案设计思路总结
389 0

相关产品

  • Serverless 应用引擎