任務關鍵性系統會盡可能在解決方案中建置備援和自我修復功能，努力將單一失敗點降到最低。 系統的任何統一進入點都可以視為失敗點。 如果此元件發生中斷，整個系統將對使用者而言處於離線狀態。 選擇路由服務時，請務必考慮服務本身的可靠性。
在 關鍵任務應用程式的架構中，Azure Front Door 因其高運作時間服務等級協議（SLA）及豐富的功能集而被選中：
- 將流量路由至多個區域，採用主動-主動或主動-被動模式
- 使用 TCP 任播的透明故障轉移
- 使用整合式內容傳遞網路從邊緣節點提供靜態內容（CDN）
- 使用整合式 Web 應用程式防火牆封鎖未經授權的存取
如需 Azure Front Door 功能的詳細資訊，請參閱 使用 Azure Front Door 加速和保護 Web 應用程式。
Azure Front Door 的設計目的是不僅為我們的外部客戶，還為 Microsoft 的多個服務提供最強的復原能力和可用性。 Azure Front Door 的功能已足夠滿足大部分的業務需求，但在任何分散式系統中，都應預期可能的失敗。 沒有元件或系統無法運作。 Microsoft為 Azure Front Door 提供領先業界的服務等級協定（SLA）。 即使供應商提供 100% 的正常運作時間 SLA，也不保證完全沒有停機時間。 SLA通常會在停電時提供服務積分。
如果業務需求需要更高的複合 SLO 或在中斷時零停機時間，則需要依賴多個替代流量輸入路徑。 許多大型組織和高調的 Web 屬性都使用這種方法，以確保最高的可用性，並優化傳遞效能。 然而，追求更高的 SLO 會帶來相當高的成本、營運負擔，且可能無意間降低整體可靠性。 仔細考慮替代路徑可能引入的權衡及其可能影響其他元件的問題，這些元件位於關鍵路徑上。 即使不可用性的影響很重大，複雜性可能超過其益處。
一種方法是定義一條次要路徑，並搭配替代服務，當 Azure Front Door 不可用時，該路徑成為主要路徑。 與 Azure Front Door 的功能同位不應被視為硬式需求。 將您絕對需要的功能進行優先排序，以確保業務持續運作，甚至可能以有限的運作能力來運行。
有多種策略可達成網頁工作負載的高可用性。 此處說明的方法提供一種直接的手動「破碎玻璃解決方案」，讓您能在停電期間快速切換，並在服務健康確認後無縫恢復 Azure Front Door 的流量。
本文說明了一些使用 Azure Traffic Manager 進行全域路由的策略，以便在 Azure Front Door 無法使用時，將流量導向替代路由器。
方法
此架構圖顯示具有多個備援流量路徑的一般方法。
透過這種方法，我們將引進數個元件，並提供指引，以對 Web 應用程式的傳遞進行重大變更：
Azure 流量管理員 會將流量導向至 Azure Front Door 或您選取的替代服務。
Azure 流量管理員是以 DNS 為基礎的全域負載平衡器。 網域的 CNAME 記錄會指向流量管理員，這會根據您設定其 路由方法的方式來決定目的地。 對於關鍵任務架構，我們建議使用 加權 路由方法，該方法可輕鬆配置，將部分或全部流量傳送至不同端點。 通常在正常營運中，有 100% 流量會經過 Azure Front Door。
我們建議您關閉 Traffic Manager 的端點監控功能。 你應該有程序來 偵測主流量路徑無法使用，並透過 切換流量以使用次要路徑作為回應。
你也可以考慮使用不同的全球流量路由系統。 不過，流量管理器在許多情況下運作良好。
您有兩個輸入路徑：
Azure Front Door 提供主要路徑。 在正常運作中，它會處理並路由全部或大部分的應用程式流量。
另一個路由器會作為 Azure Front Door 的備份。 如果前門無法使用，交通會經過這條次要通道。
您為次要路由器選取的特定服務取決於許多因素。 您可以選擇使用 Azure 原生服務或第三方服務。 在這些文章中，我們會盡可能提供 Azure 原生選項，以避免將額外的作業複雜度新增至解決方案。 如果您使用第三方服務，則必須使用多個控制平面來管理您的解決方案。
您的源應用程式伺服器必須準備好接受來自任一服務的流量。 請考慮如何 保護來源的流量，以及 Azure Front Door 和其他上游服務所提供的功能。 確保您的應用程式能夠處理從任何途徑流入的流量。
取捨
雖然此風險降低策略可讓應用程式在平臺中斷期間可供使用，但有一些顯著的取捨。 您應該根據已知成本來權衡潛在的權益，並做出明智的決定，瞭解這些優點是否值得這些成本。
財務成本：當您將多個備援路徑部署到應用程式時，您必須考慮部署和執行資源的成本。 我們針對不同的使用情境提供兩個範例，每個情境都有不同的成本結構。
作業複雜度：每次您將其他元件新增至解決方案時，都會增加管理額外負荷。 對一個元件的任何變更都可能影響其他元件。
假設您決定使用 Azure Front Door 的新功能。 您需要檢查替代流量路徑是否也提供對等的功能，如果不是，您必須決定如何處理兩個流量路徑之間行為的差異。 在真實世界中，這些複雜度可能會有很高的成本，而且可能會對系統的穩定性造成重大風險。
效能：此設計需要在名稱解析期間進行額外的 CNAME 查閱。 在大部分應用程式中，這不是一個重大問題，但您應該評估您的應用程式效能是否受到將其他層引入輸入路徑的影響。
機會成本： 設計和實作冗餘輸入路徑需要大量工程投資，這最終會以特徵開發和其他平台改進的機會成本為代價。
警告
如果您不小心設計及實作複雜的高可用性解決方案，實際上可能會讓可用性變得更糟。 增加架構中的元件數目會增加失敗點的數目。 這也表示您擁有較高層級的作業複雜度。 當您新增額外的元件時，必須仔細檢閱您所做的每項變更，以瞭解它如何影響您的整體解決方案。
Azure 流量管理員的可用性
Azure 流量管理員是一項可靠的服務，具有 領先業界的 SLA，但流量管理需要額外的措施來提供 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，也可能透過次要路徑傳送惡意流量。
最好將所有通往應用程式伺服器的路徑加以保護。
高可用性的其他考慮
當您設計任務關鍵性 Web 架構時，有許多因素可能會影響應用程式的可用性和效能。 這些因素有許多超出 Azure Front Door 設定和功能，而是與整體生態系統和解決方案設計相關。
網域名稱和 DNS
您的任務關鍵性應用程式應使用自訂網域名稱來控制流量流向應用程式的方式，並減少對單一提供者的依賴。 規劃 DNS 策略時請考慮以下幾點：
DNS 服務： 使用高品質且具韌性的網域名稱 DNS 服務（例如 Azure DNS）是個好做法。 如果您的域名的 DNS 伺服器無法使用，使用者將無法連接到您的服務。
DNS 解析器： 我們建議您使用多個 DNS 解析器，以進一步提升整體韌性。
Apex 網域： 你使用 CNAME 來將你的網域名稱指向 Traffic Manager 網域名稱。 DNS 標準不允許你在網域的頂點（或根節點）建立 CNAME。 我們建議將你的 DNS 網域放在 Azure DNS 上，並使用 Alias 紀錄 來指向你的流量管理員設定檔。
CNAME 鏈接：結合 Traffic Manager、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 流量管理員都適合使用。
當你使用 Traffic Manager 搭配 Azure Front Door 時，你應該有自己的監控、第三方或自訂監控解決方案，來偵測 Azure Front Door 是否無法使用，並啟動回應流程。 由於 Azure Front Door 是使用任播網路的全域分散式系統，因此請務必從與用戶端相同的地理區域內執行連線檢查。
這很重要
對於需要多地理區域健康驗證的全球工作負載，我們建議關閉 Traffic Manager 端點監控，改用手動故障轉移程序。
如果您的監控系統未檢測到，您應該準備好手動啟動應變程序。
回應程序
如果您的監控系統偵測到 Azure Front Door 無法使用，您需要重新設定流量管理器，透過替代路徑導向所有流量，您可以使用以下方法之一來完成此操作：
如果您手動偵測到中斷： 在流量管理員設定檔中手動停用端點。 如需詳細步驟，請參閱 新增、停用、啟用、刪除或移動端點。
自訂或使用第三方監控工具： 你可以預先建立自動回應計畫，透過程式化重新配置流量管理器以停用端點，方法如下：
az network traffic-manager endpoint update \ --resource-group MyRG \ --profile-name MyProfile \ --name MyEndpoint \ --type externalEndpoints \ --endpoint-status Disabled如需詳細資訊，請參閱 az network traffic-manager endpoint update。
這很重要
將所有流量重新導向次要路徑，是一種短期解決方案，能在持續停電時維持業務連續性。 解決中斷之後，請儘快透過 Azure Front Door 還原正常作業。
中斷對流量影響的時間長短受到多種因素影響，包括：
- DNS 記錄上的存留時間（TTL）。
- 哪個監視系統 （流量管理員或您自己的自訂監視） 會先偵測中斷。
- 健康檢查的頻率。
- 在重新路由流量之前，必須傳回多少個失敗的運作狀態檢查。
- 用戶端和上游 DNS 伺服器快取 Traffic Manager 的 DNS 回應的時間長度。
您還需要判斷哪些因素是您能控制的，以及不在您控制範圍內的上游服務是否會影響用戶體驗。 例如，即使您在 DNS 記錄中使用低 TTL，上游 DNS 快取仍然可能比預期時間更久地提供過期回應。 即使流量管理員已切換至將要求傳送至替代流量路徑，此行為可能會加劇中斷的影響，或讓應用程式似乎無法使用。
小提示
任務關鍵性解決方案需要盡可能的自動化故障轉移方法。 手動故障移轉程序被認為過於緩慢，使應用程式難以保持回應。
請參閱： 任務關鍵性設計區域：健康情況模型
韌性重組過程
當你規劃如何操作有冗餘入口路徑的解決方案時，也應該規劃服務在退化時如何部署或配置。 對於大部分的 Azure 服務，SLA 適用於服務本身的運行時間，而不是管理作業或部署。 請考慮您的部署和配置流程是否需要具有彈性，以應對服務中斷。
當你規劃故障轉移策略時，不要依賴像 Azure 入口網站這樣的單一工具，以防連線中斷。 了解如何使用 Azure CLI、Azure PowerShell 或 REST API 等工具來執行重新設定步驟，例如重新路由流量。 欲查看可在備用轉移腳本中包含的範例指令，請參閱 回應程序。
您也應該考慮需要與其互動的獨立控制平面數目，以管理您的解決方案。 當您使用 Azure 服務時，Azure Resource Manager 會提供統一且一致的控制平面。 不過，如果您使用第三方服務來路由傳送流量，您可能需要使用不同的控制平面來設定服務，這會帶來進一步的作業複雜度。
警告
使用多個控制平面會對您的解決方案帶來複雜度和風險。 每個差異點都會增加有人不小心錯過組態設定的可能性，或將不同的組態套用至備援元件。 請確定您的作業程式可降低此風險。
請參閱： 任務關鍵性設計區域：零停機部署
持續驗證
針對任務關鍵性解決方案，您的測試做法必須確認您的解決方案是否符合您的需求，而不論應用程式流量流經的路徑為何。 請考慮解決方案的每個部分，以及如何針對每種中斷類型進行測試。
請確定您的測試程式包含下列元素：
- 當主要路徑無法使用時，您是否能夠正確地透過替代路徑重新導向流量？
- 這兩個路徑都可以支援您預期要接收的生產流量層級嗎？ 次要路徑是否準備好接收生產流量，且幾乎或完全沒有預警？
- 這兩個路徑是否受到適當保護，以避免在您處於降級狀態時開啟或公開弱點？
請參閱： 任務關鍵性設計區域：持續驗證
常見場景
以下是可以使用此設計的常見案例：
全域內容傳遞 通常適用於靜態內容傳遞、媒體和大規模電子商務應用程式。 在此案例中，快取是解決方案架構的重要部分，而快取失敗可能會導致效能或可靠性大幅降低。
全域 HTTP 輸入 通常適用於任務關鍵性動態應用程式和 API。 在此案例中，核心需求是可靠且有效率地將流量路由傳送至源伺服器。 WAF 通常是在這些解決方案中使用的重要安全性控制件。
警告
如果您在設計和實作複雜的多入口解決方案時不夠謹慎，實際上可能會讓系統的可用性變得更糟。 增加架構中的元件數目會增加失敗點的數目。 這也表示您擁有較高層級的作業複雜度。 當您新增額外的元件時，必須仔細檢閱您所做的每項變更，以瞭解它如何影響您的整體解決方案。
貢獻者們
本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。
主要作者：
- 戴夫·伯克哈特 |Azure Front Door 的主要計劃管理員
- John Downs |Azure 模式和實務的主要軟體工程師
- 阿基爾·卡爾馬爾卡 | Azure Front Door 首席計畫經理
- 普里揚卡·威爾金斯 |Azure 模式與做法的主要內容開發人員
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。
後續步驟
檢閱本系列的下一篇文章，以獲得有關這些情境的具體指導：