2.2 弹性伸缩 AS 及最佳实践¶
课程简介¶
弹性伸缩（Auto Scaling，AS）是云原生架构的核心组件之一，它标志着企业 IT 从“手工运维”迈向“自动化运维”的关键一步。本课程将深入讲解弹性伸缩的工作原理，如何利用 AS 实现业务的自动“呼吸”，以及在无状态服务、高可用架构和高性能计算（HPC）场景下的最佳实践。
学习目标¶
通过本课程的学习，您将能够：
- ✓ 理解 AS 核心概念：掌握伸缩组、启动配置、伸缩策略等核心术语。
- ✓ 掌握无状态设计：深刻理解为何弹性伸缩依赖“无状态”架构，并学会通过 Redis/CDB 实现状态外置。
- ✓ 构建高可用架构：学会利用 AS 的“自愈”能力替代传统 HA 集群，实现低成本高可用。
- ✓ 实施 HPC 扩容：掌握利用数据盘快照快速构建大规模计算集群的方法。
- ✓ 整合云生态：熟练配置 AS 与负载均衡（CLB）、云数据库（CDB）及对象存储（COS）的联动。
第一部分：弹性伸缩 AS 概述¶
本部分导读
为什么我们需要弹性伸缩？它不仅仅是为了省钱，更是为了系统的稳定性。本节将介绍 AS 的定义及其四大核心价值。
一、什么是弹性伸缩 AS¶
弹性伸缩（Auto Scaling）是一种根据业务负载情况，自动调整云服务器 CVM 计算资源的管理服务。
- 当业务负载升高时：AS 自动增加 CVM 实例，保证服务能力（扩容）。
- 当业务负载降低时：AS 自动减少 CVM 实例，节省成本（缩容）。
- 当实例发生故障时：AS 自动检测并替换不健康的实例（自愈）。
二、AS 的核心产品优势¶
| 优势 | 传统模式痛点 | AS 解决方案 |
|---|---|---|
| 自动化运维 | 需人工监控，手动买机器、装环境、挂载 | 零人工干预：根据策略自动创建、配置、启动并挂载实例。 |
| 弹性降本 | 按峰值配置资源，低谷期资源浪费严重 | 按需使用：低谷期自动释放资源，极大提高资源利用率。 |
| 服务高可用 | 机器宕机需人工介入重启或切换 | 自动容错：自动检测“失联”实例并创建新实例替换，确保实例数量恒定。 |
| 无缝集成 | 扩容后需手动添加 IP 到负载均衡 | 自动关联：新实例自动注册到 CLB 后端，即刻分担流量。 |
第二部分：核心架构原理与前置条件¶
本部分导读
使用弹性伸缩的前提是应用架构必须支持“随时被销毁”。本节重点讲解无状态服务的重要性。
一、核心组件关系¶
graph TD
Policy[伸缩策略<br>(告警触发/定时/手动)] --> AS_Group[伸缩组<br>(定义最大/最小/期望数量)]
Config[启动配置<br>(定义机型/镜像/存储/网络)] -.-> AS_Group
subgraph 伸缩组内部
Instance1[CVM 1]
Instance2[CVM 2]
InstanceNew[新扩容 CVM]
end
AS_Group --> InstanceNew
InstanceNew -- 自动注册 --> CLB[负载均衡 CLB]
- 启动配置 (Launch Configuration)：定义扩容出来的机器“长什么样”（CPU、内存、镜像、安全组）。
- 伸缩组 (Scaling Group)：定义“在哪里扩”、“扩多少”（最小实例数、最大实例数、所在的子网）。
- 伸缩策略 (Scaling Policy)：定义“什么时候扩”（CPU > 70%、每天上午 9 点）。
二、关键前提：无状态服务 (Stateless)¶
在使用弹性伸缩之前，必须确保应用是无状态的。
2.1 为什么必须无状态？¶
在 AS 环境中，CVM 实例是临时的资源。 - 缩容时，实例会被直接销毁，本地磁盘数据和内存数据将永久丢失。 - 如果用户 Session 存在本地内存，实例销毁会导致用户强制登出。 - 如果日志存在本地文件，实例销毁会导致日志丢失。
2.2 如何改造为无状态？¶
原则：实例不存储任何共享状态数据，所有状态必须“外置”。
| 数据类型 | 传统方式 (有状态) | 云原生改造方式 (无状态) | 配套产品 |
|---|---|---|---|
| 会话状态 | 存储在 Tomcat/PHP 本地内存 | 存储在分布式缓存中 | 云数据库 Redis |
| 结构化数据 | 存储在本地 SQLite/Access | 存储在关系型数据库中 | 云数据库 TDSQL/CDB |
| 非结构化文件 | 图片/视频上传到本地磁盘 | 上传到对象存储 | 对象存储 COS |
| 应用日志 | 写入本地 /var/log | 实时投递到日志服务 | 日志服务 CLS |
优势总结： - 故障恢复快：新实例启动只需拉取代码，无需恢复数据。 - 负载均衡：任意实例都可处理任意请求，请求分发更均匀。
第三部分：AS 最佳实践场景¶
场景一：构建主机高可用（自愈架构）¶
背景： 传统高可用（HA）通常依赖 Keepalived 等软件构建主备集群。这种方式配置复杂，且备机长期闲置，资源浪费。
AS 解决方案： 利用 AS 的“健康检查”功能，构建一个恒定数量的集群。
操作步骤： 1. 制作镜像：将应用程序和环境配置打包成系统镜像。 2. 创建伸缩组： - 设置 最小实例数 = 2。 - 设置 最大实例数 = 2。 - 设置 期望实例数 = 2。 3. 效果： - AS 会确保组内始终有 2 台健康的机器。 - 当监控到某台主机无法 Ping 通（Ping 不可达）或硬件故障时，AS 会自动销毁该故障机，并利用镜像自动创建一台新机器补位。 4. 通知：配置 CMQ 或短信通知，管理员仅需在收到“替换实例”通知时关注即可，无需半夜起床处理故障。
场景二：Web/App 服务动态扩缩容¶
背景： 电商大促、游戏活动等场景，流量波动剧烈。
AS 解决方案： 配合负载均衡（CLB），基于负载指标自动伸缩。
架构设计：
- 配置告警伸缩策略：
- 扩容策略：当集群平均 CPU 使用率 > 70%，增加 2 台实例（冷却时间 300秒）。
- 缩容策略：当集群平均 CPU 使用率 < 30%，减少 1 台实例。
- 集成 CLB：在伸缩组设置中勾选关联的 CLB 实例。
- 扩容时，新机器启动后自动挂载到 CLB，权重设为 10。
- 缩容时，先从 CLB 解绑（停止流量转发），再销毁机器，实现优雅下线。
场景三：高性能计算 (HPC) 与数据处理¶
背景： 多组学检测、基因测序、渲染农场等业务，通常是项目制的。项目开始时需要上千核算力，结束后需释放。
挑战： 计算节点启动后，通常需要加载数百 GB 的基础数据（如基因库参考数据）才能开始工作，传输耗时极长。
AS 解决方案：基于数据盘快照的极速启动
- 数据预处理：
- 启动一台种子机，将通用的基础数据（Reference Data）写入数据盘。
- 对该数据盘制作快照 (Snapshot)。
- 配置启动配置：
- 在“数据盘”选项中，选择“基于快照创建”。
- 伸缩策略：
- 定时伸缩：项目每天晚上 20:00 开始，设置定时策略将期望实例数调整为 100 台。
- 手工伸缩：管理员在控制台直接修改期望实例数。
- 效果：
- 100 台新扩容的计算节点，在启动完成的那一刻，数据盘中就已经自带了数百 GB 的业务数据，省去了漫长的下载过程，直接开始计算。
- 计算结果写入 对象存储 COS 进行长期归档。
第四部分：AS 与云生态的协同¶
弹性伸缩不是孤立存在的，它需要与腾讯云的其他“积木”配合才能发挥最大效能。
| 协同产品 | 作用 | 最佳实践 |
|---|---|---|
| 负载均衡 (CLB) | 流量入口与分发 | 务必在伸缩组中绑定 CLB，确保新节点自动接流。 |
| 云数据库 (CDB/TDSQL) | 结构化数据存储 | 配置数据库白名单时，使用伸缩组所在的网段或关联的安全组，而非具体 IP（因为 IP 会变）。 |
| 云 Redis | 会话状态存储 | 必须使用 Redis 存储 Session，实现应用无状态。 |
| 对象存储 (COS) | 静态文件/大文件存储 | 动静分离，静态资源上传 COS，减轻 CVM 带宽压力。 |
| 云监控 (Cloud Monitor) | 触发伸缩的“眼睛” | 建议设置多维度的伸缩指标（如不仅看 CPU，也要看内存或 QPS）。 |
课程总结¶
关键知识点回顾¶
- AS 的本质：它是 CVM 的自动化管家，负责生（扩容）、死（缩容）、养（自愈）。
- 核心原则：无状态（Stateless）。任何不能随时被销毁的实例都不适合放入伸缩组。
- 高可用新解：利用 AS 的“维持期望实例数”功能，可以低成本实现服务器级别的故障自愈。
- HPC 技巧：利用“数据盘快照”功能，可以解决大规模计算集群数据分发的耗时痛点。
架构师检查清单 (Checklist)¶
在设计弹性伸缩架构时，请自查： - [ ] 应用无状态：Session 是否已移入 Redis？日志是否已对接 CLS？ - [ ] 镜像标准化：启动配置中使用的镜像是否包含了最新的应用程序代码和依赖？（或者在 UserData 中配置了开机自动拉取代码） - [ ] 网络连通性：扩容出的子网 IP 数量是否充足？是否能访问数据库？ - [ ] 冷却时间：是否设置了合理的冷却时间（如 300秒），防止系统在波动中频繁扩缩容（震荡）？ - [ ] 数据保护：缩容策略是否配置合理？是否选择了“销毁移出”以彻底停止计费？
下一章，我们将讲解云原生时代的基石——2.3 容器服务 TKE 及最佳实践。