引言：Serverless时代的弹性之舞
在云原生架构席卷一切的今天，应用的弹性能力早已不再是锦上添花的功能，而是决定系统生死存亡的核心竞争力。传统自建Kubernetes集群中，运维团队需要手动配置Horizontal Pod Autoscaler（HPA）、设置监控指标、调整副本数，这一系列操作不仅繁琐，更难以应对突发流量的瞬时冲击。阿里云Serverless应用引擎SAE的出现，彻底改变了这一局面。
SAE将底层Kubernetes集群的复杂性完全屏蔽，以白屏化操作和秒级弹性响应的方式，让开发者能够像使用水电一样按需使用计算资源。根据实际业务场景，小熊油耗在使用SAE后成本节约超过60%，资源利用率从不足20%提升至50%以上。这些数字背后，正是SAE弹性扩缩容能力的价值体现。
本文将从最基础的手动扩缩开始，逐步深入到定时弹性、监控指标弹性、混合弹性三大自动策略，再到高级参数调优、Prometheus自定义指标扩展、基础设施即代码等进阶话题，为你呈现一份完整的SAE弹性扩缩容知识图谱。
第一部分：弹性扩缩容的基础认知
1.1 什么是应用扩缩容
应用扩缩容，本质上是通过改变应用的实例数来增加或减少应用的计算容量。当业务流量攀升时，增加实例数量可以分担负载、保障响应速度；当流量回落后，减少实例数量则可以避免资源闲置、控制成本。SAE的扩缩容支持手动和自动两种方式。
手动扩缩适用于紧急需求的场景——比如突发性的流量高峰，运维人员需要立即介入，快速调整实例数量。而自动扩缩则适用于周期性或可预测的流量变化，通过预先配置的弹性策略，让系统自动完成实例的增减。
1.2 SAE弹性扩缩容的核心优势
SAE的弹性伸缩能力具备三大核心优势：高可靠性、免运维、低成本。高可靠性体现在秒级的弹性响应速度上——当流量波峰到来的瞬间，SAE能够在几秒内完成实例的扩容，确保业务不中断。免运维则意味着开发者无需关心底层Kubernetes集群的HPA配置、节点资源等问题，SAE平台自动接管这一切。低成本更是Serverless架构的天然属性——按实际使用量计费，不为闲置资源付费。
需要先登录阿里云控制台，点击：阿里云控制台
第二部分：手动扩缩——应急响应的第一道防线
2.1 何时使用手动扩缩
尽管自动弹性是SAE的主打能力，但手动扩缩依然有其不可替代的价值。当遇到以下场景时，手动扩缩是最直接有效的应对手段：突发性流量高峰且自动弹性策略尚未就绪、运维人员需要精确控制实例数量进行灰度验证、或者自动弹性策略因某些原因被临时停用。
2.2 手动扩缩的操作流程
在SAE控制台中执行手动扩缩的步骤非常直观。首先在SAE应用列表中，选择目标地域和命名空间，点击目标应用ID跳转到应用详情页。在基础信息页面中，找到并单击“手动扩缩”按钮。在弹出的对话框中，通过滑动指针设置应用的目标实例数，点击确定即可完成操作。
需要注意的是，如果应用已经部署并开启了弹性伸缩策略，手动扩缩后还需要选择“恢复自动弹性方式”。系统自动恢复模式下，定时弹性将在当前周期内的下一个时间窗口生效；监控指标弹性策略和混合弹性策略在手动扩缩后会立即自动生效。如果选择“人工启用恢复”，则需要后续手动将弹性策略重新设置为启用状态。
2.3 手动扩缩的使用限制与注意事项
扩容时，如果扩容后的实例总数超过了应用的资源使用限制，则扩容操作会失败。SAE单应用的实例数上限默认为50个，如果需要更多实例，需要加入钉群（钉群号：32874633）申请开通白名单。此外，应用扩缩容过程中可能会造成业务中断，建议在操作前为应用配置无损上下线能力。
第三部分：自动弹性三大策略详解
SAE的自动弹性伸缩策略分为三种类型：定时弹性策略、监控指标弹性策略和混合弹性策略。这三种策略各有侧重，适用于不同的业务场景。
3.1 定时弹性策略——可预测的周期性负载
定时弹性策略适用于资源使用率具有明显周期性规律的应用场景。典型的例子包括：证券交易系统在开盘和收盘时段会有流量高峰、医疗系统在工作日白天访问量较大、教育行业的选课系统在特定时间段有集中访问。
在配置定时策略时，需要指定策略的生效时间范围（长期或短期）、周期（每天、每周或每月），以及具体的触发时间和触发后保持的实例数。例如，可以配置每天早上8点将实例数扩容到10个，晚上8点缩容到3个。SAE最多支持创建5条定时策略。
3.2 监控指标弹性策略——实时响应的智能伸缩
监控指标弹性策略是SAE最核心的自动弹性能力。它通过实时监控应用的各类指标，当指标达到预设阈值时自动触发扩缩容。SAE支持的监控指标非常丰富，涵盖了基础设施层面和应用业务层面：
- 基础监控指标：CPU使用率、内存使用率
- 网络指标：TCP活跃连接数、TCP总连接数
- 应用性能指标：应用QPS（每秒查询数）、应用响应时间（RT）
- 负载均衡指标：公网CLB QPS、公网CLB响应时间、私网CLB QPS、私网CLB响应时间
配置监控指标策略时，需要设置指标的目标值。例如，当CPU使用率超过70%时触发扩容，当CPU使用率回落到70%以下时触发缩容。可以同时设置多个指标类型，SAE会综合判断是否触发弹性操作。
在实例数设置方面，需要配置三个关键参数：应用最小实例数、应用最大实例数和最小存活实例数。最小实例数保证了即使在无流量时也有基本的服务能力；最大实例数则限制了扩容的上限，避免资源失控。
3.3 混合弹性策略——双剑合璧的终极方案
混合弹性策略是SAE业界首创的弹性策略类型，它融合了定时弹性和监控指标弹性的优势。这种策略适用于那些既有潮汐特性又可能伴随流量突发的业务场景。以视频直播为例，直播活动通常在固定时间段开始，但观看人数的突发增长却难以精确预测。混合弹性策略可以先通过定时弹性在直播开始前预置一批实例，再通过监控指标弹性应对直播过程中的突发流量。
混合弹性策略通过一条策略就能实现不同时间段内定时弹性或监控指标弹性的精细化弹性需求。值得注意的是，SAE最多支持创建5条定时策略、1条监控指标策略或1条混合弹性策略，三种策略不能同时使用。
第四部分：高级参数调优——从能用到底好用
对于监控指标策略和混合弹性策略，SAE提供了五个高级参数，合理配置这些参数可以让弹性行为更加平滑和可控。
4.1 弹性扩容步长与弹性缩容步长
弹性扩容步长表示单位时间内最多扩容的实例数。如果没有配置步长，HPA控制器在检测到需要扩容时，可能会一次性将实例数从1直接扩容到最大值，这种“暴力”扩容方式虽然响应迅速，但可能对下游系统造成瞬时压力。通过配置步长，可以控制扩容的节奏，例如设置步长为1，则每次最多只扩容1个实例，实现更平滑的扩容过程。
弹性缩容步长的逻辑与扩容步长类似，控制的是单位时间内最多缩容的实例数。在生产环境中，适当限制缩容步长可以避免因流量瞬时波动导致的频繁缩容扩容，即所谓的“抖动”现象。
4.2 扩容稳定窗口与缩容稳定窗口
扩容稳定窗口通过自动扩缩算法来保证当需要执行扩容时，使用指定时间间隔内所计算的期望目标实例数中的最小值。简单来说，稳定窗口可以防止因为指标的瞬时抖动而触发不必要的扩容。缩容稳定窗口则相反，它使用指定时间间隔内所计算的期望目标实例数中的最大值，防止过早缩容。
4.3 禁止缩容——关键时期的保护伞
禁止缩容参数开启后，将永远不会缩容该应用的实例。这个功能在流量高峰期尤为有用——例如电商大促期间，即使某些监控指标暂时回落，也不希望系统自动缩容，以免在下一个流量波峰到来时来不及扩容。
4.4 高级参数实战验证
根据阿里云官方的最佳实践文档，通过PTS压测工具可以直观地验证高级参数的效果。在不配置弹性扩容步长的情况下，当QPS指标超过目标值时，HPA控制器会一次性将实例扩容到最大值。而配置步长为1后，实例会按照步长逐步扩容，过程更加平滑可控。这一差异在对接下游数据库、缓存等有状态服务时尤为关键——平滑扩容可以避免瞬间连接数暴涨导致的服务雪崩。
第五部分：深入Kubernetes HPA——理解SAE弹性的底层逻辑
5.1 SAE弹性策略与HPA的映射关系
SAE应用的弹性规则实际上对应于Kubernetes的HorizontalPodAutoscaler资源类型。这意味着，如果你熟悉Kubernetes HPA的配置方式，可以很自然地理解SAE的弹性策略。
SAE的弹性策略底层使用Kubernetes HPA的autoscaling/v2 API版本。在通过saectl工具管理弹性规则时，可以直接编写标准的HPA YAML配置文件。
5.2 使用saectl工具管理弹性规则
saectl是SAE官方提供的命令行工具，支持创建、查看、更新和删除弹性规则。以下是一个完整的HPA YAML配置示例：
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: annotations: sae.aliyun.com/alias: test-app sae.aliyun.com/enabled: "true" name: metric-test-app namespace: default spec: behavior: scaleDown: policies: - periodSeconds: 15 type: Pods value: 10 stabilizationWindowSeconds: 200 scaleUp: policies: - periodSeconds: 15 type: Pods value: 5 stabilizationWindowSeconds: 100 maxReplicas: 8 metrics: - resource: name: cpu target: averageUtilization: 80 type: Utilization type: Resource - resource: name: memory target: averageUtilization: 80 type: Utilization type: Resource - pods: metric: name: tcpActiveConn target: averageValue: "100" type: AverageValue type: Pods minReplicas: 1 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: test-app
在这个配置中，spec.behavior部分定义了扩容和缩容的具体行为策略。scaleUp.policies中的periodSeconds表示评估周期，value表示步长，stabilizationWindowSeconds表示稳定窗口时长。metrics部分则定义了多个监控指标——CPU使用率、内存使用率、TCP活跃连接数。
创建弹性规则的命令非常简单：
saectl apply -f hpa.yaml
查看弹性规则列表可以使用：
saectl get hpa -l sae.aliyun.com/app-name=${deployment-name} -n ${namespace}
查看弹性规则详情则可以使用：
saectl get hpa ${hpa-name} -o yaml -n ${namespace}
第六部分：基于Prometheus的弹性扩展——自定义指标的力量
除了SAE内置的监控指标外，对于标准版和专业版的SAE应用，还可以基于可观测监控Prometheus版采集的自定义监控指标来触发自动弹性伸缩。
这一能力使得弹性策略可以更加贴近业务语义。例如，一个电商应用可以基于“订单创建速率”这个业务指标来触发扩容，而不仅仅是依赖CPU或内存等基础设施指标。配置方式与内置指标类似，在弹性策略的触发条件中选择Prometheus指标类型，并指定相应的指标名称和目标值。
需要注意的是，基于Prometheus监控指标的弹性伸缩仅适用于SAE应用的标准版和专业版。在使用前，需要先将SAE应用接入Prometheus监控，确保自定义监控指标能够在Prometheus中正常采集。
第七部分：基础设施即代码——Terraform管理弹性策略
对于追求自动化运维和GitOps实践的团队，SAE提供了完整的Terraform支持。通过Terraform，可以将弹性策略的配置以代码的形式管理，实现版本控制、审计和自动化部署。
SAE的Terraform资源类型为alicloud_sae_application_scaling_rule。在创建应用时，可以通过配置这个资源来启用弹性策略。支持的策略类型同样包括定时弹性（timing）、监控指标弹性（metric）和混合弹性（mix）。
以下是Terraform配置弹性策略的核心属性：
- AppId：应用ID
- ScalingRuleName：弹性策略名称，应用内唯一，以小写字母开头，仅包含小写字母、数字和短划线，不超过32个字符
- ScalingRuleType：策略类型，取值为timing、metric或mix
- MinReadyInstances：最小存活实例数
- MinReadyInstanceRatio：最小存活实例数百分比
- ScalingRuleMetric：监控指标弹性策略配置
- ScalingRuleTimer：定时弹性策略配置
通过Terraform管理弹性策略，可以实现弹性配置的声明式管理和跨环境的一致性部署，是生产级SAE运维的推荐方式。
第八部分：弹性可观测性——让每一次伸缩都看得见
配置弹性策略只是第一步，更重要的是能够监控和评估弹性策略的实际效果。SAE提供了完善的弹性可观测能力。
在SAE控制台的应用详情页中，单击“弹性伸缩”页签，可以看到“实例数随弹性指标变化趋势”的可视化图表。这个图表展示了在指定时间范围内，实例数如何随监控指标的变化而动态调整。
图表中包含了六个关键参数：
- CPU使用率：CPU资源被占用的程度
- 应用实例数：当前部署的实例数量
- 扩容区间：当指标超过预设阈值时可以增加的最大实例数量
- 缩容区间：当指标下降到预设阈值时允许减少的最大实例数量
- 目标值：HPA设置的扩缩容阈值
- 弹性事件：实例数变动的具体原因说明
通过这些可视化数据，运维人员可以快速评估弹性策略是否合理——是否存在频繁的扩缩容抖动、扩容是否及时、缩容是否过于激进等。这些洞察是持续优化弹性策略的重要依据。
第九部分：生产环境最佳实践
9.1 准备工作：打好弹性伸缩的地基
在配置弹性策略之前，有几项准备工作至关重要：
- 配置应用健康检查：确保应用在弹性伸缩过程中的整体可用性，仅在启动、运行且准备完成时才接收流量
- 配置应用生命周期管理：特别是PreStop设置，确保缩容时应用能够优雅下线，避免正在处理的请求被中断
- 采用指数重试机制：避免因弹性不及时或应用启动延迟导致服务调用异常
- 优化应用启动速度：精简镜像大小、优化Java应用启动参数。在SAE上创建应用时选择Dragonwell 11环境可以开启应用加速功能
9.2 指标目标值的权衡艺术
配置监控指标的目标值需要在可用性和成本之间找到平衡点：
- 可用性优先策略：将指标目标值配置为40%，系统会更早触发扩容，保障更高的可用性，但成本也相对较高
- 成本优先策略：将指标目标值配置为70%，系统会更晚触发扩容，资源利用率更高，但可用性风险也更大
- 平衡策略：将指标目标值配置为50%，在可用性和成本之间取得平衡
建议在配置前查看基础监控和应用监控对应指标的历史数据（例如过去6小时、12小时、1天或7天的峰值、P95或P99数值），并借助PTS等压测工具进行压测，了解应用的真实容量峰值。
9.3 最小实例数的安全考量
建议将应用的最小实例数配置为大于等于2，并配置多可用区的vSwitch。这样可以避免因底层节点异常导致实例被驱逐，或某个可用区无可用实例时应用停止工作。
9.4 弹性策略与变更操作的冲突处理
一个重要的注意事项：弹性策略启用时，请勿手动执行应用生命周期管理操作，例如应用扩缩容、部署应用、更改规格、重启应用或停止应用。如果确实需要进行这些操作，需要先停用弹性策略，完成操作后再重新启用。在部署应用时，SAE会停止当前应用的弹性伸缩配置以避免操作冲突，如果希望在变更完成后自动恢复弹性配置，可以在部署页面选择“系统自动恢复”。
第十部分：场景化实战案例
10.1 电商大促场景
电商大促是弹性伸缩最典型的应用场景。在大促前，可以通过定时弹性策略预置一批实例；在大促进行中，通过监控指标弹性策略实时应对流量波动；大促结束后，自动缩容释放资源。整个过程中，SAE的秒级弹性能力确保系统平稳应对流量洪峰。
10.2 视频直播场景
视频直播兼具潮汐特性和突发流量的特点。直播开始前有可预测的流量增长，直播过程中可能有突发的观看人数暴涨。混合弹性策略在这种场景下大显身手——定时弹性在直播开始前预置实例，监控指标弹性在直播过程中兜底应对突发。
10.3 开发测试环境
在开发测试环境中，流量通常集中在工作时间，夜间和周末几乎无人访问。通过配置定时弹性策略，可以在工作时间保持适量实例，非工作时间缩容到最小实例数甚至缩容到0，大幅降低资源成本。
结语
阿里云SAE的弹性扩缩容体系，从手动应急到智能自动化，从基础指标到自定义Prometheus指标，从控制台白屏化操作到Terraform基础设施即代码，为开发者提供了一整套完整、灵活、高效的弹性解决方案。掌握这些能力，意味着你可以在保障应用稳定性的同时，实现资源利用的最大化和成本的最优化。在Serverless时代，弹性不是一种选择，而是一种必备的能力——而SAE，正是让你轻松获得这种能力的最佳伙伴。
常见问题解答
问1：SAE的三种自动弹性策略可以同时使用吗？
不可以。SAE最多支持创建5条定时策略、1条监控指标策略或1条混合弹性策略，三种策略不能同时使用。你需要根据业务场景选择最适合的一种策略类型。
问2：弹性策略启用时，我可以手动调整实例数吗？
可以，但需要注意方式。如果弹性策略已启用，手动扩缩后需要选择“恢复自动弹性方式”——系统自动恢复或人工启用恢复。如果选择人工启用恢复，需要后续手动将弹性策略重新设置为启用状态。
问3：SAE单应用最多支持多少个实例？
SAE单应用的实例数上限默认为50个。如果需要更多实例，可以加入钉群（钉群号：32874633）申请开通白名单。
问4：如何防止在流量高峰期系统自动缩容？
可以在弹性策略的高级参数中开启“禁止缩容”功能。开启后，系统将永远不会缩容该应用的实例，有效防止在流量高峰期因缩容造成的业务风险。
问5：SAE的弹性策略与Kubernetes HPA是什么关系？
SAE应用的弹性规则实际上对应于Kubernetes的HorizontalPodAutoscaler资源类型。SAE底层使用Kubernetes HPA的autoscaling/v2 API来执行弹性操作。如果你熟悉Kubernetes HPA，可以通过saectl工具直接编写标准的HPA YAML文件来管理SAE的弹性规则。
问6：如何评估我配置的弹性策略是否合理？
可以通过SAE控制台中的“弹性可观测”功能来评估。在应用详情页的“弹性伸缩”页签中，可以查看“实例数随弹性指标变化趋势”图表。通过观察实例数、监控指标、扩容区间、缩容区间等参数的变化趋势，可以判断弹性策略是否过于激进或过于保守。
