健康情況探查
重要
Azure Front Door（傳統版）將於 2027 年 3 月 31 日淘汰。 為了避免任何服務中斷，請務必在 2027 年 3 月之前將 Azure Front Door （傳統） 配置檔移轉至 Azure Front Door Standard 或 進階版 層。 如需詳細資訊，請參閱 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 就會繼續正常負載平衡演算法。
停用健全狀態探查
如果原點群組中有單一原點，您可以選擇停用健全狀態探查，以減少應用程式的負載。 如果原點群組中有多個原點，且有一個以上的原點處於啟用狀態，您無法停用健全狀態探查。
下一步
- 了解如何建立 Azure Front Door 設定檔。
- 了解 Front Door 路由傳送結構。