流量突然上升时，扩容太慢会让请求排队，阈值设得太敏感又可能反复增加和回收实例。制定海外主机突发流量下的自动扩容触发条件，应先确定哪些指标代表真实容量不足，再为缩容设置独立门槛。以下五项可作为校准起点，具体数值要结合压测、应用类型和所在区域调整。
先把五项扩容信号设清楚
1. 单实例请求量
不要只看整个站点的总请求数，应计算每台实例承担的请求量，并与压测时稳定处理的吞吐能力比较。可先在单实例达到已验证安全吞吐量的约60%至75%时触发扩容；如果请求成本差异很大，例如部分请求需要复杂计算，就应按接口或任务类型分别评估。
2. 关键请求的响应延迟
监控 p95 延迟，即95%的请求不超过的响应时间，并对照业务设定的服务目标。比如目标为500毫秒，可将约400毫秒作为观察起点，连续数个采集周期超出再扩容。不要用单次尖峰触发，以免网络抖动造成不必要的实例变动。
3. 队列长度与等待时间
对异步任务或后台工作进程，积压任务数比网页请求量更能反映压力。优先监控最老任务的等待时间，并估算当前处理能力需要多久才能清空队列；当等待时间持续逼近任务时限时扩容。若任务无法并行处理，单纯增加实例不一定能解决问题。
4. 内存压力
可把可用内存持续低于约15%至25%作为告警或扩容观察线，持续时间通常设为数分钟，再结合实例重启、交换空间和延迟判断。该范围只是常见校准起点：有些程序会主动占用空闲内存，不能仅凭内存使用率判断容量不足。
5. 错误率或连接饱和
错误率升高可作为辅助信号，但要先排除依赖服务故障、配置错误和单一接口异常。若连接池或并发连接接近上限，并同时出现延迟上升，扩容可能有效；若所有实例都报相同错误，应先处理故障，避免自动扩容放大资源消耗。
把阈值变成可执行规则
配置海外主机突发流量下的自动扩容触发条件时，按以下顺序操作，避免直接照搬其他主机的固定数值：
- 按区域、实例规格和应用版本分组采集指标，确认监控数据能区分实例，而不是只有全站汇总。
- 在预发布环境或可控压测中逐步增加并发，记录延迟开始恶化、队列持续增长或资源逼近上限时的单实例负载。
- 把触发线设在恶化点之前，并要求指标连续满足一段观察窗口；分钟级采集时，可从连续2至5分钟开始验证，具体取决于流量变化速度。
- 记录实例启动和应用就绪所需时间。若预热需要数分钟，触发信号就要留出相应提前量，并设置扩容冷却时间，避免启动期间重复下单。
- 先验证扩容后指标是否改善，再调整阈值；同时设置实例上限、预算告警和扩容失败告警。
回收条件不能照抄扩容条件
缩容应使用更低的回收线，形成滞回区间。例如扩容依据是负载超过安全值的一定比例，回收则可要求负载连续较长时间降到较低水平；两者之间留出明显间隔，避免流量在边界附近波动时反复扩缩。回收观察期通常应长于扩容观察期，常见起点可设为10至30分钟，再按业务的日常波动调整。
真正回收前，还要确认队列没有积压、延迟与错误率稳定，并让实例先停止接收新任务、完成连接排空。对有长连接、定时任务或本地状态的服务，应设置优雅退出流程；无法安全迁移任务时，不应仅因短时负载下降而缩容。跨境访问的监控也应按区域查看，避免一个区域的低负载掩盖另一区域的拥塞。
常见问题
流量上升就应该立即扩容吗？
不一定。先确认请求量、延迟或队列确实显示容量不足，并排除依赖故障和异常请求。
可以只用一个指标触发吗？
可以，但要了解其盲点。更稳妥的做法是以一个主指标触发、用延迟或错误率作保护判断。
扩容后何时允许缩容？
达到较低回收线并稳定一段时间后，再确认队列、连接和错误情况，最后执行排空。
阈值多久复核一次？
实例规格、代码或流量形态发生变化后应重新验证；日常可结合监控记录定期复核压测得到的安全容量。
归根结底，海外主机突发流量下的自动扩容触发条件要同时回答“何时增加容量”和“何时安全回收”。用实测容量校准五项信号，再为预热、观察窗口与连接排空留出保护，才能减少误扩容和过早缩容。
