Azure 應用程式組態常見問題集

應用程式組態可協助開發人員管理應用程式組態及控制功能的可用性。 其目的是要簡化多項處理複雜設定資料的工作。

應用程式組態支援：

• 階層命名空間
• 加上標籤
• 大規模查詢
• 批次擷取
• 特殊化的管理作業
• 功能管理使用者介面

應用程式組態補強了 Key Vault，而這兩者在大部分的應用程式部署中均應並行使用。

雖然應用程式組態可提供更高的安全性，但 Key Vault 仍是儲存應用程式秘密的最佳位置。 Key Vault 可提供硬體層級的加密、精細的存取原則，以及憑證輪替之類的管理作業。

您可以建立應用程式組態索引鍵/值，並使其參考儲存在 Key Vault 中的秘密。 如需詳細資訊，請參閱在 ASP.NET Core 應用程式中使用 Key Vault 參考。

是。 應用程式組態一律加密所有傳輸中和待用資料。 所有網路通訊都是透過 TLS 1.2 或 TLS 1.3 進行。 應用程式組態支援使用 Microsoft 管理的金鑰或客戶自控金鑰進行待用加密。

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。 在標準層中，每個設定存放區最多可以使用 1 GB 的一般儲存體，以及額外 1 GB 的快照集儲存體。

• 修訂歷程記錄：應用程式組態會儲存對金鑰所做之所有變更的歷程記錄。 在免費層中，此歷程記錄會儲存七天。 在標準層中，此歷程記錄會儲存 30 天。

• 要求配額：免費層存放區限定為每日 1,000 個要求。 存放區在到達 1,000 要求時，會針對所有要求傳回 HTTP 狀態碼 429，直到午夜 (UTC) 為止。

  標準層存放區限定為每小時 30,000 個要求。 一旦每小時的配額用盡，要求可能會傳回 HTTP 狀態碼 429 指出「太多要求」，直到該小時結束為止。 當傳送超過配額的要求數目時，較高的百分比可能會傳回狀態碼 429。

• 服務等級協定：標準層的 SLA 有 99.9% 的可用性，且在啟用異地複寫時有 99.95% 的可用性。 免費層沒有 SLA。

• 功能：這兩個層都含有功能，包括使用 Microsoft 管理的金鑰加密、透過存取金鑰或 Microsoft Entra ID 進行驗證、Azure 角色型存取控制 (RBAC)、受控識別、服務標籤和可用性區域備援。 標準層提供更多功能，包括 Private Link 支援、使用客戶自控金鑰加密、虛刪除保護，以及異地複寫功能。

• 成本：標準層存放區有每日使用量費用。 每日的前 200,000 要求會包含在每日費用中。 超過每日配置的要求也會產生超額費用。 使用免費層存放區不會產生任何費用。

您可以隨時從免費層升級至標準層。

您無法將存放區從標準層降級至免費層。 您可以在免費層建立新的存放區，然後將組態資料匯入該存放區中。

儲存在應用程式組態中的客戶資料位於客戶的應用程式組態存放區建立所在的區域中。 只有在客戶啟用該區域的異地複寫時，客戶資料才會複寫到另一個區域。 這適用於所有可用的區域。 客戶可以從全球各地移動、複製或存取其資料。

Azure 應用程式組態支援異地複寫，以增強區域性中斷的復原能力。

Azure 應用程式組態支援 Azure 可用性區域，以保護您的應用程式和資料不受單一資料中心失敗的影響。 所有已啟用可用性區域的區域都包含至少 3 個可用性區域，其中每個區域都是實體獨立的資料中心。 為確保復原功能，對於所有客戶都會在應用程式組態中啟用這項支援，且不額外收費。 以下是應用程式設定已啟用可用性區域支援的區域。 如需詳細資訊，請參閱 Azure 中的區域和可用性區域。

下列是應用程式組態已啟用可用性區域支援的區域。

免費層的組態存放區限定為每天 1,000 個要求。 當要求速率超過每小時 30,000 個要求時，標準層的設定存放區可能會遇到暫時性的節流。

當存放區達到標準層的限制時，可能會針對某些要求傳回 HTTP 狀態碼 429，直到那一小時結束時為止。 回應中的 retry-after-ms 標頭會提供重試要求前的建議等待時間 (以毫秒為單位)。

如果您的應用程式定期收到 HTTP 狀態碼 429 回應，請考慮重新設計以減少提出的要求數目。 如需詳細資訊，請參閱如何減少對應用程式組態提出的要求。

在下列情況下，您將會收到 HTTP 狀態碼 429 回應：

• 超過免費層存放區的每日要求限制。
• 超過標準層存放區的每小時要求限制。
• 由於要求†暴增，而造成暫時節流。
• 因頻寬使用量過高而暫時節流†。
• 嘗試在超出儲存體配額時建立或修改金鑰。

請檢查 429 回應的本文，找出要求失敗的特定原因。

†如果設定存放區收到大量要求或傳送超量資料，則設定存放區可能會暫時節流。 應用程式組態用戶端，例如 Azure SDK、組態提供者程式庫和 Azure Pipelines 工作，會針對節流要求自動重試。 對於任何使用這些用戶端的應用程式，或針對節流要求重試的自訂用戶端，此暫時節流應不會被察覺，且應發生。

舉例來說，假設您的應用程式有 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) 個要求會使用可用的每小時配額。 更新此範例中的數字，以符合您的特定設定並據此設計，讓您可以對每小時的節流限制有足夠的緩衝區。 如需詳細資訊，請參閱如何減少對應用程式組態提出的要求。

†免費層存放區沒有從每日限制中排除頻繁、重複的要求。

標準層中的所有應用程式組態存放區都會自動啟用虛刪除功能。 標準層的應用程式組態存放區在刪除後，其名稱會依保留期間進行保留。 若要在保留期間到期之前重新建立具有相同名稱的存放區，您必須先清除虛刪除的存放區，前提是該存放區未啟用清除保護。 如果有啟用清除保護，您必須等候保留期間結束。 如果您經常需要重新建立具有相同名稱的存放區，請使用清除功能或設定較短的保留期間。 需要重建同名存放區的工作流程，應該允許在清除設定存放區和執行後續建立之間間隔一小時。 這項建議已生效，因為一旦要求清除，就會以非同步方式確實清除設定存放區資源，因此需要一些額外的時間才能完成。 為了避免等待，建議建立暫時設定存放區的工作流程應使用唯一名稱。

標準層中的所有應用程式組態存放區都支援虛刪除功能，此功能無法停用。 您可以在保留期間內復原已刪除的存放區。 請遵循這些指示復原誤刪的應用程式組態存放區。

是。 雖然您可透過 Azure 入口網站 或 CLI 在應用程式組態中管理功能旗標和金鑰保存庫參考，但您也可以使用應用程式組態 SDK，以程式設計方式建立和更新它們。 因此，您可以撰寫自訂的管理入口網站，或以程式設計方式在 CI/CD 中管理。 功能旗標和金鑰保存庫參考 API 適用於所有支援語言的 SDK。 請參閱範例連結，以取得每種支援語言的範例。

在應用程式中評估和取用功能旗標需要應用程式組態提供者和功能管理程式庫，這些程式庫適用於 .NET 和 Java Spring。 如需詳細資訊，請參閱「快速入門」和「教學課程」底下的「功能管理」一節。

短期衝刺設定檔提供方法分隔應用程式各部分 (包含設定)，並使其僅在特定環境或當利用特定程式庫時可用。

建議您將索引鍵值的標籤設定為與 Spring 設定檔一致。 根據預設，若未明確設定標籤篩選條件，則 Azure 應用程式組態短期衝刺提供程式庫將根據目前活動的短期衝刺設定檔 (${spring.profiles.active})，以相同標籤來載入索引鍵值。 若無使用中的 Spring 設定檔集，則會載入「無標籤」索引鍵值。

例如，對於設定檔dev與prod，您可利用以下標籤建立相應索引鍵值。

當短期衝刺設定檔設定為dev時，config.message的值將為Hello from dev。 當短期衝刺設定檔設定為prod時，config.message的值將為Hello from prod。

您可在啟動程式檔案設定標籤篩選條件來覆寫這個預設行為。 無論使用中的短期衝刺設定檔為何，短期衝刺提供者程式庫都將根據指定的標籤來載入索引鍵值。

spring.cloud.azure.appconfiguration.stores[0].selects[0].label-filter: my-label

若要選取其他標籤與您的 Spring 設定檔，您可利用類似 ',${spring.profiles.active}' 的標籤篩選，這將選取所有不含標籤的索引鍵，以及與 Spring 設定檔一致的索引鍵。 當找到重複的索引鍵時，最右側的標籤會優先處理。

從 3.1.0 版開始，Microsoft.FeatureManagement 程式庫允許執行功能管理服務 (包括功能篩選) 做為相依性插入式 .NET 應用程式中的範圍服務。 若要利用這項功能，您可以直接將程式碼中的 AddFeatureManagement 呼叫取代為 AddScopedFeatureManagement，如下列程式碼片段所示：

services.AddScopedFeatureManagement();

功能篩選可以根據 HTTP 要求的屬性來評估功能旗標。 執行方式通常是透過單一 IHttpContextAccessor模式 來檢查 HttpContext。 不過，此模式不適用於 Blazor 伺服器應用程式，此應用程式應改用範圍服務。 在此情況下，應該使用 AddScopedFeatureManagement 方法。

訂閱我們的 GitHub 公告存放庫。

您可以直接在 GitHub 與我們聯繫。

• 關於 Azure 應用程式組態