共用方式為

任務關鍵全域 HTTP 輸入

  • 發行項

任務關鍵性應用程式需要維持高層級的執行時間，即使網路元件無法使用或降級亦然。 當您設計 Web 流量輸入、路由和安全性時，可以考慮結合多個 Azure 服務來達到較高的可用性層級，並避免發生單一失敗點。

如果您決定採用這種方法，您必須對應用程式伺服器實作個別的網路路徑，而且每個路徑都必須個別設定及測試。 您必須仔細考慮此方法的完整含意。

本文說明透過 Azure Front Door 和Azure 應用程式閘道支援全域 HTTP 流量輸入的方法。 如果您的解決方案需要，此方法可能會符合您的需求：

  • 適用于全域流量路由的 Azure Front Door。 這可能表示您在個別的 Azure 區域中有多個應用程式實例，或者您為單一區域的所有全域使用者提供服務。
  • Web 應用程式防火牆 (WAF) 來保護您的應用程式，而不論流量遵循的路徑如何連線到源伺服器。

在網路邊緣快取不是應用程式傳遞的重要部分。 如果快取很重要，請參閱替代方法 的任務關鍵全域內容傳遞 。

注意

此使用案例是整體設計策略的一部分，涵蓋 Azure Front Door 無法使用時的替代方法。 如需內容和考慮的相關資訊，請參閱 任務關鍵全域 Web 應用程式。

方法

此 DNS 型負載平衡解決方案會使用多個 Azure 流量管理員設定檔來監視 Azure Front Door。 在可用性問題不太可能發生的情況下，流量管理員會透過應用程式閘道重新導向流量。

此圖顯示優先順序路由至 Azure Front Door 的 Azure 流量管理員，以及使用效能路由傳送至兩個區域中應用程式閘道實例的巢狀流量管理員設定檔。

解決方案包含下列元件：

  • 使用優先順序路由模式的流量管理員 有兩個 端點。 根據預設，流量管理員會透過 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 服務 或 Azure Container Apps，則可以考慮此方法。 不過，如果您遵循此方法，需要考慮幾個重要的取捨：

    • WAF：Azure Front Door 和應用程式閘道都提供 WAF 功能。 如果您將應用程式服務直接公開至網際網路，可能無法使用 WAF 保護應用程式。
    • TLS 卸載：Azure Front Door 和 應用程式閘道兩者都會終止 TLS 連線。 您的應用程式服務必須設定為終止 TLS 連線。
    • 路由：Azure Front Door 和 應用程式閘道跨多個來源或後端執行路由，包括路徑型路由，並支援複雜的路由規則。 如果您的應用程式服務直接公開至網際網路，您就無法執行流量路由。

警告

如果您考慮將應用程式直接公開至網際網路，請建立徹底的威脅模型，並確保架構符合您的安全性、效能和復原需求。

如果您使用虛擬機器來裝載解決方案，就不應該將虛擬機器公開至網際網路。

下一步

檢閱 全域內容傳遞 案例，以瞭解其是否適用于您的解決方案。