本文將回答關於 Azure 應用程式組態的常見問題。
應用程式組態與 Azure Key Vault 有何不同？
應用程式組態可協助開發人員管理應用程式組態及控制功能的可用性。 其目的是要簡化多項處理複雜設定資料的工作。
應用程式組態支援：
- 階層命名空間
- 加上標籤
- 大規模查詢
- 批次擷取
- 特殊化的管理作業
- 功能管理使用者介面
應用程式組態補強了 Key Vault，而這兩者在大部分的應用程式部署中均應並行使用。
我是否應將秘密儲存在應用程式組態中？
雖然應用程式組態可提供更高的安全性，但 Key Vault 仍是儲存應用程式秘密的最佳位置。 Key Vault 可提供硬體層級的加密、精細的存取原則，以及憑證輪替之類的管理作業。
您可以建立應用程式組態索引鍵/值，並使其參考儲存在 Key Vault 中的秘密。 如需詳細資訊，請參閱在 ASP.NET Core 應用程式中使用 Key Vault 參考。
應用程式組態是否會將我的資料加密？
是。 應用程式組態一律加密所有傳輸中和待用資料。 所有網路通訊都是透過 TLS 1.2 或 TLS 1.3 進行。 應用程式組態支援使用 Microsoft 管理的金鑰或客戶自控金鑰進行待用加密。
應用程式組態與 Azure App Service 設定有何不同？
Azure App Service 可讓您定義每個 App Service 執行個體的應用程式設定。 這些設定會以環境變數的形式傳遞至應用程式程式碼。 您可以視需要將設定關聯至特定的部署位置。 如需詳細資訊，請參閱設定應用程式設定。
相對地，Azure 應用程式組態可讓您定義可在多個應用程式之間共用的設定。 這包括在 App Service 及其他平台中執行的應用程式。 您的應用程式程式碼會透過 .NET 和 Java 的設定提供者、透過 Azure SDK，或直接透過 REST API 來存取這些設定。
您可以在 App Service 的應用程式設定中，將參考新增至應用程式設定資料。 您也可以在 App Service 與應用程式設定之間匯入和匯出設定。 這項功能可讓您根據現有的 App Service 設定，快速設定新的應用程式組態存放區。 您也可以與依賴 App Service 設定的現有應用程式共用組態。
在應用程式組態中儲存的金鑰和值是否有任何大小限制？
單一索引鍵值的限制為 10 KB，包括標籤、內容類型、標記和其他中繼資料等屬性。 只要密鑰和標籤的總大小低於記憶體限制，金鑰和標籤數量就沒有限制。
此索引鍵/值限制應該足以用於大部分應用程式中的單一設定。 如果您發現您的設定大於此限制，您可以考慮將資料儲存在其他地方，並在應用程式組態中新增該資料的參考。
如需完整的限制清單，請參閱 Azure 訂用帳戶和服務限制。
如何儲存多個環境 (測試、預備、生產等) 的組態？
您可以在個別存放區層級控制可存取應用程式組態的人員。 對於需要不同權限的個別環境，請使用個別的存放區。 此方法可提供最佳安全隔離性。
如果您的環境之間不需要安全隔離性，您可以使用標籤來區分設定值。 使用標籤為不同環境啟用不同的設定會提供完整範例。
使用應用程式組態的建議方法為何？
請參閱最佳做法。
應用程式組態的成本為何？
有四個定價層：免費、開發人員、標準和進階。 如需詳細的定價資訊，請參閱應用程式組態定價頁面。
我應使用何種應用程式組態層？
所有應用程式組態層都提供核心功能，包括組態設定、功能旗標、Key Vault 參考、設定快照集、基本管理作業、計量和記錄。
以下是選擇階層時的考量。
目的：免費層非常適合在非生產環境中評估服務，讓您不需任何成本即可探索其功能。
開發人員層針對低量、非生產使用案例具有成本效益，並配備了專為開發和測試需求量身打造的特色和功能。
標準層是針對中型生產和非生產使用案例所設計，可提供效能與成本效益的平衡。
針對大量或企業級的生產需求，進階層提供最高層級的效能和延展性，以確保您的應用程式即使在負載過重的情況下也能順暢地執行。
每一訂用帳戶的資源：資源是由單一設定存放區所組成。 每個訂用帳戶在免費層中的每個區域中只能有一個設定存放區。 訂用帳戶在開發人員、標準和進階層中可以有無限數量的組態存放區。
每一資源的儲存體：在免費層中，每個設定存放區的一般儲存體上限為 10 MB，以及快照集儲存體上限為 10 MB。 在開發人員層中，每個設定存放區最多可以使用 500 MB 的一般記憶體，以及額外的 500 MB 快照集記憶體。 在標準層中，每個設定存放區最多可以使用 1 GB 的一般儲存體，以及額外 1 GB 的快照集儲存體。 在進階層中，每個設定存放區最多可以使用 4 GB 的一般儲存體，以及額外 4 GB 的快照集儲存體。
修訂歷程記錄：應用程式組態會儲存對金鑰所做之所有變更的歷程記錄。 在免費和開發人員層中，此歷程記錄會儲存七天。 在標準和進階層中，此歷程記錄會儲存 30 天。
要求配額：免費層存放區限定為每日 1,000 個要求。 存放區在到達 1,000 要求時，會針對所有要求傳回 HTTP 狀態碼 429，直到午夜 (UTC) 為止。
開發人員層存放區限制為每小時 6,000 個要求。 一旦每小時配額用盡，其他要求會傳回 HTTP 狀態代碼 429，表示要求太多，直到一小時結束為止。
標準層存放區限定為每小時 30,000 個要求。 一旦每小時配額用盡，其他要求可能會傳回 HTTP 狀態碼 429 指出「太多要求」，直到該小時結束為止。 當傳送超過配額的要求數目時，較高的百分比可能會傳回狀態碼 429。
進階層存放區對要求沒有配額限制，以確保永遠不會封鎖對存放區的存取。
輸送量：儲存在所有階層中的 Azure 應用程式組態都有輸送量允許額度。 超過此額度的要求會收到 HTTP 狀態代碼 429 回應。
免費層和開發人員層中的存放區不保證輸送量。
標準層中的存放區允許執行速率†每秒最多 300 個讀取要求 （RPS），以及寫入要求最多 60 個 RPS。
進階層中的存放區允許執行速率†讀取要求最多 450 RPS，寫入要求最多 100 RPS。
†執行速率通常會測量為 應用程式組態 存放區處理的要求平均數目，而不會在指定的期間內進行節流。
服務等級協議：免費層和開發人員層沒有 SLA。 標準層的 SLA 有 99.9% 的可用性，且在啟用異地複寫時有 99.95% 的可用性。 進階層的 SLA 有 99.9% 的可用性，且在啟用異地複寫時有 99.99% 的可用性。
功能：所有層都含有功能，包括使用 Microsoft 管理的金鑰加密、透過存取金鑰或 Microsoft Entra ID 進行驗證、Azure 角色型存取控制 (RBAC)、受控識別、服務標籤和可用性區域備援。
開發人員層也包含 Private Link 的支援。
標準和進階層提供更多功能，包括 Private Link 支援、使用客戶自控金鑰加密、虛刪除保護，以及異地複寫功能。
費用：使用免費層存放區不會產生任何費用。
開發人員層存放區有每日使用量費用，其中包含每天前3,000個要求。 超過此每日配置的要求會產生超額費用。
標準層存放區有每日使用量費用，其中包括每天的前 200,000 個要求。 超過此每日配置的要求會產生超額費用。
進階層存放區也有每日使用量費用，並且包含複本。 原始來源的前 800,000 個要求和每天針對複本的前 800,000 個要求會包含在每日費用中。 超過此每日配置的要求會產生超額費用。
我可以升級或降級應用程式組態存放區嗎？
例如，您可以隨時將應用程式組態存放區升級至開發人員、標準層或進階層，或從開發人員、標準層升級至進階層。
您可以將應用程式組態存放區從進階層降級為標準層，因為這兩個層都是針對生產使用而設計的。 不過，不支持降級至非生產層，例如免費層。 若要達成此目的，您可以在所需的層中建立新的存放區，然後將 組態數據匯入該存放區。
將應用程式組態存放區從進階層降級至標準層之前，請確定您一般記憶體和快照集記憶體的使用低於標準層的限制。 您可以透過 Azure 入口網站中應用程式組態存放區的 Azure 監視器計量、每日記憶體使用量和快照集記憶體大小來驗證目前的使用量。
儲存在應用程式組態中的資料位於何處？
儲存在應用程式組態中的客戶資料位於客戶的應用程式組態存放區建立所在的區域中。 只有當客戶啟用 該區域的異地複 寫時，客戶數據才會復寫到另一個區域。 這適用於所有可用的區域。 客戶可以從全球各地移動、複製或存取其資料。
應用程式組態如何確保高度的資料可用性？
Azure 應用程式組態支援異地複寫，以增強區域性中斷的復原能力。
Azure 應用程式組態支援 Azure 可用性區域，以保護您的應用程式和資料不受單一資料中心失敗的影響。 所有已啟用可用性區域的區域都包含至少三個可用性區域，其中每個區域都是實體獨立的數據中心。 為確保復原功能，對於所有客戶都會在應用程式組態中啟用這項支援，且不額外收費。 以下是應用程式設定已啟用可用性區域支援的區域。 如需詳細資訊，請參閱具有可用性區域支援的 Azure 區域。
下列是應用程式組態已啟用可用性區域支援的區域。
| 美洲 | 歐洲 | 中東 | 非洲 | 亞太地區 |
|---|---|---|---|---|
| 巴西南部 | 法國中部 | 卡達中部 | 澳大利亞東部 | |
| 加拿大中部 | 義大利北部 | 阿拉伯聯合大公國北部 | 印度中部 | |
| 美國中部 | 德國中西部 | 以色列中部 | 日本東部 | |
| 美國東部 | 北歐 | 南韓中部 | ||
| 美國東部 2 | 挪威東部 | 東南亞 | ||
| 美國中南部 | 英國南部 | 東亞 | ||
| US Gov 維吉尼亞州 | 西歐 | 中國北部 3 | ||
| 美國西部 2 | 瑞典中部 | |||
| 美國西部 3 | 瑞士北部 | |||
| 墨西哥中部 | 波蘭中部 | |||
| 西班牙中部 |
對應用程式組態提出的要求數目是否有所限制？
Azure 應用程式組態存放區會根據其層級有不同的要求配額。 免費層存放區限制為每天 1,000 個要求，開發人員層儲存至每小時 6,000 個要求，標準層存放區每小時 30,000 個要求，而進階層存放區沒有要求限制，確保不會中斷存取。
Azure 應用程式組態存放區會根據其層級有不同的輸送量額度。 免費層和開發人員層存放區不保證輸送量。 標準層存放區支援每秒最多 300 個讀取作業的要求執行速率，以及寫入作業最多 60 個 RPS。 進階層存放區支援讀取作業最多 450 RPS 的執行速率，以及寫入作業最多 100 個 RPS。
如何估計應用程式可能會傳送至應用程式組態的要求數量？
舉例來說，假設您的應用程式有 1,000 個組態設定。 您的應用程式會在啟動時從應用程式組態載入所有這些設定。 之後，它會每隔 30 秒檢查 Sentinel 金鑰是否發生設定變更。 無論您是在 Kubernetes、App Service 或 VM 上執行，我們假設您有 50 個應用程式實例同時執行。
首先，讓我們估計設定監視的要求數。 應用程式的每個實例每 30 秒都會傳送一個 sentinel 密鑰的要求* 至應用程式組態，因此它會在一小時內傳送 120 個 （=3600/30） 要求。 假設您有 50 個應用程式執行個體，您的應用程式會每小時總計傳送 6,000 (=120x50) 個要求，以進行設定監視。 請注意，由於 sentinel 密鑰要求頻繁且大部分未變更，因此大部分要求不會計入標準層存放區的每小時配額限制†。
接著，讓我們估計設定載入/重新載入的要求數。 您的應用程式會在啟動時或在偵測到 sentinel 金鑰變更時載入所有設定。 每個要求 應用程式組態 最多可以擷取 100 個索引鍵/值，因此載入所有設定需要 10 個 （=1000/100） 個要求。 假設您有 50 個應用程式執行個體，當您的應用程式重新啟動或重新載入設定時，會傳送總計 500 (=10x50) 個要求。
最後，讓我們將這些要求結合在一起。 假設您在一小時內更新 sentinel 金鑰兩次，您的應用程式組態存放區就會在該小時收到總計 7,000 (=6,000+500x2) 個要求。 請注意，在這些要求中，只有大約 1,000 個 （=500x2） 要求會使用標準層存放區的每小時可用配額。 更新此範例中的數位，以符合您的特定設定和設計，因此您有足夠的緩衝區來符合每小時配額限制。
*功能旗標不會使用 sentinel 密鑰來監視變更，而且會與組態分開監視。 每一次重新整理間隔需要一個要求來監視每100個功能旗標。
†Free 層存放區沒有從每日限制中排除的重複要求。
我的應用程式收到 HTTP 狀態碼 429 回應。 為什麼？
在下列情況下，您的應用程式可能會收到 HTTP 狀態碼 429 回應:
- 超過免費層中存放區的每日要求限制。
- 超過開發人員層中市集的每小時要求配額。
- 超過標準層中存放區的每小時要求限制。
- 超過任何層級中存放區的輸送量額度。
- 超過任何層級中存放區的頻寬額度。
- 在超出儲存空間配額時，嘗試建立或修改關鍵值。
請檢查 429 回應的本文，找出要求失敗的特定原因。 您也可以收集 Azure 監視器中應用程式組態存放區的記錄，並設定 [要求配額使用量] 計量的警示。
接收暫時的 HTTP 狀態代碼 429 回應通常不會造成任何傷害，因為 Azure 應用程式組態用戶端會正常處理它們。 但是，如果您的應用程式經常遇到 HTTP 狀態碼 429 回應，請考慮以下選項:
- 將您的存放區升級至進階層：此層對要求沒有配額限制，而且已增加記憶體配額和更高的輸送量額度。
- 使用 Azure 應用程式組態提供者: 提供者具有內建的重試和快取功能，以及許多其他復原功能。 請務必更新為最新版的提供者，以取得所有最新的增強功能。
- 如果您的應用程式需要傳送寫入要求，請使用 Azure 應用程式組態 SDK。 雖然 SDK 可能不像提供者那樣豐富功能，但它們會自動重試 HTTP 狀態代碼 429 回應和其他暫時性錯誤。
- 如果您無法使用 Azure 應用程式組態提供者或 SDK，請在自訂用戶端中包含重試邏輯。 回應中的
retry-after-ms標頭會提供重試要求前的建議等待時間 (以毫秒為單位)。 - 將要求散發到多個用戶端執行個體: 這有助於達到 Azure 應用程式組態存放區的最大輸送量。
- 減少對 Azure 應用程式組態提出的要求: 請遵循指引來最小化要求數目。
- 改善應用程式復原: 請考慮整合異地復寫以允許容錯移轉和負載平衡。 參閲最佳做法以建置具有高復原能力的應用程式。
為何我無法建立與我剛刪除的應用程式組態存放區同名的應用程式組態存放區？
標準和進階層中的所有應用程式組態存放區都會自動啟用虛刪除功能。 標準或進階層的應用程式組態存放區在刪除後，其名稱會依保留期間進行保留。 若要在保留期間到期之前重新建立具有相同名稱的存放區，您必須先清除虛刪除的存放區，前提是該存放區未啟用清除保護。 如果有啟用清除保護，您必須等候保留期間結束。 如果您經常需要重新建立具有相同名稱的存放區，請使用清除功能或設定較短的保留期間。 需要重建同名存放區的工作流程，應該允許在清除設定存放區和執行後續建立之間間隔一小時。 這項建議已生效，因為一旦要求清除，就會以非同步方式確實清除設定存放區資源，因此需要一些額外的時間才能完成。 為了避免等待，建議建立暫時設定存放區的工作流程應使用唯一名稱。
如何還原我誤刪的應用程式組態存放區？
我是否可以程式設計方式建立和更新功能旗標或金鑰保存庫參考？
是。 雖然您可透過 Azure 入口網站 或 CLI 在應用程式組態中管理功能旗標和金鑰保存庫參考，但您也可以使用應用程式組態 SDK，以程式設計方式建立和更新它們。 因此，您可以撰寫自訂的管理入口網站，或以程式設計方式在 CI/CD 中管理。 功能旗標和金鑰保存庫參考 API 適用於所有支援語言的 SDK。 請參閱範例連結，以取得每種支援語言的範例。
在應用程式中評估和取用功能旗標需要應用程式組態提供者和功能管理程式庫，這些程式庫適用於 .NET 和 Java Spring。 如需詳細資訊，請參閱「快速入門」和「教學課程」底下的「功能管理」一節。
如何在 Azure 應用程式組態利用 Java 短期衝刺設定檔？
短期衝刺設定檔提供方法分隔應用程式各部分 (包含設定)，並使其僅在特定環境或當利用特定程式庫時可用。
建議您將索引鍵值的標籤設定為與 Spring 設定檔一致。 根據預設，如果未明確設定標籤篩選，則 應用程式組態 Spring 提供者連結庫會載入索引鍵/值，且標籤符合目前作用中的 Spring 設定檔（s） （${spring.profiles.active}） 。 若無使用中的 Spring 設定檔集，則會載入「無標籤」索引鍵值。
例如，對於設定檔dev與prod，您可利用以下標籤建立相應索引鍵值。
| 機碼 | 標籤 | 值 |
|---|---|---|
| /application/config.message | 開發 | 開發部門向您問好 |
| /application/config.message | 產品 | 產品部門向您問好 |
當短期衝刺設定檔設定為dev時，config.message的值將為Hello from dev。 當短期衝刺設定檔設定為prod時，config.message的值將為Hello from prod。
您可在啟動程式檔案設定標籤篩選條件來覆寫這個預設行為。 不論使用中的 Spring 設定檔為何，Spring 提供者連結庫都會載入具有指定標籤的索引鍵/值。
spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label
若要選取其他標籤與您的 Spring 設定檔，您可利用類似 ',${spring.profiles.active}' 的標籤篩選，這將選取所有不含標籤的索引鍵，以及與 Spring 設定檔一致的索引鍵。 當找到重複的索引鍵時，最右側的標籤會優先處理。
如何在 Blazor 應用程式中啟用功能管理，或在 .NET 應用程式中啟用範圍服務？
從 3.1.0 版開始，Microsoft.FeatureManagement 程式庫允許執行功能管理服務 (包括功能篩選) 做為相依性插入式 .NET 應用程式中的範圍服務。 若要利用這項功能，您可以直接將程式碼中的 AddFeatureManagement 呼叫取代為 AddScopedFeatureManagement，如下列程式碼片段所示：
services.AddScopedFeatureManagement();
功能篩選可以根據 HTTP 要求的屬性來評估功能旗標。 執行方式通常是透過單一 HttpContextIHttpContextAccessor 來檢查 。 不過，此模式不適用於 應該改用範圍服務的 Blazor 伺服器應用程式 。 在此情況下，應該使用 AddScopedFeatureManagement 方法。
如何接收應用程式組態的新版發行公告和其他相關資訊？
訂閱我們的 GitHub 公告存放庫。
如何回報問題或提供建議？
您可以直接在 GitHub 與我們聯繫。