Front Door 的最佳做法
本文將摘要說明使用 Azure Front Door 的最佳做法。
一般最佳做法
了解合併 流量管理員和 Front Door 的時機
針對大部分的解決方案，我們建議使用 Front Door 或 Azure 流量管理員，但不要同時使用這兩者。 Azure 流量管理員 是以 DNS 為基礎的負載平衡器。 它會將流量直接傳送至來源的端點。 相反地，Azure Front Door 會在用戶端附近的存在點 （PoP） 終止連線，並建立與來源的個別長期連線。 產品的運作方式不同，且適用於不同的使用案例。
如果您需要內容快取和傳遞 (CDN)、TLS 終止、進階路由功能，或 Web 應用程式防火牆 (WAF)，請考慮使用 Front Door。 若要使用從用戶端直接連線到端點的簡易全域負載平衡，請考慮使用流量管理員。 如需有關選取負載平衡選項的詳細資訊，請參閱負載平衡選項。
不過，作為需要高可用性的複雜架構的一部分，您可以將 Azure 流量管理員 放在 Azure Front Door 前面。 在 Azure Front Door 無法使用的不太可能情況下，Azure 流量管理員 接著可以將流量路由傳送至替代目的地，例如 Azure 應用程式閘道 或合作夥伴內容傳遞網路（CDN）。
重要
請勿將 Azure 流量管理員 放在 Azure Front Door 後面。 Azure 流量管理員 應該一律位於 Azure Front Door 前面。
限制針對您來源的流量
Front Door 的功能在流量僅留經 Front Door 時的效果最佳。 您應該設定來源以封鎖未透過 Front Door 傳送的流量。 如需詳細資訊，請參閱保護針對 Azure Front Door 來源的流量。
使用最新的 API 版本和 SDK 版本
當您使用 API、ARM 範本、Bicep 或 Azure SDK 處理 Front Door 時，請務必使用最新的 API 或 SDK 版本。 API 和 SDK 推出新功能時就會更新，也會包含重要的安全性修補檔和錯誤修正程式。
設定記錄
Front Door 會追蹤每個要求相關的廣泛遙測資料。 當您啟用快取時，原始伺服器可能不會收到每個要求，因此請務必使用 Front Door 記錄來了解解決方案如何運作以及如何回應用戶端。 如需 Azure Front Door 所記錄計量與記錄的詳細資訊，請參閱在 Azure Front Door 中監視計量和記錄以及 WAF 記錄。
若要為您的應用程式設定記錄，請參閱設定 Azure Front Door 記錄
TLS 最佳做法
使用端對端 TLS
Front Door 會終止來自用戶端的 TCP 和 TLS 連線。 然後會從每個存在點 (PoP) 到原點建立新的連線。 使用 TLS 保護每個連線是很好的做法，即使是裝載在 Azure 中的原點也是如此。 此方法可確保您的資料在傳輸期間一律加密。
如需詳細資訊，請參閱 Azure Front Door 的端對端 TLS。
使用 HTTP 到 HTTPS 重新導向
用戶端使用 HTTPS 連線到您的服務是很好的做法。 不過，有時候您需要接受 HTTP 要求，以允許舊版用戶端或可能不了解最佳做法的用戶端。
您可以將 Front Door 設定為自動重新導向 HTTP 要求來使用 HTTPS 通訊協定。 您應該在路由上啟用重新導向所有流量，以使用 HTTPS 設定。
使用受控 TLS 認證
當 Front Door 管理 TLS 認證時，會降低您的營運成本，並協助您避免因忘記續訂認證而造成成本高昂的中斷。 Front Door 會自動發出並輪替受控 TLS 認證。
如需詳細資訊，請參閱使用 Azure 入口網站在 Azure Front Door 自訂網域上設定 HTTPS。
使用「最新」版本的客戶管理憑證
如果您決定使用自己的 TLS 憑證，請考慮將 Key Vault 憑證版本設定為「最新」。 使用「最新」設定可以避免必須將 Front Door 重新設定為使用新版本的憑證，並等候憑證在整個 Front Door 環境中部署。
如需詳細資訊，請參閱選取讓 Azure Front Door 進行部署的憑證。
網域名稱最佳做法
在 Front Door 和您的來源上使用相同的網域名稱
Front Door 可以重寫傳入要求的 Host 標頭。 當您管理一組路由至單一原點的客戶面向自訂網域名稱時，這項功能會很有幫助。 當您想要避免在 Front Door 和原點設定自訂網域名稱時，此功能也可提供協助。 不過，在重寫 Host 標頭時，要求 Cookie 和 URL 重新導向可能會中斷。 尤其是當您使用 Azure App Service 等平台時，工作階段親和性和驗證與授權等功能可能無法正常運作。
在重寫要求的 Host 標頭之前，請詳細考慮您的應用程式是否可以正常運作。
如需詳細資訊，請參閱在反向 Proxy 及其後端 Web 應用程式之間保留原始 HTTP 主機名稱。
Web 應用程式防火牆 (WAF)
啟用 WAF
針對網際網路面向的應用程式，建議您啟用 Front Door Web 應用程式防火牆 (WAF)，並將其設定為使用受控規則。 在使用 WAF 和 Microsoft 受控規則時，您的應用程式會受到保護，而免於遭受各式各樣的攻擊。
如需詳細資訊，請參閱 Azure Front Door 的 Web 應用程式防火牆 (WAF)。
遵循 WAF 最佳做法
Front Door 的 WAF 有自己專屬的一套設定和使用最佳做法。 如需詳細資訊，請參閱 Azure Front Door 的 Web 應用程式防火牆最佳做法。
健全狀態探查最佳做法
當原點群組中只有一個原點時，停用健全狀態探查
Front Door 的健全狀態探查主要是用來偵測原點無法使用或狀況不良的情況。 當健全狀態探查偵測到原點的問題時，可以設定 Front Door 將流量傳送至原點群組中的另一個原點。
如果您只有單一來源，則 Front Door 始終會將流量路由至該來源，即使其健全狀態探查報告了狀況不良狀態也是如此。 健全狀態探查的狀態不會執行任何動作來變更 Front Door 的行為。 在此案例中，健全狀態探查無法提供任何優勢，您應該將其停用來減少原點上的流量。
如需詳細資訊，請參閱健康狀態探查。
選取良好的健全狀態探查端點
請思考要求 Front Door 健全狀態探查進行監視的位置。 通常最好是監視您特別針對狀況監控所設計的網頁或位置。 您的應用程式邏輯可以考慮提供生產流量所需的所有重要元件狀態，包括應用程式伺服器、資料庫及快取。 如此一來，如果有任何元件失敗，Front Door 可以將流量路由傳送至服務的另一個執行個體。
如需詳細資訊，請參閱健康情況端點監視模式。
使用 HEAD 健全狀態探查
健全狀態探查可以使用 GET 或 HEAD HTTP 方法。 最好使用 HEAD 方法來探查健全狀態，以減少原點的流量負載量。
如需詳細資訊，請參閱健全狀態探查支援的 HTTP 方法。
下一步
了解如何建立 Front Door 設定檔。