1. 弹性伸缩AS到底解决什么问题1.1 从一次流量突增说起做过线上业务的人大概都经历过这种时刻某个活动页面突然被推上热门或者某个时间点流量毫无征兆地翻了好几倍监控面板上的CPU曲线像坐了火箭一样往上窜然后就是告警、卡顿、甚至服务不可用。等你手忙脚乱地去控制台手动加机器再等系统初始化、环境拉起、服务注册黄花菜都凉了。弹性伸缩Auto Scaling简称AS就是冲着这个场景来的。它的核心逻辑非常朴素你提前定义好规则系统根据监控指标自动帮你增减计算资源。流量涨了自动加机器流量落了自动减机器整个过程不需要人盯着。我第一次接触AS是在一个电商类项目里当时做的是限时抢购场景。平时后端服务跑在4台机器上绰绰有余但一到整点开抢QPS能瞬间涨到平时的十几倍。最开始的做法是提前手动扩容到20台活动结束再手动缩回来费时费力不说还经常估不准——估多了浪费钱估少了扛不住。后来换成AS之后整个扩容过程压缩到几分钟内自动完成成本也降下来了。1.2 弹性伸缩的适用边界AS不是万能的它有自己的适用场景和局限。适合用的场景包括流量有明显波峰波谷比如白天高、夜间低或者有固定活动周期无状态服务后端API、Web服务这类不依赖本地存储的服务最适合可水平扩展的业务加一台机器就能分担一部分流量而不是必须纵向升级配置不太适合的场景也得说清楚有状态服务比如数据库主节点加机器解决不了问题反而可能引入数据一致性风险启动极慢的服务如果一台机器从创建到能对外服务需要十几分钟那弹性伸缩的响应速度就跟不上流量变化流量波动极其剧烈且不可预测秒级突增几十倍的情况AS的冷却时间和触发延迟可能来不及提示判断一个服务能不能上AS最简单的标准就是问自己一句——“再加一台一模一样的机器能不能直接分担流量”如果答案是能那就适合。1.3 核心概念速览在动手之前有几个概念必须先搞清楚否则后面配置的时候容易懵概念含义类比伸缩组一组具有相同配置的实例集合一个班的学生伸缩配置定义实例的规格、镜像、网络等模板学生的入学标准伸缩规则触发扩容或缩容的条件班级人数多了就分班冷却时间一次伸缩动作后等待多久才能再次触发刚分完班先稳定一会儿最小值/最大值伸缩组内实例数量的边界班级最少几人、最多几人这些概念之间的关系是伸缩组引用伸缩配置来创建实例伸缩规则决定什么时候创建或销毁实例冷却时间防止频繁抖动最小最大值兜底。理解了这套关系后面的实操就是按部就班的事。2. 在线实验环境准备与伸缩组创建2.1 实验前的检查清单在线实验环境通常是平台已经预置好的沙箱环境进去之后会有一个临时账号和一定的资源配额。开始之前建议先确认几件事账号权限确认当前账号有弹性伸缩、ECS、SLB负载均衡的操作权限。有些沙箱环境会限制部分高危操作提前看一眼免得做到一半卡住。地域选择弹性伸缩是地域级别的服务伸缩组只能管理同一地域内的实例。选一个你熟悉的、有可用资源的地域后面排查问题方便。配额检查确认当前地域的ECS实例配额够用。如果伸缩组最大值设了10台但配额只剩5台那扩容到5台就会失败。网络规划想清楚实例放在哪个VPC、哪个交换机下。如果是多可用区部署需要提前规划好多个交换机。这些检查看起来琐碎但实际做实验的时候十次里有三四次卡壳都是因为这些前置条件没确认。2.2 创建伸缩组的完整流程进入弹性伸缩控制台后点击创建伸缩组会看到一个表单。这个表单的信息量不小我逐项拆解一下基础信息部分伸缩组名称起一个有意义的名字比如web-as-group方便后面识别伸缩组类型选择ECS如果是ECI或其他类型按需选组内实例数这里设置最小实例数和最大实例数。最小实例数建议至少设为2保证基本的高可用最大实例数根据配额和预算来定配置来源部分这是最关键的一步。伸缩组需要知道“用什么模板来创建实例”有两种方式从现有实例创建选一台已经配置好的ECS实例系统会自动提取它的镜像、规格、网络配置等信息生成伸缩配置。这种方式最省事适合实验环境。手动创建伸缩配置自己指定镜像ID、实例规格、安全组、密钥对等。灵活度高但需要你对各项参数比较熟悉。在实验环境里通常推荐第一种方式因为沙箱里一般已经预置了一台配置好的实例直接引用它最省时间。网络与可用区部分选择VPC和交换机。如果要做多可用区高可用就选多个交换机选择实例的分配策略优先选择哪个可用区、是否均衡分布高级设置部分冷却时间默认300秒实验环境可以调短一点比如60秒方便观察效果健康检查方式ECS健康检查或负载均衡健康检查移出策略缩容时优先移除哪台实例填完这些点击创建伸缩组就建好了。但此时组内还没有实例需要手动触发一次扩容或者等伸缩规则生效。2.3 伸缩配置的关键参数解读伸缩配置决定了每一台自动创建出来的实例长什么样。几个容易踩坑的参数实例规格不要选太小的规格比如1核1G因为这种规格在很多地域已经停售或者库存紧张扩容时容易创建失败。实验环境一般选2核4G比较稳妥。镜像镜像里必须已经装好了你的应用环境和启动脚本。如果镜像里什么都没配创建出来的实例就是个空壳加进去也没用。这是新手最容易忽略的一点——AS只负责创建实例不负责部署应用应用部署要么打在镜像里要么通过启动模板的用户数据脚本自动执行。安全组确保安全组放行了必要的端口比如Web服务的80/443SSH的22。如果伸缩组关联了负载均衡还要确保负载均衡的健康检查端口是通的。密钥对如果后续需要登录实例排查问题密钥对必须提前设置好。实验环境里有时候会提供一个默认密钥注意保存。注意伸缩配置创建后并非一成不变但修改伸缩配置不会影响已经创建的实例只影响后续新创建的实例。这个特性在做配置更新时很有用但也容易造成新旧实例配置不一致的问题。3. 伸缩规则与触发机制详解3.1 三种伸缩规则的对比弹性伸缩支持多种触发方式常见的有三类定时任务在指定时间点执行扩容或缩容。比如每天上午9点扩容到10台晚上10点缩容到2台。适合流量规律非常明确的业务。动态伸缩基于监控指标根据CPU使用率、内存使用率、网络流量等指标自动触发。比如CPU平均使用率超过70%就扩容一台低于30%就缩容一台。这是最常用的方式。自定义伸缩通过API或SDK手动触发适合一些特殊场景比如配合CI/CD流水线在发布时临时扩容。三种方式可以组合使用。比如平时用动态伸缩应对日常波动大促期间叠加定时任务提前扩容。3.2 动态伸缩规则的参数计算动态伸缩规则里最核心的参数是触发阈值和伸缩幅度。这两个值怎么定直接决定了弹性伸缩的效果。先说阈值。以CPU使用率为指标假设你的服务在CPU达到60%时响应时间开始明显上升那告警阈值可以设在60%到70%之间。设太低会导致频繁扩容设太高又来不及响应。再说伸缩幅度。有两种模式调整到指定数量比如“CPU超过70%时实例数调整为10台”按比例或固定数量增减比如“CPU超过70%时增加2台”实验环境里推荐用固定数量增减因为更容易观察效果。生产环境里更常用按比例调整比如每次增加当前实例数的20%。这里有个经验公式可以参考期望实例数 当前实例数 × (当前指标值 / 目标指标值)举个例子当前4台机器CPU使用率80%目标使用率是50%那期望实例数 4 × (80/50) 6.4取整就是7台。这个公式在流量线性增长的情况下比较准但实际业务往往不是线性的所以还需要结合冷却时间和最大最小值来兜底。3.3 冷却时间的设置逻辑冷却时间是指一次伸缩活动完成后多久之内不再触发新的伸缩活动。这个参数的作用是防止抖动。想象一下没有冷却时间的情况CPU超过70%扩容2台新机器刚创建还没完全启动CPU还是高又触发扩容2台再过一会儿又触发……结果一下子扩了一堆机器出来等新机器都开始干活了CPU骤降又开始疯狂缩容。这种来回震荡对系统稳定性伤害很大。冷却时间的设置要考虑两个因素实例启动到可服务的时间如果一台机器从创建到能处理请求需要3分钟那冷却时间至少设3分钟以上监控数据的采集周期监控指标通常有1分钟左右的延迟冷却时间要覆盖这个延迟实验环境里设60到120秒比较合适生产环境一般设300秒起步。3.4 实验中的规则配置实操在在线实验里通常会让你配置一条这样的规则监控指标CPU平均使用率触发条件大于70%伸缩动作增加1台冷却时间60秒配置完成后你需要想办法让CPU使用率升上去。实验环境里一般会提供一个压测工具或者一段脚本来模拟负载。常见做法是登录到实例上跑一个CPU密集型的命令比如# 用stress工具模拟CPU负载 stress --cpu 2 --timeout 300或者如果没有stress工具可以用一个简单的shell循环# 启动4个进程持续消耗CPU for i in $(seq 1 4); do dd if/dev/zero of/dev/null done跑起来之后等几分钟观察伸缩组的活动记录应该能看到扩容动作被触发。4. 负载均衡与健康检查的配合4.1 为什么伸缩组要挂负载均衡伸缩组本身只负责创建和销毁实例但流量怎么分配到这些实例上是负载均衡SLB的事。如果不挂负载均衡新扩容出来的实例虽然存在但流量根本不会流到它上面扩容就白做了。挂载负载均衡的流程一般是先创建一个负载均衡实例配置好监听端口和后端服务器组在创建伸缩组时选择关联这个负载均衡伸缩组自动将新创建的实例加入到负载均衡的后端服务器组缩容时自动将移除的实例从后端服务器组摘除这个联动机制是弹性伸缩能真正发挥作用的关键。没有它AS就只是个批量创建ECS的工具。4.2 健康检查的两种模式伸缩组的健康检查决定了它如何判断一台实例是否“健康”。有两种模式ECS健康检查只检查实例的运行状态只要实例是Running状态就算健康。这种模式比较简单但不够准确——实例虽然运行着但里面的服务可能已经挂了。负载均衡健康检查通过负载均衡的健康检查机制来判断通常是发一个HTTP请求到指定路径看返回码是否正常。这种模式更贴近真实的服务状态。生产环境强烈建议用负载均衡健康检查。实验环境里如果时间有限用ECS健康检查也能跑通流程但要理解两者的区别。健康检查发现不健康的实例后伸缩组会自动将其移出并创建新实例替换。这个替换过程也受冷却时间约束。4.3 实验中的关联操作在在线实验里关联负载均衡的步骤通常是在负载均衡控制台创建一个CLB实例配置TCP或HTTP监听创建一个虚拟服务器组后端服务器组回到伸缩组配置页面在“关联负载均衡”选项中选择刚创建的CLB和服务器组确认伸缩组的网络配置和负载均衡在同一个VPC下这里有个容易出错的点负载均衡的监听端口必须和实例上实际提供的服务端口一致。比如你的Web服务跑在8080端口但负载均衡监听的是80端口那健康检查就会失败所有实例都会被判定为不健康。提示实验环境里如果负载均衡创建后一直显示后端服务器异常先检查安全组是否放行了负载均衡到后端实例的流量再检查健康检查的端口和路径是否正确。5. 常见问题排查与避坑经验5.1 扩容失败的高频原因扩容失败是实验和实际使用中最常见的问题。根据我的经验原因基本集中在以下几类问题现象可能原因排查方向扩容活动显示失败实例规格库存不足换一个规格或换可用区扩容活动显示失败ECS配额已满检查配额清理无用实例扩容成功但实例未加入SLB网络不通或安全组限制检查VPC、交换机、安全组扩容成功但服务不可用镜像内应用未启动检查镜像和启动脚本扩容触发但迟迟不执行冷却时间未过查看上次伸缩活动时间其中“实例规格库存不足”是最让人头疼的因为它不是配置问题而是资源池的客观限制。解决办法通常是准备多个规格作为备选或者选择库存充足的可用区。5.2 缩容时误删实例的处理缩容时伸缩组会根据移出策略选择要移除的实例。默认策略通常是移除最早创建的实例但这个策略不一定总是合理。比如你刚手动登录到某台实例上排查问题结果缩容时恰好把它移除了排查现场就没了。为了避免这种情况可以使用保护状态对不想被缩容的实例开启保护伸缩组会跳过它调整移出策略选择“最新创建的实例优先移除”或“根据自定义策略移除”在缩容前先确认没有正在处理重要任务的实例实验环境里这个问题不突出但生产环境里一定要重视。我见过一次因为缩容移除了正在处理批量任务的实例导致任务中断需要重跑的情况。5.3 监控指标延迟导致的误判监控数据从采集到展示通常有1到3分钟的延迟。这意味着你看到的CPU使用率其实是几分钟前的状态。如果业务流量变化很快基于延迟数据做出的伸缩决策可能已经过时了。应对方法有两个缩短监控采集周期有些监控服务支持更细粒度的采集比如10秒一次结合多种指标不要只看CPU可以同时看网络流量、请求数等指标综合判断在实验环境里因为负载是人为制造的变化比较平缓这个问题不明显。但理解这个延迟的存在对生产环境配置伸缩规则很有帮助。5.4 实验环境特有的注意事项在线实验环境和真实生产环境有一些差异做实验时要注意沙箱环境有超时限制一般在线实验有时间限制到点会自动回收资源。所以操作要紧凑别在无关步骤上浪费时间。部分功能可能被限制比如某些高危API调用、跨地域操作等可能被沙箱策略拦截。计费方式不同实验环境通常不计费或使用模拟计费但生产环境里AS创建实例是真实计费的缩容不及时会导致成本上升。实验步骤有引导在线实验一般会给出步骤指引但指引往往只告诉你“做什么”不告诉你“为什么”。理解每一步背后的逻辑比机械照做更有价值。6. 从实验到生产的差距与思考6.1 实验里跑通不等于生产可用在线实验最大的价值是让你快速熟悉操作流程和核心概念但它和生产环境之间有几道明显的鸿沟第一道鸿沟是应用部署。实验里通常用预置好的镜像里面应用已经配好了。但生产环境里你的应用可能需要从代码仓库拉取、编译、配置环境变量、连接数据库、注册服务发现……这些步骤要么打进镜像要么通过启动脚本自动化否则扩容出来的实例就是废的。第二道鸿沟是流量接入。实验里挂个负载均衡就完事了生产环境里还涉及DNS解析、CDN回源、网关路由、灰度发布等一系列环节。新扩容的实例能不能正确接入流量需要整条链路都验证过。第三道鸿沟是数据一致性。无状态服务好办但如果服务依赖缓存、消息队列、分布式锁等组件新实例加入后这些组件的连接和状态需要正确处理。6.2 成本控制的现实考量弹性伸缩的一个核心卖点是“省钱”但用得不好反而可能更费钱。几个成本相关的经验缩容要果断扩容大家都很积极但缩容往往犹犹豫豫。结果就是机器越加越多流量下去了也不减账单悄悄涨上去。设置合理的最大值最大值是成本的天花板。如果不设或设得过高遇到异常流量时可能瞬间创建大量实例。关注闲置实例伸缩组里长期处于最低实例数状态的机器如果业务量确实很小可以考虑进一步降低最小值。混合计费策略对基线负载使用包年包月实例对弹性部分使用按量付费实例兼顾成本和弹性。6.3 后续可以深入的方向把弹性伸缩的基本流程跑通之后还有几个方向值得继续深入多指标组合伸缩不只看CPU结合QPS、响应时间、队列长度等业务指标做综合判断预测性伸缩基于历史数据预测未来流量提前扩容而不是等指标触发容器化弹性伸缩如果服务已经容器化可以结合容器编排平台的弹性能力粒度更细、启动更快混沌工程验证主动模拟实例故障、可用区故障验证伸缩组的自愈能力和业务连续性我个人在实际操作中的体会是弹性伸缩这个工具本身不复杂难的是把它和你的业务特性匹配好。阈值设多少、冷却时间多长、用哪种触发方式这些都没有标准答案需要在实践中不断调整。实验环境给了你一个零成本的试错空间把基本流程和常见问题都摸一遍回到真实环境里就能少踩很多坑。