Azure Front Door 是全域負載平衡器和內容傳遞網路 （CDN），可路由傳送 HTTP 和 HTTPS 流量。 Azure Front Door 提供並分配最接近應用程式使用者的網路流量。
本文假設身為架構設計人員，您已檢閱 負載平衡選項， 並選擇 Azure Front Door 作為工作負載的負載平衡器。 它也假設您的應用程式部署至主動-主動或主動-被動模型中的多個區域。 本文中的指引提供架構建議，這些建議會對應至 Azure 原則的 Framework Well-Architected 支柱。
重要
如何使用本指南
每個區段都有 設計檢查清單，其中呈現已當地語系化至技術範圍的架構領域和設計策略。
本文也包含 建議， 有助於具體化這些策略的技術功能。 建議並不代表 Azure Front Door 及其相依性可用之所有組態的完整清單。 相反，他們列出了與設計視角對應的主要建議。 使用建議來建置概念證明或優化現有的環境。
示範關鍵建議的基礎架構：帶有網路控制的任務關鍵基準架構。
技術範圍
此檢閱著重於下列 Azure 資源的相關決策：
- Azure 前端門戶
可靠性
可靠性支柱的目的是藉由 建置足夠的復原能力，以及從失敗快速復原的能力，來提供持續的功能。
可靠性設計原則 提供適用於個別元件、系統流程和整個系統的高階設計策略。
設計檢查清單
根據可靠性 的設計檢閱檢查清單，啟動您的設計策略。 請確定其與您的商務需求相關性，同時請記住層級和CDN功能。 擴充策略，以視需要包含更多方法。
選擇部署策略。 基本部署方法 主動-主動，主動-被動。 雙活部署指的是執行工作負載的多個環境或節點可以同時提供流量服務。 主動-被動式部署表示只有主要區域負責處理所有流量，但在必要時會自動切換至次要區域。 在多區域部署中，戳記或應用程式實例會在不同區域中執行，以提高可用性，並透過如 Azure Front Door 等全域負載平衡器來分配流量。 因此，請務必為適當的部署方法設定負載平衡器。
Azure Front Door 支持數種路由方法，您可以設定為將流量分散在主動-主動或主動-被動模型中。
上述模型有許多變化。 例如，您可以使用暖備援來部署主動-被動模型。 在此情況下，次要託管服務會以最小可能的計算和數據尺寸進行部署，並在無負載的情況下運行。 當發生容錯時，計算和數據資源會擴展以處理主要區域的負載。 如需詳細資訊，請參閱 多區域設計的主要設計策略。
有些應用程式需要用戶連線，才能在用戶會話期間停留在相同的源伺服器上。 從可靠性的觀點來看，我們不建議將用戶連線保留在相同的源伺服器上。 盡可能避免會話親和性。
在每個層次上使用相同的主機名，。 若要確保 Cookie 或重新導向 URL 正常運作，請在 Web 應用程式前面使用反向 Proxy，例如 Azure Front Door 時，保留原始 HTTP 主機名。
實作健康端點監視模式。 您的應用程式應該公開健康情況端點，以匯總應用程式需要處理要求的重要服務和相依性的狀態。 Azure Front Door 健康情況探查會使用端點來偵測源伺服器的健康情況。 如需詳細資訊，請參閱 健康端點監控模式。
快取靜態內容。 Azure Front Door 的內容傳遞功能有數百個邊緣位置，可協助承受流量激增和分散式阻斷服務 （DDoS） 攻擊。 這些功能有助於改善可靠性。
考慮備援流量管理選項。 Azure Front Door 是全域散發的服務，可在環境中以單一方式執行。 Azure Front Door 是系統中潛在的單一失敗點。 如果服務失敗，用戶端就無法在停機期間存取您的應用程式。
建議
| 建議 | 好處 |
|---|---|
| 選擇支援部署策略的 路由方法。 加權方法會根據設定的權數係數分配流量，支援主動-主動模型。 優先順序型值，會將主要區域設定為接收所有流量，並將流量傳送至次要區域作為備份支持主動-被動模型。 將上述方法與延遲敏感度設定結合，讓來源與最低的延遲接收流量。 |
您可以使用一系列決策步驟和設計來選取最佳原始資源。 選取的來源會以指定的權數比例，在允許的延遲範圍內提供流量。 |
| 在一或多個原始群組中 多個原始來源，以支援備援。 一律有應用程式的備援實例，並確定每個實例都會公開來源。 您可以將這些來源放在一或多個原始群組中。 |
多個來源可藉由將流量分散到應用程式的多個實例，以支援備援。 如果某個實例無法使用，則其他來源仍然可以接收流量。 |
|
於來源設置健康探查。 設定 Azure Front Door 進行健康情況檢查，以判斷來源實例是否可用，並準備好繼續接收要求。 如需詳細資訊，請參閱 健康情況探查的最佳做法。 |
啟用的健康情況探查是健康情況監視模式實作的一部分。 健康情況探查可確保 Azure Front Door 只會將流量路由傳送至狀況良好且足以處理要求的實例。 |
| 設定將請求轉送至來源的逾時，並避免長時間執行的請求。 根據您的端點需求調整逾時設定。 如果您未這麼做，Azure Front Door 可能會在來源傳送回應之前關閉連線。 如果所有來源都有較短的逾時，您也可以降低 Azure Front Door 的預設逾時。 如需詳細資訊，請參閱 解決無回應請求的疑難問題。 |
長時間執行的請求會耗用系統資源。 設置時間限制可以藉由終止超過預期時間的請求，協助防止效能問題和可用性問題。 |
| 在 Azure Front Door 和您的來源上使用相同的主機名。 Azure Front Door 可以重寫進入請求的主機標頭，當您擁有多個自訂網域名稱並路由傳送至一個起始點時，這非常有用。 不過，重寫主機標頭可能會導致請求的 Cookie 和 URL 重新導向的問題。 如需詳細資訊，請參閱 [保留原始 HTTP 主機名稱](/azure/architecture/best-practices/host-name-preservation) 在反向代理和其原始 Web 應用程式之間。 |
設定相同的主機名，以防止會話親和性、驗證和授權故障。 |
| 決定您的應用程式是否需要 會話親和性。 如果您有較高的可靠性需求，建議您停用會話親和性功能。 | 使用會話親和性時，使用者連線會在使用者會話期間維持在相同的來源。 在某些情況下，單一原始來源可能會隨著要求而變得多載，而其他來源則處於閑置狀態。 如果該來源變成無法使用，則用戶體驗可能會中斷。 |
| 利用 Web 應用程式防火牆 （WAF） 隨附的 速率限制規則。 | 限制要求以防止用戶端將太多流量傳送至您的應用程式。 速率限制措施可協助您避免重試風暴等問題。 |
安全
安全性要素的目的是為工作負載提供 機密性、完整性和可用性 保證。
安全性設計原則 提供的高階設計策略，透過在技術設計中應用方法，來限制透過 Azure Front Door 的流量，以達到這些目標。
設計檢查清單
根據安全性 的設計檢閱檢查清單，啟動您的設計策略。 識別弱點和控件，以改善安全性狀態。 擴充策略，以視需要包含更多方法。
檢閱 Azure Front Door的安全性基準。
保護源伺服器。 Azure Front Door 是前端介面，也是應用程式的唯一入口點。
Azure Front Door 會使用 Azure Private Link 來存取應用程式的來源。 Private Link 會建立分割，讓來源不需要公開公用IP位址和端點。 如需詳細資訊，請參閱 在 Azure Front Door Premium中使用 Private Link 保護您的來源。
將後端服務設定為只接受與 Azure Front Door 外部所使用的相同主機名的要求。
只允許授權存取控制平面。 使用 Azure Front Door 角色型存取控制 （RBAC） 來限制只存取所需的身分識別。
在邊緣封鎖常見威脅。 WAF 與 Azure Front Door 整合。 在前端啟用 WAF 規則，以保護應用程式免受網路邊緣常見的利用漏洞和弱點攻擊，更貼近攻擊來源。 請考慮進行地理篩選，以限制依國家或地區存取您的 Web 應用程式。
如需詳細資訊，請參閱 Azure Front Door 上的 Azure Web 應用程式防火牆。
防止非預期的流量。 Azure Front Door 的架構提供內建的 DDoS 保護，以保護應用程式端點免受 DDoS 攻擊。 如果您需要從應用程式公開其他公用IP位址，請考慮針對這些位址新增 Azure DDoS 保護標準方案，以取得進階保護和偵測功能。
另外還有 WAF 規則集，可偵測機器人流量或可能是惡意的異常大量流量。
保護傳輸中的數據。 啟用端對端傳輸層安全性 （TLS）、HTTP 到 HTTPS 重新導向，以及適用時受控 TLS 憑證。 如需詳細資訊，請參閱 Azure Front Door 的 TLS 最佳做法。
監視異常活動。 定期檢閱記錄以檢查攻擊和誤報。 將 WAF 記錄從 Azure Front Door 傳送至組織的集中式安全性資訊和事件管理 （SIEM），例如 Microsoft Sentinel，以偵測威脅模式，並在工作負載設計中納入預防性措施。
建議
| 建議 | 效益 |
|---|---|
| 啟用WAF規則集，以偵測並封鎖潛在的惡意流量。 此功能可在進階層使用。 我們建議使用這些規則集： - 預設 - Bot 保護 - IP限制 - 異地篩選 - 速率限制 |
預設規則集會根據 OWASP 前 10 大攻擊類型和來自 Microsoft 威脅情報的資訊，頻繁更新。 特製化規則集會偵測特定使用案例。 例如，Bot 規則會根據用戶端 IP 位址，將 Bot 分類為良好、不良或未知。 它們也會封鎖不正確的 Bot 和已知的 IP 位址，並根據來電者的地理位置限制流量。 藉由使用規則集的組合，您可以使用各種意圖來偵測和封鎖攻擊。 |
|
為受管理的規則集合建立排除項目。 在偵測模式中測試 WAF 原則數周，並在部署前調整任何誤判。 |
減少誤判，並允許應用程式的合法要求。 |
| 將 主機標頭傳送至來源。 | 後端服務應該注意主機名，以便他們建立規則，只接受來自該主機的流量。 |
保護從 Azure Front Door 到來源的連線。
啟用私有連接連線能力， 至支援的來源。 如果您的來源不支援 Private Link 連線，請使用服務標籤和 X-Azure-FDID 標頭來確認要求的來源是您的 Azure Front Door 配置檔。 |
請確定所有流量都會流經 Azure Front Door，並取得 DDoS 保護和 WAF 檢查等安全性優點。 |
| 視需要啟用端對端 TLS、HTTP 到 HTTPS 重新導向，以及受控 TLS 憑證。 檢閱 Azure Front Door TLS 最佳做法。 使用 TLS 1.2 版作為應用程式相關密碼的最低允許版本。 Azure Front Door 管理的憑證應該是您的預設選擇，以便於操作。 不過，如果您想要管理憑證的生命週期，請在 Azure Front Door 自定義網域中使用您自己的憑證 端點，並將其儲存在 Key Vault 中。 |
TLS 可確保瀏覽器、Azure Front Door 和來源之間的數據交換會經過加密，以防止竄改。 Key Vault 提供受控憑證支援，以及簡單的憑證更新和輪替。 |
成本優化
成本優化著重於 偵測支出模式、將投資放在重要領域，並將其他 優化，以符合組織的預算，同時符合商務需求。
成本優化設計原則 提供高階設計策略，以達成這些目標，並在與 Azure Front Door 及其環境相關的技術設計中在必要時進行取捨。
設計檢查清單
根據投資成本優化 設計檢閱檢查清單，開始您的設計策略。 微調設計，讓工作負載符合為工作負載配置的預算。 您的設計應該使用正確的 Azure 功能、監視投資，以及尋找經過一段時間優化的機會。
檢視服務級別和定價。 使用 定價計算機 來估計 Azure Front Door 每一層的實際成本。 比較每個層級的功能 和其在你的情境中的適用性。 例如，只有進階層支援透過 Private Link 連線到您的來源。
標準 SKU 更符合成本效益，適用於中度流量案例。 在進階 SKU 中，您會支付較高的單位費率，但您可以存取 WAF 和 Private Link 中的受控規則等安全性權益和進階功能。 根據業務需求對 可靠性 和 安全性 取捨考慮。
考慮的頻寬成本。 Azure Front Door 的頻寬成本取決於您選擇的層級和數據傳輸類型。 若要瞭解 Azure Front Door 計費，請參閱 瞭解 Azure Front Door 計費。
Azure Front Door 提供關於可計費指標的內建報告。 若要評估與頻寬相關的成本，以及您可以將優化工作放在何處，請參閱 Azure Front Door 報告。
優化傳入要求。 Azure Front Door 會收取傳入要求的費用。 您可以在設計組態中設定限制。
使用前端 後端 和 閘道匯總等設計模式來減少要求數目。 這些模式可以改善作業的效率。
WAF 規則會限制連入流量，以將成本優化。 例如，使用速率限制來防止異常高層級的流量，或使用地理篩選只允許從特定區域或國家/地區存取。
有效率地使用資源。 Azure Front Door 使用可協助資源優化的路由方法。 除非工作負載極度延遲敏感，否則將流量均衡地分配到所有環境，以有效地使用已部署的資源。
Azure Front Door 端點可以提供許多檔案。 降低頻寬成本的其中一種方法是使用壓縮。
針對不會經常變更的內容，使用 Azure Front Door 中的快取。 由於內容是從快取提供，因此您可以節省要求轉送至來源時所產生的頻寬成本。
請考慮使用組織所提供的共享實例。 集中式服務所產生的成本會在工作負載之間共用。 不過，請考慮可靠性 和的取捨。 對於具有高可用性需求的任務關鍵性應用程式，我們建議使用自主實例。
請注意記錄的數據量。 如果某些請求不是必要的，或日誌數據被保留了很長時間，則與頻寬和儲存相關的成本可能會增加。
建議
| 建議 | 好處 |
|---|---|
| 針對支援的端點使用快取。 | 快取可優化數據傳輸成本，因為它可將從 Azure Front Door 實例到來源的呼叫數目減少。 |
|
考慮啟用檔案壓縮。 針對此設定，應用程式必須支援壓縮，而且必須啟用快取。 |
壓縮可減少頻寬耗用量並改善效能。 |
| 停用單一原始來源的原始群組中的健康檢查。 如果您的 Azure Front Door 原始群組中只設定了一個原始來源，則不需要這些呼叫。 |
您可以停用不需要進行路由決策的健康情況檢查要求，以節省頻寬成本。 |
卓越營運
營運卓越主要著重於 開發實務、可觀察性和發行管理的程序。
營運卓越設計原則 提供高階設計策略，以達成工作負載作業需求的目標。
設計檢查清單
根據營運卓越 的 設計檢閱檢查清單，開始您的設計策略，以定義與 Azure Front Door 相關的可觀察性、測試和部署程式。
使用基礎設施即代碼（IaC）技術。 使用 IaC 技術，如 Bicep 和 Azure Resource Manager 範本，來 布建 Azure Front Door 實例。 這些宣告式方法提供一致性和直接維護。 例如，藉由使用 IaC 技術，您可以輕鬆地採用新的規則集版本。 一律使用最新的 API 版本。
簡化組態。 使用 Azure Front Door 輕鬆管理設定。 例如，假設您的架構支援微服務。 Azure Front Door 支援 重新導向功能，因此您可以使用路徑型重新導向來鎖定個別服務。 另一個使用案例是通配符網域的設定。
處理漸進式曝光。 Azure Front Door 提供 多個路由方法，。 針對 加權負載平衡方法，您可以使用金絲雀部署，將特定比例的流量發送到源伺服器。 這種方法可協助您在受控制的環境中測試新功能和版本，再推出這些功能。
作為工作負載監視的一部分，收集和分析運營數據。 使用 Azure 監視器記錄擷取相關的 Azure Front Door 記錄和計量。 此數據可協助您針對使用者行為進行疑難解答、瞭解用戶行為，以及優化作業。
將憑證管理卸除至 Azure。 減輕與認證輪替和更新相關聯的作業負擔。
建議
| 建議 | 效益 |
|---|---|
| 使用 HTTP 到 HTTPS 重新導向 來支援向前相容性。 | 啟用重新導向時，Azure Front Door 會自動將使用較舊通訊協定的用戶端重新導向，以使用 HTTPS 來獲得安全體驗。 |
|
擷取記錄和指標。 包含資源活動記錄、存取記錄、健康情況探查記錄和 WAF 記錄。 設定警示。 |
監視輸入流程是監視應用程式的重要部分。 您想要追蹤要求並改善效能和安全性。 您需要數據才能對 Azure Front Door 設定進行偵錯。 有了警示，您可以立即收到任何重大作業問題的通知。 |
| 檢視 內建分析報告。 | Azure Front Door 配置檔的整體檢視有助於根據 WAF 指標所提供的流量和安全性報告來推動改進。 |
| 盡可能使用受控 TLS 憑證。 | Azure Front Door 可以為您發行和管理憑證。 這項功能可消除憑證更新的需求，並將因無效或已過期的 TLS 憑證而中斷的風險降到最低。 |
| 使用通配符 TLS 憑證。 | 您不需要修改組態，即可個別新增或指定每個子域。 |
效能效率
效能效率與 維護用戶體驗有關，即使藉由管理容量來增加負載 也一定。 此策略包括調整資源、識別和優化潛在的瓶頸，以及優化尖峰效能。
效能效率設計原則 提供針對預期使用量達成這些容量目標的高階設計策略。
設計檢查清單
根據效能效率 的設計檢閱檢查清單，啟動您的設計策略。 定義以 Azure Front Door 關鍵效能指標為基礎的基準。
透過分析預期的流量模式來規劃容量。 進行徹底的測試，以瞭解應用程式在不同負載下執行的方式。 請考慮同時交易、請求率和資料傳輸等因素。
根據該規劃來選擇您的 SKU。 標準 SKU 更符合成本效益，適用於中度流量案例。 如果您預期負載較高，建議您使用進階 SKU。
通過定期檢閱效能指標來分析效能數據。 Azure Front Door 報告 提供各種計量的見解，以作為技術層級的效能指標。
使用 Azure Front Door 報告來設定工作負載的實際效能目標。 請考慮回應時間、輸送量和錯誤率等因素。 將目標與您的商務需求和使用者期望保持一致。
優化數據傳輸。
使用快取來降低提供靜態內容的延遲，例如影像、樣式表單和 JavaScript 檔案，或不會經常變更的內容。
優化您的應用程式以進行快取。 在應用程式中使用快取到期標頭，以控制用戶端和代理伺服器快取內容的時間長度。 較長的快取有效性表示對源伺服器的要求較不頻繁，這會導致流量降低和延遲降低。
減少透過網路傳輸的檔案大小。 較小的檔案會導致載入時間更快，並改善用戶體驗。
將應用程式中的後端要求數目降至最低。
例如，網頁會顯示使用者配置檔、最近的訂單、餘額和其他相關信息。 不要針對每組資訊提出個別要求，而是使用設計模式來建構應用程式，以便將多個要求匯總成單一要求。
更新用戶端以使用 HTTP/2 通訊協定，可將多個要求合併成單一 TCP 連線。
使用 WebSockets 來支援即時全雙工通訊，而不是進行重複的 HTTP 要求或輪詢。
藉由匯總要求，您會在前端與後端之間傳送較少的數據，並在用戶端與後端之間建立較少的連線，以減少額外負荷。 此外，Azure Front Door 會處理較少的要求，以防止多載。
優化健康探測器的使用。 只有在來源狀態變更時，才從健康探測獲取健康資訊。 在監視精確度和將不必要的流量降至最低之間取得平衡。
健康情況探查通常用來評估群組內多個來源的健康情況。 如果您的 Azure Front Door 原始群組中只設定了一個原始來源，請停用健康情況探查，以減少源伺服器上的不必要的流量。 因為只有一個實例，因此健康探測狀態不會影響路由。
檢閱來源路由方法。 Azure Front Door 提供各種路由方法，包括延遲型、優先順序型、加權和會話親和性型路由至來源。 這些方法會大幅影響應用程式的效能。 若要深入瞭解適合您情境的最佳流量路由方式，請參閱流量路由方法至來源的相關資訊 。
檢閱源伺服器的位置。 您的源伺服器位置會影響應用程式的回應性。 源伺服器應該更接近使用者。 Azure Front Door 可確保來自特定位置的使用者存取最接近的 Azure Front Door 進入點。 效能優點包括更快的用戶體驗、更妥善地利用 Azure Front Door 的延遲型路由，以及透過將內容儲存於更接近使用者的地點，來將數據傳輸時間降到最低。
建議
| 建議 | 好處 |
|---|---|
|
啟用快取。 您可以優化 查詢字串，以提升的快取效果。 若為純靜態內容，請忽略查詢字串，以充分利用快取。 如果您的應用程式使用查詢字串，請考慮將它們包含在快取索引鍵中。 在快取索引鍵中包含查詢字串，可讓 Azure Front Door 根據您的組態提供快取的回應或其他回應。 |
Azure Front Door 提供強大的內容傳遞網路解決方案，在網路邊緣快取內容。 快取可減少源伺服器上的負載，並減少網路上的數據移動，這有助於減少頻寬的使用。 |
| 當您存取可下載的內容時，請使用檔案壓縮。 | Azure Front Door 中的壓縮可協助以最佳格式傳遞內容、具有較小的承載，並將內容更快傳遞給使用者。 |
當您在 Azure Front Door 中設定健康情況探查時，請考慮使用 HEAD 要求，而不是 GET 要求。 健康狀態探查只會讀取狀態代碼，而不是內容。 |
HEAD 要求允許您查詢狀態的變更，而不需擷取其完整內容。 |
| 評估當需要將來自相同使用者的請求導向至相同的源伺服器時，是否應啟用 會話親和性。 從可靠性的觀點來看，我們不建議使用此方法。 如果您使用此選項，應用程式應該正常復原，而不會中斷用戶會話。 負載平衡存在取捨，因為這會限制將流量均勻分布到多個來源的靈活性。 |
優化效能並維護使用者會話的持續性，特別是當應用程式依賴在本機維護狀態資訊時。 |
Azure 原則
Azure 提供一組與 Azure Front Door 及其相依性相關的大量內建原則。 您可以透過 Azure 原則稽核上述一些建議。 例如，您可以檢查是否：
- 您需要進階層以支援 Azure Front Door 配置檔中的受控 WAF 規則和 Private Link。
- 您必須使用最低 TLS 版本，也就是 1.2 版。
- 您需要 Azure Front Door Premium 與 Azure PaaS 服務之間的安全、私人連線。
- 您必須啟用資源記錄。 WAF 應該已啟用要求主體檢查。
- 您必須使用原則來強制執行 WAF 規則集。 例如，您應該啟用 Bot 保護，並開啟速率限制規則。
如需全面治理，請檢閱 Azure 內容傳遞網路 和其他 Azure Front Door 原則 內建定義，這些原則列在 Azure 原則內建原則定義。
Azure Advisor 建議
Azure Advisor 是個人化的雲端顧問，可協助您遵循最佳做法來優化 Azure 部署。 顧問的建議與 Well-Architected 框架的支柱一致。
如需詳細資訊，請參閱 Azure Advisor中的建議。
後續步驟
請考慮下列文章做為用來展示本文所強調建議的資源。
- 使用下列參考架構作為如何將本文指引套用至工作負載的範例：
- 使用網路控制 任務關鍵基準
- 使用下列產品檔建置實作專業知識：