Azure Front Door 中的原始來源和來源群組

發行項
04/04/2024

重要

Azure Front Door（傳統版）將於 2027 年 3 月 31 日淘汰。為了避免任何服務中斷，請務必在 2027 年 3 月之前將 Azure Front Door （傳統）配置檔移轉至 Azure Front Door Standard 或進階版層。如需詳細資訊，請參閱 Azure Front Door（傳統版）淘汰。

注意

本文章中的來源和來源群組是指 Azure Front Door (傳統) 設定的後端和後端集區。

本文說明如何使用 Azure Front Door 對應 Web 應用程式部署的概念。您會瞭解 Azure Front Door 組態中的原點 和 原始群組 為何。

原始來源

來源是指 Azure Front Door 在未啟用快取時或快取遺漏時擷取內容的應用程式部署。 Azure Front Door 支援裝載於 Azure 中的來源，以及裝載於內部部署資料中心或另一個雲端提供者的應用程式。來源不應與您的資料庫層或儲存層混淆。來源應視為應用程式後端的端點。當您在 Front Door 組態中將來源新增至原始群組時，您也必須設定下列設定：

原始類型： 您想要新增的資源類型。 Front Door 支援從 App Service、雲端服務或儲存體自動探索應用程式後端。如果您想要 Azure 或甚至是非 Azure 後端中的不同資源，請選取 [自定義主機]。

重要

在設定期間，API 不會驗證來源是否無法從 Front Door 環境存取。請確定 Front Door 可以觸達您的來源。
訂用帳戶和來源主機名： 如果您未針對後端主機類型選取 [自定義主機 ]，請選擇適當的訂用帳戶和對應的後端主機名，以選取您的後端。

Private Link：Azure Front Door 進階版層支援使用 Private Link 將流量傳送至來源。如需詳細資訊，請參閱使用 Private Link 保護您的原始來源。
憑證主體名稱驗證： 在 Azure Front Door 到來源 TLS 連線期間，Azure Front Door 會驗證要求主機名是否符合來源所提供憑證中的主機名。從安全性的觀點來看，Microsoft 不建議停用憑證主體名稱檢查。如需詳細資訊，請參閱端對端 TLS 加密，特別是如果您想要停用此功能。

原始主機標頭： 針對每個要求傳送至後端的主機標頭值。如需詳細資訊，請參閱原始主機標頭。
優先順序。當您想要針對所有流量使用主要服務後端時，將優先順序指派給不同的後端。此外，如果主要或備份後端無法使用，請提供備份。如需詳細資訊，請參閱優先順序。
權重。將權數指派給不同的後端，以平均或根據權數係數將流量分散到一組後端。如需詳細資訊，請參閱權數。

來源主機標題

Azure Front Door 轉送至來源的要求包括來源用來擷取目標資源的主機標頭字段。此欄位的值通常來自具有主機標頭和埠的來源 URI。

例如，針對提出的 www.contoso.com 要求具有主機標頭 www.contoso.com。如果您使用 Azure 入口網站來設定原點，此欄位的預設值是來源的主機名。如果原始來源是 contoso-westus.azurewebsites.net，在 Azure 入口網站中，原始主機標頭contoso-westus.azurewebsites.net的自動填入值為。不過，如果您在未明確設定此字段的情況下使用 Azure Resource Manager 範本或其他方法，Front Door 會將傳入主機名傳送為主機標頭的值。如果已針對 www.contoso.com提出要求，且您的原始來源 contoso-westus.azurewebsites.net 具有空的標頭欄位，Front Door 會將主機標頭設定為 www.contoso.com。

大部分的應用程式後端（Azure Web Apps、Blob 記憶體和雲端服務）都需要主機標頭以符合後端的網域。不過，路由傳送至您來源的前端主機會使用不同的主機名，例如 www.contoso.net。

如果您的來源要求主機標頭符合原始主機名，請確定原始主機標頭包含來源的主機名。

注意

如果您使用 App Service 作為來源，請確定 App Service 也已設定自定義功能變數名稱。如需詳細資訊，請參閱將現有的自定義 DNS 名稱對應至 Azure App 服務。

設定來源的源主機標頭

若要在原始群組區段中設定來源的源主機標頭欄位：

開啟您的 Front Door 資源，然後選取具有要設定的來源群組。
如果您尚未這麼做，請新增來源，或編輯現有的來源。
將原始主機標頭字段設定為自定義值，或將它保留空白。傳入要求的主機名會當做主機標頭值使用。

原始群組

Azure Front Door 中的來源群組是指一組來源，可接收其應用程式的類似流量。您可以將來源群組定義為世界各地應用程式實例的邏輯群組，這些實例會接收相同的流量，並以預期的行為回應。這些來源可以部署到不同區域或相同區域內。所有來源都可以部署在主動/主動或主動/被動設定中。

原始群組會定義健康情況探查評估來源的方式。它也會定義它們之間的負載平衡方法。

健康情況探查

Azure Front Door 會將定期 HTTP/HTTPS 探查要求傳送至每個已設定的來源。探查要求會決定每個來源的鄰近性和健康情況，以平衡使用者要求負載。原始群組的健康情況探查設定會定義如何輪詢應用程式後端的健康情況狀態。下列設定可用於負載平衡組態：

路徑：用於來源群組中所有來源之探查要求的URL。例如，如果您的其中一個來源是 contoso-westus.azurewebsites.net ，且路徑設定為 /probe/test.aspx，則 Front Door 會將健康情況探查要求 http://contoso-westus.azurewebsites.net/probe/test.aspx 傳送至，如果通訊協定設定為 HTTP。
通訊協定：定義是否使用 HTTP 或 HTTPS 通訊協定，將健康情況探查要求從 Front Door 傳送至您的來源。
方法：要用於傳送健康情況探查的 HTTP 方法。選項包括 GET 或 HEAD （預設值）。

注意

為了降低後端的負載和成本，Front Door 建議針對健康情況探查使用 HEAD 要求。
間隔（秒）：定義健康情況探查到您的來源的頻率，或每個 Front Door 環境傳送探查的間隔。

注意

若要加快故障轉移速度，請將間隔設定為較低的值。值越低，後端接收的健康情況探查磁碟區就越高。例如，如果間隔設定為 30 秒，且假設全域有 100 個 Front Door POP，則每個後端每分鐘會收到大約 200 個探查要求。

如需詳細資訊，請參閱健康狀態探查。

負載平衡設定

原始群組的負載平衡設定會定義我們如何評估健康情況探查。這些設定會判斷來源是否狀況良好或狀況不良。它們也會檢查如何平衡來源群組中不同來源之間的流量負載。下列設定可用於負載平衡組態：

樣本大小： 識別我們需要考慮多少個健康情況探查樣本，以進行原始健康情況評估。
成功取樣大小： 定義先前所述的樣本大小，這是呼叫來源狀況良好所需的成功樣本數目。例如，假設 Front Door 健康情況探查間隔為 30 秒，樣本大小為 5，而成功的樣本大小為 3。每次我們評估您來源的健康情況探查時，我們會查看最後五個樣本超過 150 秒（5 x 30）。至少需要三個成功的探查，才能將來源宣告為狀況良好。
延遲敏感度（額外延遲）： 定義您是否希望 Front Door 將要求傳送至延遲測量敏感度範圍內的原點，或將要求轉送至最接近的後端。

如需詳細資訊，請參閱最低延遲型路由方法。

下一步

了解如何建立 Azure Front Door 設定檔。
了解 Azure Front Door 路由架構。

瞭解如何建立 Azure Front Door （傳統）配置檔。
瞭解 Azure Front Door （傳統）路由架構。