任務關鍵性 Web 應用程式的全域路由備援
任務關鍵性系統會盡可能在解決方案中建置備援和自我修復功能，努力將單一失敗點降到最低。 系統的任何統一進入點都可以視為失敗點。 如果此元件發生中斷，整個系統將會離線給使用者。 選擇路由服務時，請務必考慮服務本身的可靠性。
在任務關鍵性應用程式的基準架構中，已選擇 Azure Front Door，因為它的高運行時間服務等級協定（SLA）和豐富的功能集：
- 將流量路由傳送至主動-主動模型中的多個區域
- 使用 TCP 任何廣播的透明故障轉移
- 使用整合式內容傳遞網路從邊緣節點提供靜態內容（CDN）
- 使用整合式 Web 應用程式防火牆封鎖未經授權的存取
Front Door 的設計目的是為外部客戶提供最大的復原能力和可用性，也提供跨Microsoft的多個屬性。 如需 Front Door 功能的詳細資訊，請參閱 使用 Azure Front Door 加速和保護 Web 應用程式。
Front Door 功能已足夠滿足大部分的商務需求，不過，任何分散式系統都預期失敗。 如果商務需求在中斷時需要較高的複合 SLO 或零停機時間，您必須依賴替代的流量輸入路徑。 不過，追求較高的 SLO 會產生顯著的成本、營運額外負荷，並可降低整體可靠性。 請仔細考慮 替代路徑在重要路徑的其他元件中可能會引入的取 捨和潛在問題。 即使無法使用的影響很重要，複雜度可能超過優點。
其中一種方法是定義次要路徑，其中具有替代服務，只有在 Azure Front Door 無法使用時才會變成作用中。 與 Front Door 的功能同位不應被視為硬式需求。 排定您絕對需要商務持續性用途的功能優先順序，甚至可能以有限的容量執行。
另一種方法是使用第三方技術進行全域路由。 此方法需要多雲端主動-主動部署，且戳記裝載於兩個或多個雲端提供者。 雖然 Azure 可以有效地與其他雲端平臺整合，但不建議使用此方法，因為不同雲端平臺的作業複雜度。
本文說明一些使用 Azure 流量管理員 作為替代路由器的全域路由策略，在 Azure Front Door 無法使用的情況下。
方法
此架構圖顯示具有多個備援流量路徑的一般方法。
透過這種方法，我們將引進數個元件，並提供指引，以對 Web 應用程式的傳遞進行重大變更：
Azure 流量管理員 將流量導向至 Azure Front Door 或您選取的替代服務。
Azure 流量管理員 是以 DNS 為基礎的全域負載平衡器。 網域的 CNAME 記錄會指向 流量管理員，這會根據您設定其路由方法的方式決定目的地。 根據預設，使用 優先順序路由 會讓流量流經 Azure Front Door。 如果無法使用 Azure Front Door，流量管理員 會自動將流量切換至替代路徑。
重要
此解決方案可降低與 Azure Front Door 中斷相關的風險，但很容易 Azure 流量管理員 中斷作為全域失敗點。
您也可以考慮使用不同的全域流量路由系統，例如全域負載平衡器。 不過，流量管理員 適用於許多情況。
您有兩個輸入路徑：
Azure Front Door 提供主要路徑和進程，並路由傳送所有應用程式流量。
另一個路由器會作為 Azure Front Door 的備份。 如果 Front Door 無法使用，流量只會流經此次要路徑。
您為次要路由器選取的特定服務取決於許多因素。 您可以選擇使用 Azure 原生服務或第三方服務。 在這些文章中，我們提供 Azure 原生選項，以避免將額外的作業複雜度新增至解決方案。 如果您使用第三方服務，則必須使用多個控制平面來管理您的解決方案。
您的源應用程式伺服器必須準備好接受來自任一服務的流量。 請考慮如何 保護來源的流量，以及 Front Door 和其他上游服務所提供的責任。 請確定您的應用程式可以處理流量從流量流經的路徑。
取捨
雖然此風險降低策略可讓應用程式在平臺中斷期間可供使用，但有一些顯著的取捨。 您應該根據已知成本來權衡潛在的權益，並做出明智的決定，瞭解這些優點是否值得這些成本。
財務成本：當您將多個備援路徑部署到應用程式時，您必須考慮部署和執行資源的成本。 我們針對不同的使用案例提供兩個範例案例，每個案例都有不同的成本配置檔。
作業複雜度：每次您將其他元件新增至解決方案時，都會增加管理額外負荷。 對某個元件的變更可能會影響其他元件。
假設您決定使用 Azure Front Door 的新功能。 您需要檢查替代流量路徑是否也提供對等的功能，如果不是，您必須決定如何處理兩個流量路徑之間行為的差異。 在真實世界中，這些複雜度可能會有很高的成本，而且可能會對系統的穩定性造成重大風險。
效能：此設計需要在名稱解析期間進行額外的 CNAME 查閱。 在大部分應用程式中，這不是一個重大問題，但您應該評估您的應用程式效能是否受到將其他層引入輸入路徑的影響。
商機成本： 設計和實作備援輸入路徑需要大量工程投資，這最終將帶來特徵開發和其他平臺改進的機會成本。
警告
如果您不小心設計及實作複雜的高可用性解決方案，實際上可能會讓可用性變得更糟。 增加架構中的元件數目會增加失敗點的數目。 這也表示您擁有較高層級的作業複雜度。 當您新增額外的元件時，必須仔細檢閱您所做的每項變更，以瞭解它如何影響您的整體解決方案。
Azure 流量管理員的可用性
Azure 流量管理員 是可靠的服務，但服務等級協定並不保證 100% 的可用性。 如果 流量管理員 無法使用，使用者可能無法存取您的應用程式，即使 Azure Front Door 和替代服務都可供使用。 請務必規劃解決方案在這些情況下繼續運作的方式。
流量管理員 傳回可快取的 DNS 回應。 如果 DNS 記錄上的存留時間 （TTL） 允許快取，則 流量管理員 短暫中斷可能並不重要。 這是因為下游 DNS 解析程式可能已快取先前的回應。 您應該規劃長時間中斷。 如果 流量管理員 無法使用，您可以選擇手動重新設定 DNS 伺服器，將使用者導向 Azure Front Door。
流量路由一致性
請務必瞭解您使用和依賴的 Azure Front Door 功能和功能。 當您選擇替代服務時，請決定所需的最低功能，並在解決方案處於降級模式時省略其他功能。
規劃替代流量路徑時，您應該考慮下列一些關鍵問題：
- 您是否使用 Azure Front Door 的快取功能？ 如果快取無法使用，您的源伺服器能否跟上流量？
- 您是否使用 Azure Front Door 規則引擎來執行自定義路由邏輯，或重寫要求？
- 您是否使用 Azure Front Door Web 應用程式防火牆 （WAF） 來保護您的應用程式？
- 您是否根據IP位址或地理位置限制流量？
- 誰發出並管理您的 TLS 憑證？
- 如何限制對源應用程式伺服器的存取，以確保其能透過 Azure Front Door 取得？ 您是否使用 Private Link，或依賴具有服務標籤和標識碼標頭的公用 IP 位址？
- 您的應用程式伺服器是否接受來自 Azure Front Door 以外的任何位置的流量？ 如果他們這樣做，他們接受哪些通訊協定？
- 您的用戶端是否使用 Azure Front Door 的 HTTP/2 支援？
Web 應用程式防火牆 (WAF)
如果您使用 Azure Front Door 的 WAF 來保護您的應用程式，請考慮流量未通過 Azure Front Door 時會發生什麼情況。
如果您的替代路徑也提供 WAF，請考慮下列問題：
- 是否可以以與 Azure Front Door WAF 相同的方式進行設定？
- 是否需要獨立微調和測試，以減少誤判偵測的可能性？
警告
您可以選擇不要將 WAF 用於替代輸入路徑。 此方法可視為支援應用程式的可靠性目標。 不過，這不是一個很好的做法，我們不建議您這麼做。
請考慮在接受來自因特網的流量時取捨，而不需要進行任何檢查。 如果攻擊者探索到應用程式未受保護的次要流量路徑，即使主要路徑包含WAF，也可能透過次要路徑傳送惡意流量。
最好保護 應用程式伺服器的所有路徑 。
功能變數名稱和 DNS
您的任務關鍵性應用程式應該使用自定義功能變數名稱。 您將控制流量流向應用程式的方式，並減少單一提供者的相依性。
針對您的功能變數名稱使用高品質且具彈性的 DNS 服務，例如 Azure DNS 也是很好的作法。 如果您的功能變數名稱 DNS 伺服器無法使用，使用者就無法連線到您的服務。
建議您使用多個 DNS 解析程序，進一步提高整體復原能力。
CNAME 鏈結
結合 流量管理員、Azure Front Door 和其他服務的解決方案會使用多層 DNS CNAME 解析程式，也稱為 CNAME 鏈結。 例如，當您解析自己的自定義網域時，您可能會在傳回IP位址之前看到五筆以上的 CNAME 記錄。
將其他連結新增至 CNAME 鏈結可能會影響 DNS 名稱解析效能。 不過，通常會快取 DNS 回應，以減少效能影響。
TLS 憑證
對於任務關鍵性應用程式，建議您布建並使用自己的 TLS 憑證，而不是 Azure Front Door 所提供的受控憑證。 您將減少此複雜架構的潛在問題數目。
以下是一些優點：
若要發出並更新受控 TLS 憑證，Azure Front Door 會驗證網域的擁有權。 網域驗證程序假設網域的 CNAME 記錄直接指向 Azure Front Door。 但是，這種假設通常不正確。 在 Azure Front Door 上發行和更新受控 TLS 憑證可能無法順利運作，而且您因 TLS 憑證問題而增加中斷的風險。
即使您的其他服務提供受控 TLS 憑證，它們可能無法驗證網域擁有權。
如果每個服務獨立取得自己的受控 TLS 憑證，可能會發生問題。 例如，使用者可能不會預期看到不同授權單位所簽發的不同 TLS 憑證，或有不同的到期日或指紋。
不過，在憑證到期之前，將會有其他與更新憑證相關的作業。
原始安全性
當您 將來源 設定為只接受透過 Azure Front Door 的流量時，您會獲得第 3 層和第 4 層 DDoS 攻擊的保護。 由於 Azure Front Door 只會回應有效的 HTTP 流量，因此也有助於減少您接觸許多通訊協定型威脅的風險。 如果您變更架構以允許替代輸入路徑，則必須評估是否不小心增加來源暴露在威脅的風險。
如果您使用 Private Link 從 Azure Front Door 連線到源伺服器，流量會如何流經您的替代路徑？ 您可以使用私人IP位址來存取您的來源，還是必須使用公用IP位址嗎？
如果您的來源使用 Azure Front Door 服務標籤和 X-Azure-FDID 標頭來驗證流量已流經 Azure Front Door，請考慮如何重新設定您的來源，以驗證流量是否已流經您的其中一個有效路徑。 您必須測試您並未不小心將來源開啟至透過其他路徑的流量，包括來自其他客戶的 Azure Front Door 配置檔。
當您規劃原始安全性時，請檢查替代流量路徑是否依賴布建專用的公用IP位址。 這可能需要手動觸發的程式，才能讓備份路徑上線。
如果有專用的公用IP位址，請考慮您是否應實 作 Azure DDoS 保護 ，以降低針對來源的阻斷服務攻擊風險。 此外，請考慮您是否需要實作 Azure 防火牆 或其他防火牆，以防範各種網路威脅。 您可能還需要更多入侵檢測策略。 這些控制件可以是更複雜的多重路徑架構中的重要元素。
健康情況模型
任務關鍵性設計方法需要系統 健康情況模型 ，以提供解決方案及其元件的整體可觀察性。 當您使用多個流量輸入路徑時，您必須監視每個路徑的健康情況。 如果您的流量重新路由傳送至次要輸入路徑，您的健康情況模型應該反映系統仍在運作，但處於降級狀態的事實。
在您的健康情況模型設計中包含這些問題：
- 解決方案的不同元件如何監視下游元件的健康情況？
- 健康情況監視器何時應該將下游元件視為狀況不良？
- 偵測到中斷需要多久的時間？
- 偵測到中斷之後，流量需要多久時間才能透過替代路徑路由傳送？
有多個全域負載平衡解決方案可讓您監視 Azure Front Door 的健康情況，並在發生中斷時觸發自動故障轉移至備份平臺。 Azure 流量管理員 在大部分情況下都適用。 使用 流量管理員，您可以指定要檢查的 URL、檢查該 URL 的頻率，以及何時根據探查回應考慮下游服務狀況不良，來設定端點監視以監視下游服務。 一般而言，檢查間隔越短，流量管理員 透過替代路徑引導流量到達源伺服器所花費的時間越短。
如果 Front Door 無法使用，則多個因素會影響中斷影響流量的時間量，包括：
- DNS 記錄上的存留時間（TTL）。
- 流量管理員 執行其健康情況檢查的頻率。
- 在重新路由傳送流量之前，流量管理員 設定為要查看的失敗探查數目。
- 用戶端和上游 DNS 伺服器快取 流量管理員 DNS 回應的時間長度。
您也需要判斷控件內的哪些因素，以及超出控件的上游服務是否會影響用戶體驗。 例如，即使您在 DNS 記錄上使用低 TTL，上游 DNS 快取可能仍會提供過期回應的時間超過預期。 此行為可能會加劇中斷的影響，或讓應用程式似乎無法使用，即使 流量管理員 已切換至將要求傳送至替代流量路徑也一樣。
提示
任務關鍵性解決方案需要盡可能的自動化故障轉移方法。 手動故障轉移程式會被視為緩慢，以便讓應用程式保持回應。
請參閱：任務關鍵性設計區域： 健康情況模型
零停機部署
當您規劃如何使用備援輸入路徑操作解決方案時，您也應該規劃如何在服務降級時部署或設定服務。 對於大部分的 Azure 服務，SLA 適用於服務本身的運行時間，而不是管理作業或部署。 請考慮您的部署和設定程式是否需要針對服務中斷進行復原。
您也應該考慮需要與其互動的獨立控制平面數目，以管理您的解決方案。 當您使用 Azure 服務時，Azure Resource Manager 會提供統一且一致的控制平面。 不過，如果您使用第三方服務來路由傳送流量，您可能需要使用不同的控制平面來設定服務，這會帶來進一步的作業複雜度。
警告
使用多個控制平面會對您的解決方案帶來複雜度和風險。 每個差異點都會增加有人不小心錯過組態設定的可能性，或將不同的組態套用至備援元件。 請確定您的作業程式可降低此風險。
請參閱：任務關鍵性設計區域： 零停機部署
持續驗證
針對任務關鍵性解決方案，您的測試做法必須確認您的解決方案是否符合您的需求，而不論應用程式流量流經的路徑為何。 請考慮解決方案的每個部分，以及如何針對每種中斷類型進行測試。
請確定您的測試程式包含下列元素：
- 當主要路徑無法使用時，您是否能夠正確地透過替代路徑重新導向流量？
- 這兩個路徑都可以支援您預期要接收的生產流量層級嗎？
- 這兩個路徑是否受到適當保護，以避免在您處於降級狀態時開啟或公開弱點？
請參閱：任務關鍵性設計區域： 持續驗證
常見場景
以下是可以使用此設計的常見案例：
全域內容傳遞 通常適用於靜態內容傳遞、媒體和大規模電子商務應用程式。 在此案例中，快取是解決方案架構的重要部分，而快取失敗可能會導致效能或可靠性大幅降低。
全域 HTTP 輸入 通常適用於任務關鍵性動態應用程式和 API。 在此案例中，核心需求是可靠且有效率地將流量路由傳送至源伺服器。 WAF 通常是在這些解決方案中使用的重要安全性控制件。
警告
如果您不小心設計及實作複雜的多輸入解決方案，實際上可能會讓可用性變得更糟。 增加架構中的元件數目會增加失敗點的數目。 這也表示您擁有較高層級的作業複雜度。 當您新增額外的元件時，必須仔細檢閱您所做的每項變更，以瞭解它如何影響您的整體解決方案。
下一步
檢閱全域 HTTP 輸入和全域內容傳遞案例，以瞭解它們是否適用於您的解決方案。