Azure Front Door 中的原點和原點群組
重要
Azure Front Door (傳統) 將於 2027 年 3 月 31 日遭到淘汰。 為了避免任何服務中斷，請務必在 2027 年 3 月之前，將 Azure Front Door (傳統) 設定檔移轉至 Azure Front Door 標準或進階層。 如需詳細資訊，請參閱 Azure Front Door (傳統版) 淘汰。
注意
本文章中的來源和來源群組是指 Azure Front Door (傳統) 設定的後端和後端集區。
本文說明如何使用 Azure Front Door 對應 Web 應用程式部署的概念。 您將了解 Azure Front Door 設定中的「原點」和「原點群組」。
原始來源
原點是指 Azure Front Door 從中擷取內容的應用程式部署。 Azure Front Door 支援裝載於 Azure 的原點，以及裝載於內部部署資料中心或其他雲端提供者的應用程式。 原點不應該與您的資料庫層或儲存層混淆。 原點應該視為應用程式後端的端點。 當您在 Front Door 設定中將原點新增至原點群組時，也必須設定下列設定：
原點類型：您想要新增的資源類型。 Front Door 支援從應用程式服務、雲端服務或儲存體自動探索您的應用程式後端。 若要使用 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 Apps、Blob 儲存體和雲端服務) 都需要主機標頭符合後端的網域。 不過，路由至原點的前端主機會使用不同的主機名稱，例如 www.contoso.net。
如果您的原點要求主機標頭符合原點主機名稱，請確定原點主機標頭包含原點的主機名稱。
注意
如果您使用 App Service 作為原點，請確定 App Service 也已設定自訂網域名稱。 如需詳細資訊，請參閱將現有的自訂 DNS 名稱對應至 Azure App Service。
為原點設定原點主機標頭
若要在原點群組區段中為原點設定原點主機標頭欄位：
開啟您的 Front Door 資源，然後選取具有要設定原點的原點群組。
如果您尚未這麼做，請新增原點，或編輯現有的原點。
將原點主機標頭欄位設定為自訂值，或將其保留空白。 傳入要求的主機名稱會用來作為主機標頭值。
原始群組
Azure Front Door 中的原點群組是指一組原點，可接收其應用程式的類似流量。 您可以將原點群組定義為全球應用程式執行個體的邏輯群組，用於接收相同的流量，並以預期的行為回應。 這些原點可部署至不同區域或相同區域內。 所有原點都可以部署在主動/主動或主動/被動設定中。
原點群組會定義健全狀態探查評估原點的方式。 其也會定義兩者之間的負載平衡方法。
健康情況探查
Azure Front Door 會將定期 HTTP/HTTPS 探查要求傳送至每個已設定的原點。 探查要求會決定每個原點的鄰近性和健康情況，以平衡使用者要求的負載。 原點群組的健康狀態探查設定會定義如何輪詢應用程式後端的健康狀態。 下列設定適用於負載平衡設定：
路徑：用於原點群組中所有原點探查要求的 URL。 例如，如果您的其中一個原點是
contoso-westus.azurewebsites.net，並且路徑設定為 /probe/test.aspx，則 Front Door 會在通訊協定設定為 HTTP 的情況下，將健全狀態探查要求傳送至http://contoso-westus.azurewebsites.net/probe/test.aspx。通訊協定：定義當健康狀態探查要求要從 Front Door 傳送至原點時，要使用 HTTP 還是 HTTPS 通訊協定。
方法：用來傳送健康狀態探查的 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 將要求傳送至延遲度量敏感度範圍內的原點，或是將要求轉送至最近的後端。
如需詳細資訊，請參閱最低延遲型路由方法。