Note
本文中的 源 和 源组 是指 Azure Front Door 配置的后端和后端池。
为了确定给定 Azure Front Door 环境中每个源的运行状况和邻近，每种 Front Door 配置文件将定期向你配置的所有源发送综合 HTTP/HTTPS 请求。 然后，Front Door 使用运行状况探测的响应来确定将客户端请求路由到最佳源。
Warning
由于每个 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 方法与 GET 相同，不同之处在于服务器 不得 在响应中返回消息正文。 对于新的 Front Door 配置文件，默认的探测方法设置为 HEAD。
Tip
为了降低源的负载和成本，Front Door 建议将 HEAD 请求用于运行状况探测。
运行状况探测响应
| Responses | Description |
|---|---|
| 确定健康状况 | 200 正常状态代码指示源正常。 任何其他状态代码都视为失败。 如果出于任何原因，探测未接收到有效的 HTTP 响应，则该探测被视为失败。 |
| 测量延迟 | 延迟是指从发送探测请求前的那一刻到 Front Door 收到响应的最后一个字节的那一刻所测得的时钟时间。 Front Door 为每个请求使用新的 TCP 连接。 策略不偏向于具有现有暖连接的源。 |
Front Door 如何确定源运行状况
Azure Front Door 在所有算法中均使用三步过程来确定运行状况。
排除禁用的源。
排除具有运行状况探测错误的源：
通过查看最后 n 个运行状况探测响应来完成此选择。 如果至少 x 正常，则原点被视为正常。
通过 更改负载均衡设置中的 SampleSize 属性来配置 n。
通过 更改负载均衡设置中的 SuccessfulSamplesRequired 属性来配置 x。
对于源组中的正常源集，Front Door 会测量每个源的延迟并继续保持该延迟。
Note
如果某个单一终结点属于多个源组，Front Door 会优化发送到源的运行状况探测的数量，以减少源的负载。 将根据配置的最小采样间隔发送运行状况探测请求。 来自相同运行状况探测的响应确定所有源组中终结点的运行状况。
完成运行状况探测失败
如果源组中每个源的运行状况探测均失败，则 Front Door 会将所有源视为运行不正常，并将跨所有源在轮循机制分配中路由流量。
一旦源返回到正常运行状态，Front Door 即恢复正常负载平衡算法。
禁用运行状况探测
如果源组中只有一个源，则可以选择禁用运行状况探测，以减少应用程序上的负载。 如果源组中有多个源，并且不止一个源处于启用状态，则无法禁用运行状况探测。
Note
如果源组中只有一个源，则该源将获得很少的运行状况探测。 这可能会导致源运行状况指标下降，但流量不会受到影响。