任務關鍵性應用程式需要在網路元件無法使用或性能下降時，依然能維持高可用的運行正常時間。 當您設計 Web 流量輸入、路由和安全性時，可以考慮結合多個 Azure 服務來達到更高的可用性層級，並避免發生單一失敗點。
Microsoft為 Azure Front Door 提供領先業界的服務等級協定（SLA）。 即使另一個提供者提供 100% 運行時間 SLA，請務必注意，這無法保證零停機，且 SLA 通常會在發生中斷時提供服務積分。 因此，即使是Microsoft的競爭對手也建議針對任務關鍵性工作負載使用多個輸入路徑。
如果您決定採用這種方法，則必須對應用程式伺服器實作個別的網路路徑，而且每個路徑都必須個別設定及測試。 您必須仔細考慮此方法的完整含意。
本文說明透過 Azure Front Door 和 Azure 應用程式閘道支援全域 HTTP 流量輸入的方法。 如果您的解決方案需要，此方法可能會符合您的需求：
- 適用於全域流量路由的 Azure Front Door。 這可能表示您在個別的 Azure 區域中有多個應用程式實例，或是從單一區域為所有全域使用者提供服務。
- Web 應用程式防火牆 （WAF） 可保護您的應用程式，不論流量遵循的路徑如何到達您的源伺服器。
網路邊緣的快取並不是您應用程式傳遞的關鍵部分。 如果快取很重要，請參閱具有關鍵性使命的全域內容傳遞以尋找替代方法。
備註
此使用案例是整體設計策略的一部分，涵蓋 Azure Front Door 無法使用時的替代方法。 如需內容和考慮的相關信息，請參閱 任務關鍵全域 Web 應用程式。
方法
此 DNS 型負載平衡解決方案會使用多個 Azure 流量管理員配置檔。 在 Azure Front Door 出現不太可能的可用性問題時，Azure Traffic Manager 會透過應用程式網關改道流量。
解決方案包含下列元件：
使用優先順序路由模式的流量管理員 有兩個 端點。 根據預設，流量管理員會透過 Azure Front Door 傳送要求。 如果無法使用 Azure Front Door，第二個流量管理員設定檔會決定要導向要求的位置。 第二個配置檔如下所述。
Azure Front Door 會處理並路由傳送大部分的應用程式流量。 Azure Front Door 會將流量路由傳送至適當的源應用程式伺服器，並提供應用程式的主要路徑。 Azure Front Door 的 WAF 可保護您的應用程式免於常見的安全性威脅。 如果無法使用 Azure Front Door，流量會自動透過次要路徑重新導向。
使用效能路由模式的流量管理員 具有每個應用程式閘道實例的端點。 此流量管理員會根據用戶端位置選擇性能最佳的應用程式閘道實例來傳送要求。
應用程式閘道 會部署到每個區域，並將流量傳送至該區域內的源伺服器。 應用程式閘道的 WAF 可保護流經次要路徑的任何流量。
您的源應用程式伺服器 必須隨時準備好接受來自 Azure Front Door 和 Azure 應用程式閘道的流量。
考慮事項
下列各節說明這種類型的架構的一些重要考慮。 當您在任務關鍵性解決方案中使用 Azure Front Door 時，也應該檢閱 任務關鍵性全域 Web 應用程式 以取得其他重要考慮和取捨。
流量管理員設定
此方法會使用 巢狀流量管理員配置檔 ，針對應用程式的替代流量路徑，同時達成優先順序型和效能型路由。 在一個起源於單一地區的簡單案例中，您可能只需要設定一個使用優先路由的流量管理服務配置檔。
區域分佈
Azure Front Door 是全域服務，而應用程式閘道則是區域服務。
Azure Front Door 的存在據點會全域部署，TCP 和 TLS 連線會在最接近用戶端的存在據點終止。 此行為可改善應用程式的效能。 相反地，當用戶端連線到應用程式閘道時，其 TCP 和 TLS 聯機會在接收要求的應用程式網關終止，而不論流量來自何處。
來自客戶端的連線
作為全球多租用戶服務，Azure Front Door 會針對各種威脅提供固有的保護。 Azure Front Door 只接受有效的 HTTP 和 HTTPS 流量，而且不接受其他通訊協定上的流量。 Microsoft管理 Azure Front Door 用於其輸入連線的公用 IP 位址。 由於這些特性，Azure Front Door 有助於 保護您的來源免於各種攻擊類型，而且您的來源可以 設定為使用 Private Link 連線。
相反地，應用程式閘道是具有專用公用IP位址的因特網對應服務。 您必須保護您的網路和源伺服器，以防止各種攻擊類型。 如需詳細資訊，請參閱來源安全性。
來源伺服器的私人連結連線
Azure Front Door Premium 提供 Private Link 連接至您的來源，以減少解決方案的公用網際網路暴露面。
如果您使用 Private Link 連線到您的來源，請考慮將私人端點部署到您的虛擬網路，並將應用程式閘道設定為使用私人端點作為應用程式的後端。
縮放
當您部署應用程式閘道時，會自動部署專用的計算資源，以支援應用程式閘道實例的作業。 如果大量流量意外抵達應用程式閘道，您可能會發現效能或可靠性問題。
若要降低此風險，請考慮如何 調整應用程式閘道實例。 使用自動調整，或確定您已手動調整規模，以處理故障轉移後可能收到的流量量。
緩存
如果您使用 Azure Front Door 的快取功能，請務必注意，當您的流量切換至替代路徑並使用應用程式閘道之後，就不會再從 Azure Front Door 快取提供內容。
如果您依賴於解決方案的快取，請參閱 任務關鍵性全域內容傳遞 ，以使用替代內容傳遞網路 （CDN） 作為 Azure Front Door 的後援之另類方法。
或者，如果您使用快取，但它並不是您應用程式交付策略的核心部分，考慮是否可以擴展或提升來源，以應對因故障轉移導致快取未命中次數增加而引發的額外負載。
取捨
如果您希望替代流量路徑使用要求處理規則、WAF 和 TLS 卸除等功能，這種架構最有用。 Azure Front Door 和應用程式閘道都提供類似的功能。
不過，有取捨：
作業複雜度。 當您使用上述任何功能時，您必須在 Azure Front Door 和應用程式閘道上設定這些功能。 例如，如果您對 Azure Front Door WAF 進行組態變更，您也必須將相同的組態變更套用至應用程式閘道 WAF。 當您需要重新設定及測試兩個不同的系統時，作業複雜度會變得更高。
功能同位。 雖然 Azure Front Door 和應用程式閘道所提供的功能之間有相似之處，但許多功能並沒有完全同位。 請注意這些差異，因為它們可能會影響根據應用程式所遵循的流量路徑來傳遞應用程式的方式。
應用程式閘道不提供快取。 如需這項差異的詳細資訊，請參閱 快取。
Azure Front Door 和應用程式閘道是不同的產品，而且有不同的使用案例。 特別是 ，這兩個產品在部署到 Azure 區域的方式上有所不同。 請確定您瞭解每個產品的詳細數據，以及其使用方式。
成本。 您通常需要將應用程式閘道實例部署到您擁有來源的每個區域。 由於每個應用程式閘道實例都會個別計費，因此當您將來源部署到數個區域時，成本可能會變得很高。
如果成本是您解決方案中的重要因素，請參閱任務關鍵性全域內容傳遞，該方法使用另一個內容傳遞網絡（CDN）作為 Azure Front Door 的備援。 某些CDN會以耗用量為基礎計費流量，因此這種方法可能更具成本效益。 不過，您可能會失去將應用程式閘道用於解決方案的一些其他優點。
或者，您可以考慮部署替代架構，其中流量管理員可以將流量直接路由傳送至平臺即服務 （PaaS） 應用程式服務，避免需要應用程式網關並降低成本。 如果您針對解決方案使用 Azure App Service 或 Azure Container Apps 之類的服務，則可以考慮此方法。 不過，如果您遵循此方法，請考慮幾個重要的取捨：
- WAF： Azure Front Door 和應用程式閘道都提供 WAF 功能。 如果您將應用程式服務直接公開至因特網，可能無法使用WAF保護應用程式。
- TLS 卸載： Azure Front Door 和應用閘道器皆終止 TLS 連線。 您的應用程式服務必須設定為終止 TLS 連線。
- 路由： Azure Front Door 和應用程式閘道都會跨多個來源或後端執行路由，包括路徑型路由，並支援複雜的路由規則。 如果您的應用程式服務會直接公開至因特網，則無法執行流量路由。
警告
如果您考慮將應用程式直接公開至因特網，請建立徹底的威脅模型，並確保架構符合您的安全性、效能和復原需求。
如果您使用虛擬機來裝載解決方案，則不應該將虛擬機公開至因特網。
貢獻者們
本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。
主要作者：
- 戴夫·伯克哈特 |Azure Front Door 的主要計劃管理員
- John Downs |首席軟體工程師
- Priyanka Wilkins |主要內容開發人員
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。
後續步驟
檢閱 全域內容傳遞 案例，以瞭解其是否適用於您的解決方案。