导读：本次课程介绍在 sae 场景下，如何借助压测工具与 sae 弹性能力来应对大促的实践。主要包含 3 部分要点：传统大促面临的挑战、sae 大促方案以及快速压测验证。
传统大促挑战
一次常见的大促活动，技术人员通常会从下面几个方面着手，进行准备工作：
- 架构梳理：对参与大促的服务，进行系统性的架构梳理；
- 容量规划：结合架构梳理，确定系统 sla 指标，形成容量模型，帮助业务进行评估；
- 性能测试：核心系统的单机容量评估，与核心链路全链路压测，可以验证容量模型，发现系统存在的问题；
- 应用/数据库优化：对发现的系统问题，譬如热点、死锁或慢 sql 等，进行优化，确保系统可以支撑大促；
- 准备扩容方案：通过容量规划与性能测试，可以确定一套满足活动需求的扩容方案，既保障业务，又降低成本；
- 应急预案准备：当遇到突发情况如何应对，譬如业务降级，砍掉非核心逻辑，或者限流降级，保障核心链路稳定；
- 大促在线应急保障：专人专项，对问题进行响应，执行应急预案。
要完成上述准备工作，经常会遇到如下痛点：
- 系统核心全链路，缺少全局关系视角。需要花大量时间，整理依赖关系。
- 链路上下游问题、定位问题比较耗时。压测与在线应急保障过程中，汇总链路上下游问题，定位问题比较耗时，缺少快速定位分析工具。
- 业务开发迭代快，需要常态化压测支持。大量重复性人力投入，给大家造成很大负担。
- 预留资源成本高，需要频繁扩缩容。需要产品化支持自动弹性伸缩，降低自建机房等高成本高闲置的固定投入。
sae 大促ag真人游戏的解决方案
首先，sae 是一款面向应用的 serverless paas 平台，在传统 paas 功能之外，提供了完备的全链路监控、微服务管理等能力，并借助 serverless 能力，最大程度进行快速扩缩容、降低手工运维成本。
sae 提供的ag真人游戏的解决方案，将从三方面入手：
- 指标可视化：借助应用监控 arms 提供丰富的 jvm、全链路 tracing 、慢 sql 等功能，便捷地评估水位、定位问题；
- 应用高可用：借助 ahas 限流降级能力，流量激增时，保护核心服务，保障可用性不完全跌 0；
- 性能压测：借助压测工具如 pts，模拟单机压测或全链路压测，验证容量规划、发现应用问题。
快速压测验证
那么如何通过 sae ，进行一次快速的大促压测验证呢？下面将进行一次完整的展示：
第一步：观察应用监控指标，大致拟定弹性/压测/限流降级
通过观察应用监控，对日常业务的监控指标，有一个大致的概念。以一个典型的电商类应用为例。
从监控情况看：
- 该应用为 http 微服务应用；
- 应用依赖大量 http 微服务调用，少量使用 redis / mysql 服务，适合使用单机 分布式压测工具，分别进行压测；
- qps 指标，相比 cpu、mem 和 rt 指标，对业务更敏感，更适合作为弹性策略指标。
第二步：选择合适的压测工具
根据业务诉求，可以选择快速使用的工具，或功能完整的压测工具。
- 譬如单机 http 压测工具 ab、wrk，可以提供简单快速的压测方式，但只支持单机、不支持上下文。
- 如果我们需要支持 websocket 、常态化压测，云产品 pts 可以提供较为完整的服务，相比自建成本更低。
第三步：配置 sae 弹性伸缩策略 ahas 限流降级策略
无需精准设置，选择一些合适的指标，配置 sae 弹性伸缩策略，或额外配置 ahas 限流策略 / arms 告警。
- 对 api 类型，可通过对 api qps、sql qps 等指标进行限流，保障超过系统水位的请求，快速 failover，降低对容量内业务的 sla；并选择应用监控指标 qps、rt，配置弹性规则，让系统进行弹性伸缩；
- 对于计算型应用，则可选择更敏感的指标，如 cpu、memory 对应用进行扩缩容。
第四步：执行压测 – 观察结果 – 优化代码 – 调整策略配置
1）根据压测与监控结果，看是否有必要优化代码，或调整 sae 弹性伸缩策略、ahas 限流策略。 2）执行压测，查看压测结果，发现存在失败请求。 3）查看监控异常，发现存在 gc 异常。通过 sae 控制台，优化 jvm 参数解决。 4）再次压测，验证问题是否解决。 5）如此重复一两轮，解决其中发现的主要问题，可以更从容地面对大促。
详细演示过程请点击【视频课链接】进行观看。