问题描述

在 Azure App Service 中启用 Automatic Scaling 后，当业务负载增加并触发横向扩展时，平台可能需要动态增加新的 App Service 实例。

对于生产环境，一个非常重要的问题是：

如何确保新扩展出来的实例已经完成应用启动、依赖初始化并处于健康状态后，再开始承载实际业务流量，从而降低扩容过程对业务稳定性的影响？

解决这个问题不能只关注扩容规则本身，还需要从应用架构、应用初始化、实例健康检查以及预热能力几个方面共同考虑。

问题解答

在应用架构方面，建议采用无状态设计，将 Session 等状态保存在 Redis、数据库等共享存储中，而不是依赖单个实例的内存。

启用 Automatic Scaling 时，同一 App Service Plan 中已有应用的 ARR Affinity 会自动关闭，因此需要确保请求切换实例后仍能正常处理。

除了应用架构，另外三个方面分别解决不同的问题：

1. Application Initialization：提前初始化应用，完成预热。
2. Health Check：检查实例健康状态。
3. Prewarmed Instance：提供扩容时的预热容量缓冲。

本文重点介绍 Health Check。应用初始化已在第一部分介绍，预热实例将在第三部分介绍。

实例健康检查（Health Check）

新实例完成启动后，应用和必要依赖不一定已经具备处理业务请求的能力。

配置 Health Check 后，App Service 在扩容时会探测指定路径，以检查新实例是否就绪。

例如，应用可以提供 `/ready`：初始化完成且关键依赖可用时返回 200，否则返回 503。 接口应轻量、无副作用，并设置合理的依赖检查超时。

如何配置和验证

在 Azure Portal 中进入应用的 **Monitoring > Health check**，启用 Health Check，填写 `/ready` 并保存。

注意，修改 Health Check 配置会触发应用重启。

• 平台每分钟探测一次，返回 200–299 表示健康。
• 对于运行中的实例，默认连续失败 10 次后才判为不健康。该次数可通过 `WEBSITE_HEALTHCHECK_MAXPINGFAILURES` 调整为 2–10 次。
• Health Check 不保证所有不健康实例都被摘除。默认最多摘除一半活跃实例，所有实例不健康或只有一个活跃实例时，不会全部摘除。
• 生产环境应保留至少两个活跃实例，并确保 Plan 容量足够。
• 测试时可模拟依赖故障，观察健康状态和业务请求。
• 探测路径应避免重定向，使用自定义认证时，需允许探测访问，并按官方文档限制访问或验证平台请求。

参考资料

App Service Health Check : https://learn.microsoft.com/azure/app-service/monitor-instances-health-check

App Service Automatic Scaling : https://learn.microsoft.com/azure/app-service/manage-automatic-scaling

当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!