企业官网建设流程全解析

1. 弹性伸缩AS到底解决什么问题

1.1 从一个真实场景说起

假设你负责维护一个电商平台的Web服务，平时日均访问量稳定在几千QPS，但每逢大促活动，流量会在几分钟内暴涨到平时的十倍甚至几十倍。如果按照峰值流量来配置服务器，平时就会有大量资源闲置，成本高得离谱；如果按照日常流量配置，大促一来系统直接被打挂，用户流失、订单丢失，损失更大。

这个矛盾就是弹性伸缩要解决的核心问题：让计算资源随业务负载自动调整，用多少付多少，既保证高峰期的稳定性，又不为低谷期的闲置买单。

弹性伸缩（Auto Scaling，简称AS）是云计算中最核心的能力之一。它的基本逻辑并不复杂：你定义一组规则，系统根据监控指标自动增加或减少ECS实例数量。但真正把它用好，需要理解不少细节，比如伸缩组的配置逻辑、冷却时间的设置、伸缩规则的触发条件、和负载均衡的配合方式等等。

1.2 弹性伸缩的核心组件

在动手操作之前，先把几个关键概念理清楚，不然后面配置的时候容易懵。

伸缩组（Scaling Group）是弹性伸缩的基本管理单元。一个伸缩组里定义了三个核心要素：最大实例数、最小实例数和当前期望实例数。你可以把它理解为一个“实例池”，系统会保证池子里的实例数量始终在[min, max]区间内，并尽量维持在期望值附近。

伸缩配置（Scaling Configuration）决定了新创建的ECS实例长什么样——用什么镜像、什么规格、挂什么安全组、要不要加入负载均衡。伸缩配置是伸缩组扩容时的“模板”，一旦设定，后续自动创建的实例都按这个模板来。

伸缩规则（Scaling Rule）是触发伸缩动作的条件。可以是简单的定时规则（比如每天晚8点扩容到10台），也可以是基于监控指标的动态规则（比如CPU平均使用率超过70%就扩容2台）。

冷却时间（Cooldown）是一个容易被忽视但非常重要的参数。每次伸缩活动完成后，系统会进入冷却期，在此期间不会响应新的伸缩请求。这个机制是为了防止频繁伸缩导致的“震荡”——比如刚扩容完，新实例还没开始分担负载，监控指标还没降下来，系统又触发一次扩容，结果实例加多了。

1.3 为什么选择在线实验来学习AS

弹性伸缩这个功能，光看文档很难真正理解。文档会告诉你“设置最小实例数为2，最大为10”，但你不知道的是：扩容出来的实例多久能进入负载均衡？冷却时间设多少合适？伸缩规则里那个“统计周期”到底怎么算？

在线实验的价值就在于，它提供了一个真实的云环境，你可以亲手创建伸缩组、配置伸缩规则、观察扩容过程、验证缩容逻辑。这种“做一遍”的经验，比看十遍文档都管用。而且实验环境通常有预置的资源，不需要你自己从头搭建VPC、交换机、安全组这些基础设施，可以把精力集中在弹性伸缩本身的逻辑上。

2. 实验环境准备与前置检查

2.1 实验资源清单

在线实验通常会预置好以下资源，你需要先确认它们的状态：

这些资源之间的关系是：SLB挂载伸缩组内的实例，对外提供统一入口；伸缩组根据规则自动增减ECS实例；所有实例都在同一个VPC内，通过安全组控制访问。

2.2 创建自定义镜像

这是整个实验中最关键的前置步骤之一。伸缩组扩容时，新实例是基于“伸缩配置”创建的，而伸缩配置的核心就是镜像。如果你直接用系统镜像，新扩容出来的实例就是一个干净的操作系统，里面没有你的应用代码、没有配置好的Web服务，扩容了也没用。

所以第一步是：把已经部署好应用的ECS实例制作成自定义镜像。

操作路径是：登录ECS控制台 → 找到目标实例 → 创建自定义镜像。这里有几个细节需要注意：

• 创建镜像前，最好先停止实例，确保数据一致性。如果实例正在运行，内存中的数据可能没有完全落盘，制作出来的镜像可能有问题。
• 镜像创建需要几分钟时间，期间可以去做其他配置。
• 镜像名称建议包含应用名称和版本号，比如“webapp-v1.2”，方便后续管理。

注意：自定义镜像会占用快照存储空间，产生少量费用。实验环境中通常有额度，但正式使用时要注意清理不再需要的镜像。

2.3 确认应用的自启动配置

新扩容出来的实例，开机后需要自动启动Web服务。如果你的应用是通过systemd管理的，确认服务已经设置为开机自启：

systemctl enable nginx systemctl enable your-app

如果是通过脚本启动的，可以把启动命令写入/etc/rc.local或者创建一个systemd service文件。这一步如果漏了，扩容出来的实例虽然运行着，但Web服务没起来，SLB的健康检查会失败，实例会被判定为异常。

3. 伸缩组与伸缩配置的创建实操

3.1 创建伸缩组的关键参数

进入弹性伸缩控制台，创建伸缩组。这里有几个参数需要仔细设置：

伸缩组名称：建议用有意义的命名，比如“web-as-group”，方便在多个伸缩组之间区分。

最小实例数：这个值决定了伸缩组的下限。设置得太小，缩容时可能把实例全干掉，服务直接不可用。一般建议至少设置为2，保证高可用。实验中可以设为1，方便观察缩容效果。

最大实例数：上限，防止无限扩容导致成本失控。根据业务峰值预估，实验中设为5或10即可。

期望实例数：初始状态下的实例数量。通常设置为最小实例数，或者略大一些。

移出策略：当缩容时，系统按什么规则选择要移除的实例。常见策略有“最早创建的实例”、“最新创建的实例”、“最旧伸缩配置的实例”等。一般选择“最早创建的实例”，因为老实例可能积累了一些状态，移除后新实例更干净。

冷却时间：默认300秒。这个值需要根据应用的启动时间和监控指标的采集周期来调整。如果应用启动需要2分钟，监控指标每1分钟采集一次，那冷却时间至少设180秒，否则新实例还没启动完，系统又触发扩容。

3.2 伸缩配置的详细设置

创建伸缩配置时，需要指定以下内容：

• 镜像：选择刚才创建的自定义镜像。
• 实例规格：根据应用需求选择CPU和内存配置。实验中选最低配即可。
• 安全组：选择与种子实例相同的安全组。
• 登录凭证：可以设置密钥对或密码，实验中通常用密码方便调试。
• 公网IP：如果实例需要访问外网，勾选“分配公网IP”。如果通过NAT网关访问外网，则不勾选。
• 加入负载均衡：选择实验预置的SLB实例和对应的后端服务器组。

实操心得：伸缩配置创建后不能修改，如果需要调整，只能创建新的配置并应用到伸缩组。所以第一次创建时就要想清楚，避免反复重建。

3.3 验证伸缩组初始状态

伸缩组创建完成后，系统会自动创建“期望实例数”指定数量的ECS实例。等待几分钟，观察实例列表：

• 实例是否成功创建并运行？
• 实例是否已加入SLB的后端服务器组？
• SLB的健康检查是否通过？

如果健康检查失败，登录到新创建的实例，检查Web服务是否正常运行、安全组是否放行了SLB的健康检查端口。这一步排查清楚了，后面的伸缩规则才能正常工作。

4. 伸缩规则的配置与触发验证

4.1 定时伸缩规则

定时伸缩适合可预测的流量变化，比如每天固定时间段的流量高峰。配置方式很简单：指定触发时间、重复周期、伸缩动作（增加或减少多少台实例）。

比如，设置每天上午9点扩容2台，晚上9点缩容2台。这种规则的好处是确定性高，不需要依赖监控数据，适合流量模式稳定的业务。

实验中可以设置一条“5分钟后扩容1台”的定时规则，观察系统是否按时执行。执行后，在伸缩活动记录中可以看到详细的日志：触发时间、执行结果、实例增减数量。

4.2 动态伸缩规则

动态伸缩基于监控指标自动触发，更灵活，但也更复杂。配置时需要关注以下几个参数：

监控指标：常见的有CPU使用率、内存使用率、负载均衡连接数等。实验中通常用CPU使用率，因为最容易模拟。

统计周期：指标的统计时长，比如“5分钟内平均CPU使用率”。周期太短容易受瞬时波动影响，太长则反应迟钝。一般设300秒比较稳妥。

阈值：触发伸缩的临界值。比如“CPU平均使用率 > 70%”触发扩容，“< 30%”触发缩容。

伸缩动作：增加或减少多少台实例。可以设固定数量（如+2台），也可以设百分比（如+20%）。

冷却时间：与伸缩组的冷却时间配合使用。如果伸缩组冷却时间是300秒，伸缩规则里也可以单独设置，取两者中较大的值。

配置完成后，需要验证规则是否生效。在实验环境中，可以通过在实例上运行压力测试工具来模拟高CPU负载：

# 安装压力测试工具 yum install -y stress # 模拟CPU高负载，持续600秒 stress --cpu 4 --timeout 600

运行后，观察监控图表中的CPU曲线是否上升，以及伸缩组是否在几分钟后自动扩容。扩容完成后，检查新实例是否自动加入SLB并开始分担流量。

4.3 伸缩活动的查看与解读

每次伸缩活动都会在“伸缩活动记录”中留下日志。日志内容包括：触发原因（定时规则还是动态规则）、执行动作（扩容还是缩容）、影响的实例列表、执行结果（成功或失败）。

如果执行失败，常见原因有：

• 伸缩配置中的镜像不存在或已删除
• 安全组规则不允许新实例加入SLB
• 账户余额不足或配额已满
• 交换机下的IP地址不够用

排查时，先看错误信息，再逐项检查对应的资源状态。

5. 常见问题与排查技巧实录

5.1 扩容出来的实例无法加入SLB

这是最常见的问题之一。排查思路如下：

1. 检查安全组：SLB的健康检查请求需要能到达实例的Web端口。确认安全组的入方向规则允许SLB所在网段的访问。
2. 检查Web服务：登录到新实例，用curl localhost:80确认Web服务正常响应。
3. 检查SLB后端组：确认伸缩配置中正确关联了SLB的后端服务器组，且后端组的健康检查配置正确。
4. 检查实例状态：如果实例还在“启动中”，需要等待其完全启动后再观察。

5.2 伸缩规则不触发

如果配置了动态伸缩规则但一直不触发，可能的原因有：

• 监控数据不足：新创建的实例可能还没有上报监控数据，需要等待几分钟。
• 统计周期未满足：比如设置了“连续3个周期超过阈值”，但只满足了2个周期。
• 冷却时间未过：上一次伸缩活动后还在冷却期内。
• 阈值设置不合理：比如CPU阈值设了90%，但实际负载只到80%。

排查时，先看监控图表确认指标是否真的达到了阈值，再看伸缩活动记录确认是否有触发但被冷却时间拦截。

5.3 缩容时误删了关键实例

如果伸缩组中有一些实例承载了特殊角色（比如作为配置中心、数据库从库），缩容时不应该被移除。解决办法是开启“实例保护”功能，对关键实例设置保护状态，伸缩组在缩容时会跳过这些实例。

5.4 常见问题速查表

实操心得：在正式环境中，建议先用手动伸缩验证伸缩配置和SLB的配合是否正常，再启用自动伸缩规则。这样可以避免自动规则触发后才发现配置有问题，导致服务中断。

6. 弹性伸缩的成本与架构优化思考

6.1 成本控制的关键点

弹性伸缩的核心价值之一是成本优化，但如果配置不当，反而可能增加成本。几个关键点：

• 合理设置最大实例数：防止因监控异常或规则配置错误导致无限扩容。
• 缩容规则要配套：只配扩容不配缩容，实例数量只增不减，成本自然下不来。
• 选择合适的实例规格：伸缩组内的实例规格可以多样化，比如用抢占式实例来降低成本，但要注意抢占式实例可能被回收，适合无状态服务。
• 利用定时伸缩：对于可预测的流量模式，定时伸缩比动态伸缩更精准，避免过度扩容。

6.2 与容器服务的配合

弹性伸缩不仅适用于ECS实例，也可以与容器服务配合使用。在容器场景下，弹性伸缩的粒度更细，可以基于Pod的CPU、内存指标自动调整Pod数量。这种模式下，底层节点的伸缩由容器服务自动管理，用户只需要关注Pod层面的伸缩规则。

6.3 多可用区部署的高可用考虑

创建伸缩组时，可以选择多个可用区的交换机。这样扩容时，实例会分散到不同可用区，即使某个可用区出现故障，其他可用区的实例仍然可以提供服务。SLB也会自动将流量分发到健康的实例上。

这种多可用区部署是高可用架构的基础，建议在生产环境中始终启用。实验中如果只提供了一个可用区，可以了解这个机制，在实际项目中应用。

6.4 监控与告警的配合

弹性伸缩虽然能自动调整资源，但并不意味着可以完全放手不管。建议配置以下告警：

• 伸缩组实例数达到最大值时告警，说明可能需要调整上限或优化应用性能。
• 伸缩活动频繁触发时告警，说明冷却时间或阈值设置可能不合理。
• 扩容失败时告警，及时排查资源或配置问题。

这些告警可以帮助你及时发现弹性伸缩策略中的问题，避免服务受到影响。

7. 从实验到生产的经验迁移

在线实验的环境是简化的，生产环境要复杂得多。把实验中学到的知识迁移到生产时，有几个地方需要特别注意。

首先是镜像管理。实验中可能只用一个镜像，但生产环境中应用会不断更新，每次更新都需要制作新镜像并更新伸缩配置。建议建立自动化的镜像构建流程，把应用部署、配置、测试都纳入流水线，减少人工操作。

其次是伸缩规则的调优。实验中的负载是模拟的，生产中的流量模式需要观察一段时间才能摸清。建议先以“观察模式”运行一段时间，只记录不执行，分析监控数据后再设置合理的阈值和冷却时间。

最后是与其他服务的联动。弹性伸缩不是孤立的，它需要和负载均衡、监控、日志、CI/CD等系统配合。比如，新扩容的实例需要自动注册到监控系统，日志需要自动采集，这些都需要在伸缩配置中提前考虑。

我个人在实际操作中的体会是，弹性伸缩的配置本身不难，难的是对业务负载的理解和对参数的持续调优。实验能帮你快速上手，但真正的经验还是要在实际项目中积累。建议每次调整伸缩规则后，都观察一段时间的效果，记录下触发次数、扩容数量、成本变化，慢慢就能找到最适合自己业务的配置。