Azure 應用程式組態集中儲存和管理應用程式設定與功能旗標，取代直接嵌入應用程式中的設定檔。 透過這種方式，你可以動態更新組態值、追蹤版本歷史，並隨時維護組態變更的紀錄。 應用程式設定的可用性與可靠性是重要考量，因為應用程式行為可能直接依賴於執行時對設定資料的存取。
使用Azure時，可靠性是共同責任。 Microsoft 提供一系列功能以支援韌性與復原。 您有責任瞭解這些功能在您使用的所有服務中如何運作，並選取符合業務目標和正常運作時間目標所需的功能。
本文說明應用程式配置的可靠性架構，以及服務如何設計以在瞬態故障、可用性區域故障及區域中斷時保持可用。
可靠性的生產部署建議
對於大多數 App Configuration 的生產部署，請考慮以下建議：
SKU： 使用標準或高級 SKU。
軟刪除與清除保護： 開啟軟刪除和清除保護，幫助防止資料刪除。
針對關鍵任務情境： 使用高級 SKU 並設定附帶的副本能跨多個區域複製。 此方法提升了對區域中斷的高可用性與韌性。
關於生產工作負載的推薦實務與配置清單，請參見 建構具有高韌性的應用程式。
可靠性架構概觀
當你部署 App Configuration 時，你是在部署 一個儲存庫。 你的商店包含各種應用程式可能使用的設定，包括 鍵與值，以及 功能旗標。 服務還內建組織、保護、版本管理及安全推送各環境設定變更的功能。 欲了解更多資訊，請參閱 「什麼是應用程式設定？」
App Configuration 是一個完全受管理的服務。 Microsoft 負責對服務進行維護，並儲存和管理您的設定。
當你建立連接 App Configuration 的客戶端應用程式時，可以選擇
對瞬態故障的彈性
暫時性錯誤是元件中的短暫間歇性失敗。 它們經常出現在雲端等分散式環境中，而且是作業的一般部分。 暫時性錯誤會在短時間內自行修正。 請務必確保您的應用程式能妥善處理暫時性錯誤，通常透過重試受影響的請求來進行。
所有雲端託管應用程式在與任何雲端託管的 API、資料庫及其他元件通訊時，都應遵循 Azure 暫態故障處理指引。 如需詳細資訊，請參閱 處理暫時性錯誤的建議。
使用應用程式設定時，請考慮以下最佳實務，以減少暫時錯誤對配置存取的影響，尤其是在關鍵程式碼路徑中。
配置提供者： 使用具備內建重試與快取功能及其他韌性功能的 應用程式設定服務提供者。
Azure SDK： 如果你的應用程式需要發送寫入請求，請使用 App Configuration SDK。 SDK 會自動重試 HTTP 狀態碼 429 回應及其他暫態錯誤。
重試邏輯： 如果你無法使用應用程式設定服務提供者或 SDK，可以在自訂客戶端中加入重試邏輯。
retry-after-ms回應中的標頭會提供建議的等待時間（以毫秒為單位），客戶端才會重新嘗試請求。快取： 如果可能的話，將快取設定放在記憶體中，以減少直接請求到你的商店。
其他應用程式設定指引，請參閱 應用程式設定常見問題。
對可用性區域故障的抵抗力
可用性區域是Azure區域內物理上獨立的資料中心群組。 當某個區域發生故障時，服務可以切換至其他剩餘的區域。
應用程式設定會自動在 支援可用性區域的區域中提供區域冗餘。 此備援可在區域內提供高可用性，而不需要任何特定設定。
圖示顯示可用區間1、2和3。 App Configuration store 涵蓋該地區內所有三個區段。
當某個可用區域無法使用時，App Configuration 會自動將您的請求導向到其他健康的可用區域，以確保高可用性。
需求
區域支援： 部署到以下區域的服務自動具備區域冗餘。
| 美洲 | 歐洲 | 中東 | 非洲 | 亞太地區 |
|---|---|---|---|---|
| 巴西南部 | 法國中部 | 以色列中部 | Australia East | |
| 加拿大中部 | 德國中西部 | 卡達中部 | 印度中部 | |
| 美國中部 | 義大利北部 | 阿拉伯聯合大公國北部 | 中國北部 3 | |
| 美國東部 | 北歐 | 東亞 | ||
| 美國東部 2 | 挪威東部 | 日本東部 | ||
| 墨西哥中部 | 波蘭中部 | 南韓中部 | ||
| 美國中南部 | 西班牙中部 | 東南亞 | ||
| US Gov 維吉尼亞州 | 瑞典中部 | |||
| 美國西部 2 | 瑞士北部 | |||
| 美國西部 3 | 英國南部 | |||
| 西歐 |
費用
App Configuration 的區域冗餘不需要額外費用。
設定可用性區域支援
當商店位於支援可用區域的地區時，Microsoft 會自動配置區域冗餘。
如果應用程式設定在現有區域新增可用性區支援，你不需要採取任何行動就能享受可用性區的支援。 您的商店受益於区域內 App Configuration 商店新推出的可用性區域支援。
所有區域都狀況良好時的行為
本節說明當你擁有區域冗餘的應用程式設定儲存庫，且所有區域皆正常運作時，會遇到什麼情況。
跨區作業： 應用程式設定會自動管理可用性區間的流量路由。 在正常操作期間，它會透明地將請求分散到不同區域。
跨可用性區域資料複製： 在支援可用性區域的地區，App Configuration 會同步複製資料跨可用性區域。 這種複製確保即使區域無法使用，你的設定也能保持一致且可用。
區域失敗期間的行為
本節將描述當你擁有一個區域冗餘的應用程式配置商店時，遭遇其中一個區域故障時的預期情況。
- 偵測與回應： 應用程式組態服務會偵測區域故障並自動回應。 在區域失敗期間，您不需要採取任何動作。
- Notification： Microsoft 不會自動通知你區域關閉。 不過，你可以使用 Azure 服務健康狀態 來了解服務整體健康狀況，包括任何區域故障，並且可以設定 Service Health 警示來通知你問題。
作用中要求：在區域失敗期間，受影響的區域可能無法處理即時要求，這需要用戶端應用程式重試這些要求。 用戶端應用程式應遵循 暫時性錯誤處理做法 ，以確保在發生區域失敗時可以重試要求。
預期的數據遺失： 由於區域之間的同步復寫，區域失敗期間不會有任何數據遺失。
預期的停機時間： 預計不會有停機。
重新劃分： 應用程式設定會自動將流量從受影響區域重新導向健康區域，無需客戶介入。
區域復原
當先前無法使用的區域恢復時，App Configuration 會自動恢復所有可用區域的正常操作。 你不需要採取任何行動來從區域故障中恢復。
測試區域失敗
應用程式配置平台負責管理區域冗餘儲存的流量路由、故障轉移及區域恢復。 Microsoft 完全管理這個流程，所以你不需要驗證可用性區的故障流程。
對區域範圍故障的復原能力
App Configuration 提供原生的地理複製功能，以支援區域中斷時的韌性。 地理複製允許設定資料作為管理服務功能跨區域複製。
地理複製
透過地理複製，你可以在多個 Azure 區域複製一個儲存裝置。 每個商店可以在不同地區擁有多個 副本 。 原始商店也是複製品。 此能力有助於保護應用免受區域性干擾。
需求
Region support： 你可以在 App Configuration 支援的任何Azure區域建立副本，即使這些區域不是Azure配對的區域。
等級： 設定儲存必須使用支援的層級才能啟用地理複製。 欲了解更多資訊，請參閱 啟用地理複製。
考慮事項
當您啟用異地複寫時，請考慮下列因素：
區域冗餘複製品： 只要你在 App Configuration 支援可用性區域的區域建立副本，都會自動成為區域冗餘。
Azure Front Door： 要啟用與 Azure Front Door 的地理冗餘配置交付，請將 App Configuration 複本設為來源群組中的來源。 Azure Front Door 需要正確設定的起源節點，才能執行基於健康狀態的路由、負載平衡及跨區域自動故障轉移。 欲了解更多資訊，請參閱 「流量路由方法至起點」。
費用
每個地理複製區域依照相應層級與區域的價格獨立收費。 跨區域複製不收取資料出口費用。 欲了解價格細節，請參閱 應用程式設定定價。
設定多區域支援
若要設定新建立的組態儲存的複製，請參見 啟用地理複製。
當所有區域都正常時的行為
本節說明在設定應用程式組態儲存以進行地理複製時，所有區域皆已運作時，應期待的情況。
跨區作業： 每個副本皆可獨立尋址，並擁有自己的網域名稱系統（DNS）名稱。 所有副本都能接受讀寫操作。
App Configuration 不會自動將流量路由到不同區域。 當你使用 App Configuration 配置提供者 時，你的應用程式可以選擇使用自動副本發現功能。 或者，你可以指定一個優先排序的副本清單，App Configuration 會選擇第一個健康的副本。 此方法使應用程式能控制所使用的複本。
備註
如果你用 Azure Front Door，流量路由行為會不同。 欲了解更多資訊，請參見 故障轉移與負載平衡。
跨區域資料複製： 資料以非同步方式複製，最終保持一致。 你可以在 Azure 監視器 中使用
複製延遲指標來監控副本間目前的複製延遲。
區域失敗期間的行為
本節說明當您設定應用程式組態儲存庫進行地理複製時，當某個副本區域發生故障時，可以預期的情況。
Detection and Response： Microsoft 負責偵測區域或複本的故障並啟動復原程序。
當你使用具備自動副本發現或多個副本清單的 App Configuration 配置提供者時，應用程式會自動偵測故障並切換到健康的副本。
如果您不使用 App Configuration 服務提供者，您需要負責將應用程式切換到健全的複製體。
Notification： Microsoft 不會自動通知你區域故障。 不過，你可以使用 Azure 服務健康狀態 來了解整體服務的健康狀況，包括任何區域故障，並且可以設定 Service Health alerts 來通知你問題。
目前的請求： 針對該區域副本的主動請求可能會失敗。 用戶端應用程式應該對不同的副本重新嘗試請求。
預期資料遺失： 如果一個副本失敗，該副本最近所做的變更可能還無法複製到其他副本。 這些變更可以在複製品恢復前保持不可用。 要估算潛在的資料遺失，請監控Azure 監視器<>的
複製延遲指標。 預期的停機時間： 當複本無法使用時，該副本會保持離線狀態，直到其區域恢復。 其他副本繼續處理請求。 應用程式可能會短暫停機，直到偵測故障並切換到健康的副本。 持續時間取決於每個應用程式執行此偵測與故障轉移的速度。
重新劃分： 應用程式在發生故障時必須將流量導向健康的複本。
如果你使用 App Configuration 提供者，這些提供者會自動處理副本選擇與故障轉移。
如果你把Azure Front Door放在資料儲存庫前，並配置多個副本作為故障轉移的來源群組，Azure Front Door 會自動將請求重新導向健康的副本。
區域復原
區域恢復後，App Configuration 會自動將副本與其他副本同步，無需你介入。
你負責重新設定應用程式，將流量路由回已恢復的區域實例。 使用 App Configuration Provider 的應用程式會自動重新開始使用該複本。
區域故障測試
你無法直接在 App Configuration 模擬副本故障切換。 然而，由於應用程式控制副本選擇，你可以透過強制應用程式進入必須切換副本的狀態來測試故障轉移行為。
為了驗證應用程式的複本故障轉移行為，可以在非生產環境中引入受控連線故障，觀察應用程式的反應。
一種方法是使用你的本機或其他你擁有管理員權限的環境。 執行下列步驟:
開啟 Azure SDK 的詳細記錄。 在.NET中，使用
AzureEventSourceListener類別來設定記錄器。 如需詳細資訊，請參閱記錄和監視。手動設定你的
hosts檔案，讓申請到應用程式組態儲存庫的請求會被路由到無法接收的 IP 位址，比如127.0.0.1（localhost）。警告
此步驟實際上阻擋了電腦對應用程式設定商店的存取。 只有在非生產環境下才會遵循這些步驟。
監控日誌中是否有類似以下範例的訊息：
[Warning] Microsoft-Extensions-Configuration-AzureAppConfiguration-Refresh: Failed to get configuration settings from endpoint 'https://myappconfigstore.azconfig.io'. Failing over to endpoint https://myappconfigstore-eus.azconfig.io'.應用程式成功切換到使用你商店的另一個副本時，會顯示此訊息。
完成測試後，將
hosts的變更還原。
備份與還原
你可以使用 App Configuration 從儲存 庫匯出設定資料 ，並將其作為更廣泛備份策略的一部分使用。
針對大部分的解決方案，您不應該只依賴備份。 請改用本指南中所述的其他功能來支持復原需求。 不過，備份可防範其他方法未發生的一些風險。 欲了解更多資訊，請參閱冗餘、複寫與備份是什麼？
對意外刪除的韌性
應用程式配置提供兩項關鍵的復原功能，以防止意外或惡意刪除：
軟刪除： 當你開啟軟刪除時，可以在可設定的保留期間恢復已刪除的儲存和設定。 軟刪除的功能就像是應用程式設定資源的回收筒。
清除防護： 當你開啟清除保護時，服務會防止商店及其設定被永久刪除，直到保留期限結束。 此防護措施防止惡意行為者永久破壞您的設定。
在生產環境中同時使用這兩個功能。 更多資訊請參見 軟刪除與清除保護。
服務維護的韌性
Microsoft 定期進行服務更新及其他維護。 服務會自動處理這些工作，讓維護對您來說順暢且透明。 除非Azure 服務健康狀態提供計畫性維護通知，否則維修期間不會有停機。
對配置問題的韌性
錯誤或意外的設定變更可能導致應用程式停機。 使用 設定快照 來安全地推送設定變更。 在設定變更後監控應用程式健康狀況，若變更帶來問題，則回退到最後已知良好狀態的設定快照。
服務等級協定
Azure 服務的服務層級協議（SLA）描述了每項服務的預期可用性，以及您的解決方案必須符合的條件，以達成該可用性預期。 欲了解更多資訊，請參閱線上服務的 SLA。