適用於： ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (傳統)
重要
Azure Front Door（經典版）將於 2027 年 3 月 31 日退休。 由於該服務即將退休，不再支援設定檔建立、新網域導入或管理憑證。 為避免服務中斷，遷移至Azure Front Door標準版或高級版。 如需詳細資訊，請參閱 Azure Front Door (傳統版) 淘汰。
Azure Front Door 支援四種流量路由方法，用於管理 HTTP/HTTPS 流量在不同來源之間的分配方式。 當使用者要求到達 Front Door 邊緣位置時，設定的路由方法可確保要求會轉送至最佳後端資源。
注意
在本文中， Origin 是指後端，而 原始群組 則參考 Azure Front Door （傳統） 組態中的後端集區。
四種流量路由方法如下：
優先事項： 允許你為起始點設定優先順序，指定一個主要起始點處理所有流量，並指定一個次要起始點作為備用，以防主起始點無法使用。
加權： 將權數指派給每個來源，以平均分配流量，或根據指定的權數係數分配流量。 如果來源的延遲位於可接受的範圍內，流量會根據加權值來分配。
會話親和性： 為前端主機或網域設定會話親和性，確保來自相同使用者的要求會傳送至相同的來源。
注意
在 Azure Front Door 標準和進階層中， 端點名稱 稱為 Azure Front Door 中的前端主機 （傳統）。
所有 Front Door 設定均包含後端健康監控和自動化的全球故障轉移功能。 如需詳細資訊，請參閱 Front Door 後端監視。 Azure Front Door 可以使用單一路由方法，或結合多個方法，根據您的應用程式需求建立最佳路由拓撲。
注意
透過使用 Front Door 規則引擎，你可以設定規則，在Azure Front Door標準版和高級版中覆蓋路由配置，或在 Azure Front Door（經典版）中設定規則覆蓋後端池以回應請求。 規則引擎設定的起源群組或後端池會覆蓋本文所述的路由流程。
整體決策流程
下圖說明整體決策流程：
決定步驟如下：
-
可用的來源： 根據健康探測，選取已啟用且運行正常 （200 OK） 的所有來源。
- 範例：如果有六個來源 A、B、C、D、E 和 F，而 C 狀況不良且 E 已停用，可用的來源為 A、B、D 和 F。
-
優先順序： 從可用的來源中選取最高優先順序來源。
- 範例：如果原點 A、B 和 D 的優先順序為 1，而來源 F 的優先順序為 2，則選取的原點為 A、B 和 D。
-
延遲訊號 (以健全狀態探查探查為基礎)：從接收要求的 Front Door 環境中，選取延遲在可接受範圍內的原始來源。 此範圍基於起點組的延遲敏感度設定及最近起點的延遲。
- 範例：如果來源 A 的延遲為 15 毫秒，至 B 為 30 毫秒，而 D 為 60 毫秒，而延遲敏感度設定為 30 毫秒，則選取的來源為 A 和 B，因為 D 超過 30 毫秒的範圍。
-
權數： 根據指定的權數比例，將流量分散到最終選取的來源之間。
- 範例：如果來源 A 的權重為 3，而來源 B 的權重為 7，流量會分配 3/10 給 A，並將 7/10 分配給 B。
如果你啟用會話親和性，會話中的第一個請求會遵循先前解釋的流程。 後續請求會回到第一個請求所選的原點。
基於最低延遲的流量路由
在多個全球地點部署起點，可以透過將流量導向離終端使用者「最近」的源頭，提升應用程式的回應速度。 延遲路由方法是 Azure Front Door 設定的預設值。 此方法會將使用者要求導向到具有最低網路等待時間的來源，而不是最接近的地理位置，以確保最佳效能。
Azure Front Door 採用單播架構，結合延遲路由方法，確保每位使用者根據其位置享有最佳效能。 每個 Front Door 環境都會獨立測量來源的延遲，這表示不同位置的使用者會路由傳送至提供其特定環境最佳效能的來源。
注意
依預設，延遲敏感度屬性會設定為 0 毫秒。 使用此設定時，要求一律會轉送至最快的可用來源。 只有當兩個原點具有相同的網路延遲時，原點的權重才會生效。
如需詳細資訊，請參閱 Azure Front Door 路由架構。
基於優先權的流量路由
為確保高可用性，部署備用服務以在主要服務失效時接手。 此設定稱為作用中/待命或主動/被動部署。 Azure Front Door 中的 Priority流量路由方法可協助你實作此故障轉移模式。
預設情況下，Azure Front Door 會將請求路由到設定優先權最高的健康來源，其中優先權為 1。 如果該優先順序層級沒有可用的來源，Front Door 會將要求路由至下一個優先順序層級中狀況良好的來源。
如果 Azure Front Door 無法建立與所選來源的 TCP 連線，它會根據來源群組的路由設定，嘗試對另一個符合資格的來源重新嘗試請求。 即使健康探查顯示所選來源狀態正常，此重試仍可能發生。
建立連線後，Front Door 只會重試可安全重試的要求，例如冪等要求，而且僅會在回應標頭傳送至用戶端之前進行重試。 如果沒有其他來源符合資格，Front Door 可能會重新嘗試相同的來源。 並非每次請求或失敗都會保證重試。
設定原點優先順序
你Azure Front Door起源群組中的每個原點都有一個Priority屬性，你可以設定為1到5之間的值。 較低的值就代表優先順序較高。 多個來源可以共用相同的優先順序值。
加權流量路由方法
注意
對於 RPS（每秒請求數）非常低的客戶，由於 Azure Front Door 的接入點（POPs）和機器是分散式的，Azure Front Door 無法保證你設定的權重會被嚴格遵守，負載平衡可能會顯得不合理。
加權流量路由方法根據預先定義的權重分配流量。
在此方法中，您會將權數指派給 Azure Front Door 原始群組中的每個原始來源。 權重為1到1,000之間的整數，預設值為 50。
流量透過基於指定權重比的輪轉機制分配至可用起點，前提是起點符合可接受的延遲敏感性。 如果你把延遲靈敏度設為 0 毫秒，權重只有在兩個起點的網路延遲相同時才會生效。
加權方法支持數個案例：
- 漸進式應用程式升級：將流量的百分比路由傳送至新的來源，並隨著時間逐漸增加。
- 應用程式移轉至 Azure︰建立同時具有 Azure 和外部原點的原點群組。 調整權重以偏好新的來源，逐漸增加其流量比例，直到能處理大部分流量，然後停用並移除較不偏好的來源。
- 雲端擴展以增加容量：透過新增或啟用更多原始來源並指定流量分配，將內部部署擴展至雲端。
工作階段親和性
根據預設，Azure Front Door 會將來自相同用戶端的要求轉送至不同的來源。 不過，會話親和性對於有狀態的應用程式或相同用戶後續的請求需要由同一來源處理的情況非常有用。 這項功能可確保同源處理使用者的會話，例如有助於客戶端驗證等情境。
Azure Front Door 使用 Cookie 型工作階段親和性，其中受控 Cookie 會使用對原始來源 URL 進行 SHA256 雜湊的結果作為識別碼。 此方法將後續流量從使用者會話導向同一起點。
在 Azure Front Door Standard 與 Premium 層級中，您可以在來源群組層級啟用工作階段親和性；在 Azure Front Door (傳統) 中，則可在前端主機層級，針對每個已設定的網域或子網域啟用。 啟用此功能後，Azure Front Door會為使用者的會話新增名為 ASLBSA 和 ASLBSACORS 的 cookie。 這些 Cookie 即使使用者共用相同 IP 位址，也能協助辨識不同使用者，讓流量在來源間分配得更平均。
Cookie 的存留期符合使用者的會話，因為 Front Door 目前僅支援會話 Cookie。
注意
瀏覽器的工作階段 Cookie 在網域層級維持工作階段親和性。 只要使用者的瀏覽器對相同來源的資源提出請求，同一個通配符網域下的子域就可以共享會話親和性。
公用 Proxy 可能會干擾工作階段親和性，因為在建立工作階段時，Front Door 必須在回應中加入工作階段親和性 Cookie。 如果回應是可快取的，這個動作就無法執行，因為這會干擾其他客戶端請求相同資源的 Cookie。 為避免此問題，若來源方發送的回應是可快取的，則不會建立會話親和性。 如果會話已經建立，則回應的快取性就不再重要。
在標準的不可快取情境之外，工作階段親和性會在以下情況下建立：
- 回應包含
Cache-Controlno-store 標頭。 - 回應包含有效的
Authorization標頭。 - 回應是 HTTP 302 狀態碼。