98 lines
4.8 KiB
Markdown
98 lines
4.8 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
28 如何通过压测工具+ SAE 弹性能力轻松应对大促
|
||
传统大促挑战
|
||
|
||
|
||
|
||
一次常见的大促活动，技术人员通常会从下面几个方面着手，进行准备工作：
|
||
|
||
|
||
架构梳理：对参与大促的服务，进行系统性的架构梳理；
|
||
容量规划：结合架构梳理，确定系统 SLA 指标，形成容量模型，帮助业务进行评估；
|
||
性能测试：核心系统的单机容量评估，与核心链路全链路压测，可以验证容量模型，发现系统存在的问题；
|
||
应用/数据库优化：对发现的系统问题，譬如热点、死锁或慢 SQL 等，进行优化，确保系统可以支撑大促；
|
||
准备扩容方案：通过容量规划与性能测试，可以确定一套满足活动需求的扩容方案，既保障业务，又降低成本；
|
||
应急预案准备：当遇到突发情况如何应对，譬如业务降级，砍掉非核心逻辑，或者限流降级，保障核心链路稳定；
|
||
大促在线应急保障：专人专项，对问题进行响应，执行应急预案。
|
||
|
||
|
||
要完成上述准备工作，经常会遇到如下痛点：
|
||
|
||
|
||
系统核心全链路，缺少全局关系视角。需要花大量时间，整理依赖关系。
|
||
链路上下游问题、定位问题比较耗时。压测与在线应急保障过程中，汇总链路上下游问题，定位问题比较耗时，缺少快速定位分析工具。
|
||
业务开发迭代快，需要常态化压测支持。大量重复性人力投入，给大家造成很大负担。
|
||
预留资源成本高，需要频繁扩缩容。需要产品化支持自动弹性伸缩，降低自建机房等高成本高闲置的固定投入。
|
||
|
||
|
||
SAE 大促解决方案
|
||
|
||
|
||
|
||
首先，SAE 是一款面向应用的 Serverless PaaS 平台，在传统 PaaS 功能之外，提供了完备的全链路监控、微服务管理等能力，并借助 Serverless 能力，最大程度进行快速扩缩容、降低手工运维成本。
|
||
|
||
|
||
|
||
SAE 提供的解决方案，将从三方面入手：
|
||
|
||
|
||
指标可视化：借助应用监控 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）如此重复一两轮，解决其中发现的主要问题，可以更从容地面对大促。
|
||
|
||
详细演示过程请点击【视频课链接】进行观看。
|
||
|
||
|
||
|
||
|