適用於： ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door （傳統）
重要
Azure Front Door (傳統) 將於 2027 年 3 月 31 日遭到淘汰。 為了避免任何服務中斷，請務必在 2027 年 3 月之前將 Azure Front Door（傳統）配置檔移轉至 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 的 Anycast 架構與延遲路由方法結合，可確保每位用戶根據其位置體驗最佳效能。 每個 Front Door 環境都會獨立測量來源的延遲，這表示不同位置的使用者會路由傳送至提供其特定環境最佳效能的來源。
注意
依預設，延遲敏感度屬性會設定為 0 毫秒。 使用此設定時，要求一律會轉送至最快的可用來源。 只有當兩個原點具有相同的網路延遲時，原點的權重才會生效。
如需詳細資訊，請參閱 Azure Front Door 路由架構。
優先順序式流量路由
為確保高可用性，部署備用服務以在主要服務失效時接手。 此設定稱為作用中/待命或主動/被動部署。 Azure Front Door 中的 Priority流量路由方法可協助你實作此故障轉移模式。
根據預設，Azure Front Door 會將流量路由傳送至優先順序最高的來源（最低優先順序值）。 如果這些主要來源變成無法使用，它會將流量路由傳送至次要來源（下一個最低優先順序值）。 如果主要和次要來源不可用，程序會繼續使用第三級來源。 健康探測依據其設定的狀態和健康情況監控來源的可用性。
設定原點優先順序
你Azure Front Door起源群組中的每個原點都有一個Priority屬性，你可以設定為1到5之間的值。 較低的值就代表優先順序較高。 多個來源可以共用相同的優先順序值。
加權流量路由方法
注意
對於 RPS（每秒請求數）非常低的客戶，由於 AFD POP 和機器分散的特性，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 在網域層級保持會話關聯性。 只要使用者的瀏覽器對相同來源的資源提出請求，同一個通配符網域下的子域就可以共享會話親和性。
公共代理可能會干擾會話親和性，因為建立會話時，Front Door 必須在回應中加入會話親和 Cookie。 如果回應是可快取的，這個動作就無法執行，因為這會干擾其他客戶端請求相同資源的 Cookie。 為避免此問題，若來源方發送的回應是可快取的，則不會建立會話親和性。 如果會話已經建立，則回應的快取性就不再重要。
在標準的非快取情境之外，會話親和力是在以下情況下建立的：
- 回應包含
Cache-Controlno-store 標頭。 - 回應包含有效的
Authorization標頭。 - 回應是 HTTP 302 狀態碼。