傳送至原點的流量路由傳送方法
重要
Azure Front Door（傳統版）將於 2027 年 3 月 31 日淘汰。 為了避免任何服務中斷，請務必在 2027 年 3 月之前將 Azure Front Door （傳統） 配置檔移轉至 Azure Front Door Standard 或 進階版 層。 如需詳細資訊，請參閱 Azure Front Door（傳統版）淘汰。
Azure Front Door 支援四種不同的流量路由傳送方法，以判斷 HTTP/HTTPS 流量在不同原點之間散發的方式。 當使用者要求到達 Front Door 邊緣位置時，系統會套用已設定的路由傳送方法，以確保要求會轉送到最佳的後端資源。
注意
本文章中的原點和原點群組是指 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 環境，在可容許的延遲範圍內選取原點。 這個訊號是根據原點群組的延遲敏感度設定，以及較近原點的延遲。
- 範例：假設 Front Door 已測量出從請求到達環境至原點 A 的延遲時間為 15 毫秒、至 B 的延遲時間為 30 毫秒，而至 D 為 60 毫秒。 若原點群組的延遲敏感度設定為 30 毫秒，則最低延遲集區由原點 A 與 B 組成，因為 D 距離最接近的原點 A 超過 30 毫秒。
- 權重：最後，Azure Front Door 會按照指定的加權比率，在最終選定的原點群組之間循環配置流量。
- 範例：若原點 A 的權重為 3，而原點 B 的權重為 7，則流量會以 3/10 給原點 A、7/10 給原點 B 進行分配。
若啟用工作階段親和性，則工作階段的第一項請求會遵守上述流程。 後續請求會傳送至第一項請求選取的原點。
最低延遲式流量路由
如果將原點部署在全球的兩個或更多個位置，然後將流量路由傳送至「最靠近」您終端使用者的目的地，即可改善您應用程式的回應速度。 延遲是 Front Door 設定的預設流量路由傳送方法。 此路由傳送方法會將來自終端使用者的要求轉送至 Azure Front Door 背後的最靠近原點。 這個路由機制與 Azure Front Door 的任何傳播架構相結合，可確保個別最終使用者根據其所在位置獲得最佳效能。
「最靠近」的原點不一定是地理距離測量上最靠近的原點。 相反的，Azure Front Door 會透過測量網路延遲來決定最靠近的原點。 深入閱讀 Azure Front Door 路由傳送架構。
個別 Front Door 環境會分別測量原點延遲。 這代表不同位置的不同使用者會利用其環境的最佳效能來路由至原點。
注意
依預設，延遲敏感度屬性會設定為 0 毫秒。 使用此設定時，除非兩個原點具有相同的網路延遲，否則要求一律會轉送到最快速的可用原點，且原點上的權數不會生效。
優先順序式流量路由
組織通常會想要藉由部署多個備份服務來為其服務提供高可用性，以防主要備份服務停止運作。 在業界中，此類型的拓撲也稱為拓撲「使用中/待命」或「主動/被動」部署。 「優先順序」流量路由方法可讓您輕鬆實作此容錯移轉模式。
預設 Azure Front Door 包含原點清單，其中每個原點都具有相同的優先順序。 根據預設，Azure Front Door 只會將流量傳送到優先順序最高的原點 (優先順序值最低)，作為原點的主要集合。 如果無法使用主要原點時，Azure Front Door 會將流量路由傳送至原點的次要集合 (優先順序值次低)。 如果主要和次要原點都無法供使用，系統就會將流量傳送到第三個原點，依此類推。 原點的可用性是以設定狀態及健全狀態探查判斷的進行中原點健康狀態為基礎。
設定原點優先順序
在 Azure Front Door 設定的原點群組中，每個原點都具有稱為「優先順序」的屬性，其數字介於 1 和 5 之間。 搭配 Azure Front Door，您可以針對每個原點使用此屬性，明確地設定原點優先順序。 此屬性的值介於 1 到 5 之間。 值愈低，優先順序愈高。 原點可以共用相同的優先順序值。
加權流量路由方法
「加權」流量路由傳送方法可讓您平均散發流量，或使用預先定義的權數。
在加權流量路由傳送方法中，您會在您原點群組的 Azure Front Door 設定中為每個原點指派權數。 權數是範圍 1 到 1,000 的整數。 此參數會使用預設權數 50。
搭配具有可接受延遲敏感度的可用原點清單，流量會使用指定的權數比例，搭配循環機制進行散發。 如果延遲敏感度設定為 0 毫秒，則除非有兩個具有相同網路延遲的原點，否則此屬性不會生效。
加權方法支援一些實用的案例︰
- 應用程式逐步升級：提供要路由傳送到新原點的流量百分比，並隨時間逐漸增加流量到與其他原點相等。
- 應用程式移轉至 Azure︰建立同時具有 Azure 和外部原點的原點群組。 調整原點的權數來優先使用新的原點。 您可以從停用新原點，再將最低權數指派給它們，並緩慢增加到使其接收最多流量的層級，來逐漸設定。 接著最後再停用較不慣用的原點，並從群組中移除它們。
- 額外容量的雲端高載：透過將其放在 Front Door 之後，使內部部署快速展開至雲端。 當您需要在雲端中增加額外容量時，您可以新增或啟用更多原點並指定進入每個原點的流量比例。
工作階段親和性
根據預設，若沒有工作階段親和性，Azure Front Door 會將源自相同用戶端的要求轉送至不同的原點。 特定具狀態應用程式，或在特定案例中，其中來自相同使用者的後續要求偏好相同的原點來處理初始要求。 當您想要在同一個原點保留使用者工作階段時，以 Cookie 為基礎的工作階段親和性非常有用。 當您搭配原點 URL 的 SHA256 使用受控 Cookie 作為 Cookie 中的識別碼時，Azure Front Door 可以將來自使用者工作階段的後續流量導向至相同的原點進行處理。
針對您設定的每個網域 (子網域)，工作階段親和性可以在下列層級中啟用：Azure Front Door 標準及進階級中的原點群組層級，以及 Azure Front Door (傳統) 中的前端主機層級。 一旦啟用，Azure Front Door 就會將 Cookie 新增到使用者的工作階段。 這些 Cookie 稱為 ASLBSA 和 ASLBSACORS。 根據 Cookie 的工作階段親和性可讓 Front Door 識別不同使用者 (即使使用者位於相同 IP 位址之後)，在您的不同原點間進行更平均的流量散發。
Cookie 的存留期與使用者工作階段相同，因為 Front Door 目前僅支援工作階段 Cookie。
注意
不論其設定位置為何，都會透過網域層級的瀏覽器工作階段 Cookie 來記住工作階段親和性。 相同萬用字元網域下的子網域可以共用工作階段親和性，只要相同的使用者瀏覽器傳送相同原點資源的要求即可。
公用 Proxy 可能會影響工作階段親和性。 這是因為建立工作階段需要 Front Door 將工作階段親和性 Cookie 新增至回應，因此若可針對回應進行快取，便會中斷要求相同資源的其他用戶端 Cookie。 為了避免此問題，工作階段親和性不會在原點嘗試傳送可快取的回應時建立。 若工作階段已建立，則無論來自原點的回應是否可進行快取，皆不會造成影響。
除標準非快取案例之外，會在以下情況建立工作階段親和性：
- 回應必須包含 no-store 的
Cache-Control標頭。 - 如果回應包含
Authorization標頭，則不得過期。 - 回應是 HTTP 302 狀態碼。