你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
运行状况探测
重要
Azure Front Door（经典版）将于 2027 年 3 月 31 日停用。 为了避免任何服务中断，请务必在 2027 年 3 月之前将 Azure Front Door（经典版）配置文件迁移到 Azure Front Door 标准层或高级层。 有关详细信息，请参阅 Azure Front Door（经典版）停用。
注意
本文中的“源”和“源组”指的是 Azure Front Door（经典版）配置的后端和后端池。
为了确定给定 Azure Front Door 环境中每个源的运行状况和邻近，每种 Front Door 配置文件将定期向你配置的所有源发送综合 HTTP/HTTPS 请求。 然后，Front Door 会根据运行状况探测的响应来确定用于路由客户端请求的“最佳”源。
警告
由于每个 Azure Front Door 边缘位置都会向你的源发出运行状况探测，因此，源的运行状况探测量可能非常高。 探测数取决于客户的流量位置和运行状况探测频率。 如果 Azure Front Door 边缘位置没有收到来自最终用户的真实流量，则边缘位置运行状况探测频率会比配置频率低。 如果向所有 Azure Front Door 边缘位置发送流量，则运行状况探测量可能会很高，具体取决于运行状况探测频率。
例如，使用 30 秒默认探测频率时，粗略估计每分钟源的运行状况探测量。 每个源的探测量等于边缘位置数乘以每分钟两个请求。 如果没有任何流量发送到所有边缘位置，则探测请求数会变少。 有关边缘位置的列表，请参阅按区域排序的边缘位置。
支持的协议
Azure Front Door 支持通过 HTTP 或 HTTPS 协议发送探测。 这些探测通过为路由客户端请求配置的同一 TCP 端口发送，且不能重写。 Front Door HTTP/HTTPS 探测在发送时带 User-Agent 标头，其值设置为 Edge Health Probe。
受支持的运行状况探测 HTTP 方法
Azure Front Door 支持使用以下 HTTP 方法发送运行状况探测：
- GET：GET 方法表示检索由请求 URI 标识的所有信息（以实体形式）。
- HEAD：在 HEAD 方法中，除了服务器不得在响应中返回消息正文，其他都与 GET 方法相同。 对于新的 Front Door 配置文件，默认的探测方法设置为 HEAD。
提示
为了降低源的负载和成本，Front Door 建议将 HEAD 请求用于运行状况探测。
运行状况探测响应
| 响应 | 说明 |
|---|---|
| 确定运行状况 | 200 OK 状态代码指示源运行状况良好。 任何其他状态代码都视为失败。 如果出于任何原因，探测未接收到有效的 HTTP 响应，则该探测被视为失败。 |
| 测量延迟 | 延迟是指从发送探测请求前的那一刻到 Front Door 收到响应的最后一个字节的那一刻所测得的时钟时间。 Front Door 为每个请求使用新的 TCP 连接。 策略不偏向于具有现有暖连接的源。 |
Front Door 如何确定源运行状况
Azure Front Door 在所有算法中均使用三步过程来确定运行状况。
排除禁用的源。
排除具有运行状况探测错误的源：
此选择是通过查看最后 n 个运行状况探测响应来完成的。 如果至少有 x 个运行状况良好，则源将被视为运行状况良好。
通过更改负载平衡设置中的 SampleSize 属性，配置 n。
通过更改负载平衡设置中的 SuccessfulSamplesRequired 属性，配置 x。
对于源组中的正常源集，Front Door 会测量每个源的延迟并继续保持该延迟。
注意
如果某个单一终结点属于多个源组，Front Door 会优化发送到源的运行状况探测的数量，以减少源的负载。 将根据配置的最小采样间隔发送运行状况探测请求。 所有源组中终结点的运行状况将由来自相同运行状况探测的响应确定。
完成运行状况探测失败
如果源组中每个源的运行状况探测均失败，则 Front Door 会将所有源视为运行不正常，并将跨所有源在轮循机制分配中路由流量。
一旦源返回到正常运行状态，Front Door 即恢复正常负载平衡算法。
禁用运行状况探测
如果源组中只有一个源，则可以选择禁用运行状况探测，以减少应用程序上的负载。 如果源组中有多个源，并且不止一个源处于启用状态，则无法禁用运行状况探测。