傳送至原點的流量路由傳送方法
重要
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，流量會分散至 A 3/10，而 7/10 則散發至 B。
如果已啟用會話親和性，會話中的第一個要求會遵循先前說明的流程。 後續請求會傳送至第一項請求選取的原點。
最低延遲式流量路由
將來源部署在多個全域位置可以藉由將流量路由傳送至「最接近」使用者的來源，來增強應用程式的回應性。 延遲路由方法是 Azure Front Door 設定的預設值。 此方法會將使用者要求導向到具有最低網路等待時間的來源，而不是最接近的地理位置，以確保最佳效能。
Azure Front Door 的任何廣播架構與延遲路由方法結合，可確保每位用戶體驗根據其位置獲得最佳效能。 每個 Front Door 環境都會獨立測量來源的延遲，這表示不同位置的使用者會路由傳送至提供其特定環境最佳效能的來源。
注意
依預設，延遲敏感度屬性會設定為 0 毫秒。 使用此設定時，要求一律會轉送至最快的可用來源。 只有在兩個來源具有相同的網路等待時間時，來源的權數才會生效。
如需詳細資訊，請參閱 Azure Front Door 路由架構。
優先順序式流量路由
為了確保高可用性，組織通常會在主要服務失敗時部署備份服務來接管。 此設定稱為主動/待命或主動/被動部署。 Azure Front Door 中的優先順序流量路由方法可讓您有效地實作此故障轉移模式。
根據預設，Azure Front Door 會將流量路由傳送至優先順序最高的來源（最低優先順序值）。 如果這些主要來源變成無法使用，它會將流量路由傳送至次要來源（下一個最低優先順序值）。 如果主要和次要來源無法使用，此程式會繼續進行第三個原始來源。 健康狀態探查會根據其設定的狀態和健康情況來監視來源的可用性。
設定原點優先順序
Azure Front Door 來源群組中的每個原始來源都有 Priority 屬性，其可設定為介於 1 到 5 之間的值。 較低的值就代表優先順序較高。 多個來源可以共用相同的優先順序值。
加權流量路由方法
加權流量路由方法可讓您根據預先定義的權數來散發流量。
在此方法中，您會將權數指派給 Azure Front Door 原始群組中的每個原始來源。 權數是介於 1 到 1000 之間的整數，預設值為 50。
如果來源符合可接受的延遲敏感度，流量會使用迴圈配置資源機制，根據指定的權數比例，將流量分散到可用的來源之間。 如果延遲敏感度設定為 0 毫秒，則權數只有在兩個來源具有相同的網路等待時間時才會生效。
加權方法支持數個案例：
- 漸進式應用程式升級：將流量的百分比路由傳送至新的來源，並隨著時間逐漸增加。
- 應用程式移轉至 Azure︰建立同時具有 Azure 和外部原點的原點群組。 調整權數以偏好新的來源，逐漸增加其流量共用，直到處理大部分的流量，然後停用並移除較不慣用的來源。
- 額外容量的雲端高載：藉由新增或啟用更多來源並指定流量散發，擴充內部部署至雲端。
工作階段親和性
根據預設，Azure Front Door 會將來自相同用戶端的要求轉送至不同的來源。 不過，會話親和性對於具狀態應用程式或相同用戶後續要求需要由相同來源處理的情況很有用。 這項功能可確保相同的來源會處理使用者的會話，這對客戶端驗證等案例很有説明。
Azure Front Door 使用以 Cookie 為基礎的會話親和性，其中使用來源 URL SHA256 作為標識碼的受控 Cookie。 這會將後續從用戶會話的流量導向至相同的來源。
會話親和性可以在 Azure Front Door Standard 和進階層的原始群組層級上啟用，以及每個已設定網域或子域的前端主機層級。 啟用之後，Azure Front Door 會將名為 ASLBSA 和 ASLBSACORS 的 Cookie 新增至使用者的會話。 這些 Cookie 有助於識別不同的使用者，即使他們共用相同的 IP 位址，也允許在來源之間更均勻地散發流量。
Cookie 的存留期符合使用者的會話，因為 Front Door 目前僅支援會話 Cookie。
注意
會話親和性是透過網域層級的瀏覽器會話 Cookie 來維護。 只要使用者的瀏覽器傳送相同原始來源資源的要求，同一個通配符網域下的子域就可以共用會話親和性。
公用 Proxy 可能會干擾會話親和性，因為建立會話需要 Front Door 將會話親和性 Cookie 新增至回應。 如果回應可快取，則無法完成此動作，因為它會中斷要求相同資源之其他用戶端的 Cookie。 為避免這種情況，如果來源傳送可快取的回應，則不會建立會話親和性。 如果已建立會話，回應的可快取性並不重要。
除標準非快取案例之外，會在以下情況建立工作階段親和性：
- 回應包含
Cache-Control沒有 存放區的標頭。 - 回應包含有效的
Authorization標頭。 - 回應是 HTTP 302 狀態碼。