本文討論使用 Azure 應用程式組態時的常見模式和最佳做法。
索引鍵群組
應用程式組態提供兩個選項來組織索引鍵：
- 索引鍵前置詞
- 標籤
您可以使用一或兩個選項來分組索引鍵。
索引鍵前置詞可讓您藉由在名稱中使用通用前置詞來分組相關索引鍵。 前置詞可以包含多個區段，以分隔符分隔，例如 / 或 :，形成階層命名空間。 在單一應用程式組態存放區中儲存多個應用程式或微服務的組態密鑰時，此方法很有用。
請務必記住，應用程式程式碼會直接參考索引鍵來擷取其對應值。 因此，索引鍵應該保持穩定，以避免程式碼變更。 如有需要，您可以使用應用程式組態提供者在執行期間修剪密鑰的前綴字串。
標籤可讓您建立索引鍵的變化，例如不同版本或環境特定設定。 藉由指派標籤，您可以維護相同索引鍵的多個值。 接著，您的應用程式可以藉由指定適當的標籤來擷取不同的索引鍵/值集合，讓程式代碼中的密鑰參考保持一致。
索引鍵/值組合
應用程式組態會將儲存在其中的每個金鑰視為獨立實體。 它不會根據索引鍵階層推斷索引鍵之間的關聯性或繼承值。 不過，您可以在應用程式中透過標籤和組態堆疊的結合，有效整合多個索引鍵集合。
假設您有名為 TestApp：MySetting 的組態設定，其值會根據環境而有所不同。 您可以建立兩個具有相同名稱的索引鍵，但指派不同的標籤，其中一個沒有標籤（預設值），另一個標示為 開發。 未標記的索引鍵會保留預設值，而加上標籤的索引鍵則包含環境特定值。
在應用程式程式代碼中，您會先載入預設的索引鍵/值，然後使用 [開發 ] 卷標載入環境特定的索引鍵/值。 載入第二組時，任何相符的索引鍵會覆寫先前載入的值。 此方法可讓您「堆疊」多個組態集，最後一個載入的值優先。 跨支援語言和平臺的應用程式設定提供者提供這項堆疊功能。
下列範例示範如何在 .NET 應用程式中實作機碼值組合：
configBuilder.AddAzureAppConfiguration(options => {
options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
// Load all keys that start with `TestApp:` and compose with two different labels
.Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
.Select(keyFilter: "TestApp:*", labelFilter: "Development");
});
使用標籤為不同環境啟用不同的設定會提供完整範例。
設定重新整理
Azure 應用程式組態支援動態設定重新整理，而不需要重新啟動應用程式。 應用程式組態提供者可以使用兩種方法來監視組態變更：
監視所有選取的金鑰
在此方法中，提供者會監視所有選取的金鑰。 如果在任何選取的索引鍵/值中偵測到變更，則會重載整個組態。 此方法可確保立即更新，而不需要進行額外的密鑰修改。
configBuilder.AddAzureAppConfiguration(options =>
{
options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
// Load all keys that start with `TestApp:` and have no label
.Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
.ConfigureRefresh(refreshOptions =>
{
// Trigger full configuration refresh when any selected key changes.
refreshOptions.RegisterAll();
});
});
監視 Sentinel 索引鍵
或者，您可以監視個別鍵，通常稱為哨兵鍵。 此方法在更新多個鍵值時很有用。 只有在完成所有其他組態變更之後，才會更新 sentinel 金鑰，以確保應用程式只會重載設定一次，維持一致性。
configBuilder.AddAzureAppConfiguration(options =>
{
options.Connect(new Uri("<your-app-config-endpoint>"), new DefaultAzureCredential())
// Load all keys that start with `TestApp:` and have no label
.Select(keyFilter: "TestApp:*", labelFilter: LabelFilter.Null)
.ConfigureRefresh(refreshOptions =>
{
// Trigger full configuration refresh only if the `SentinelKey` changes.
refreshOptions.Register("SentinelKey", refreshAll: true);
});
});
這兩種方法都可透過支援的語言和平臺的應用程式設定提供者取得。
若要降低設定不一致的風險，請使用 設定快照 集來確保設定完整性。
外部資料的參考
應用程式組態的設計目的是儲存您通常會儲存在設定檔或環境變數中的任何設定資料。 不過，某些類型的資料可能更適合存放在其他來源。 例如，將祕密儲存在金鑰保存庫、Azure 儲存體中的檔案、Microsoft Entra 群組中的成員資格資訊，或資料庫中的客戶清單。
您仍然可以藉由將外部資料的參考儲存在索引鍵/值中，來利用應用程式組態。 您可以使用內容類型來區分每個資料來源。 當應用程式讀取參考時，其會從參考的來源載入實際資料，假設其具有來源的必要權限。 如果您變更外部資料的位置，您只需要更新應用程式組態中的參考，而不是更新和重新部署整個應用程式。
在此案例中，應用程式組態金鑰保存庫參考功能是範例。 其可讓應用程式視需要更新所需的祕密，而基礎祕密本身會保留在金鑰保存庫中。
應用程式組態啟動程序
若要存取 Azure 應用程式組態存放區，您可以使用連接字串或Microsoft Entra 標識符進行驗證。 雖然連接字串已在 Azure 入口網站中隨時可用，但它們包含認證資訊，而且必須被視為秘密。 如果您選擇此方法，請將連接字串安全地儲存在 Azure Key Vault 中，並確定您的應用程式會向 Key Vault 進行驗證以擷取。
更安全且建議的方法是使用 Microsoft Entra ID 驗證。 如果您的應用程式裝載在 Azure 中，例如在 Azure Kubernetes Service、App Service 或 Azure Functions 上，您可以使用 Microsoft Entra ID 所提供的受控識別。 受控識別不需要明確管理秘密。 使用此方法時，您的應用程式只需要應用程式組態端點 URL，此 URL 可以安全地內嵌在應用程式程式代碼或組態檔中。
如需詳細資訊，請參閱使用受控識別來存取應用程式組態。
Azure Kubernetes Service 對應用程式組態的存取
下列選項適用於裝載在 Azure Kubernetes Service (AKS) 中的工作負載，以存取 Azure 應用程式組態。 這些選項通常也適用於 Kubernetes。
將 Azure 應用程式組態 Kubernetes 提供者新增至 AKS 叢集。 Kubernetes 提供者會以 Pod 的形式在叢集中執行。 它可以依據應用程式組態存放區中的索引鍵/值和 Key Vault 參考來建構 ConfigMap 和秘密。 ConfigMap 和秘密均可當成環境變數或掛接的檔案取用，不需要對應用程式程式碼進行任何修改。 如果您在相同的 AKS 叢集中執行多個應用程式，這些應用程式都可以存取產生的 ConfigMap 和秘密，而不需要對應用程式組態提出個別要求。 Kubernetes 提供者也支援動態設定更新。 如果您可以的話，建議使用此選項。
更新您的應用程式以使用 Azure 應用程式組態提供者程式庫。 提供者程式庫有許多架構和語言，例如 ASP.NET、.NET、Java Spring、JavaScript/Node.js 和 Python。 此方法可讓您完整存取應用程式組態功能，包含動態組態和功能管理。 您可以細微控制要載入哪些資料，以及每個應用程式使用的應用程式組態存放區。
使用 Helm 與 Kubernetes 部署整合。 如果您不想更新應用程式或將新的 Pod 新增至 AKS 叢集，您可以選擇透過 Helm 部署來將 App Configuration 的資料帶入 Kubernetes 叢集。 這個方法可讓您的應用程式繼續從 Kubernetes 變數和祕密存取設定。 每當您想要讓應用程式納入新的設定變更時，都可以執行 Helm 升級。
App Service 或 Azure Functions 對應用程式組態的存取
使用應用程式組態提供者或 SDK 程式庫，直接在應用程式中存取應用程式組態。 此方法可讓您完整存取應用程式組態功能，包含動態組態和功能管理。 App Service 或 Azure Functions 上執行的應用程式可以透過下列方式，取得應用程式組態存放區的存取：
- 在 App Service 或 Azure Functions 上啟用受控識別，並對其授予應用程式組態存放區的存取。 如需詳細資訊，請參閱使用受控識別來存取應用程式組態。
- 在 App Service 或 Azure Functions 的應用程式設定中，將連接字串儲存於應用程式組態存放區。 為了增強安全性，請將連接字串儲存於 Key Vault 並從 App Service 或 Azure Functions 參考。
您也可以將應用程式組態資料作為應用程式設定或環境變數，以讓應用程式存取。 透過此方法，您可以避免變更應用程式程式碼。
- 在 App Service 或 Azure Functions 的應用程式設定中，將參考新增至應用程式組態資料。 應用程式設定提供工具，一次將索引鍵/值集合匯出為參考。 如需詳細資訊，請參閱使用 App Service 和 Azure Functions 的應用程式組態參考。
- 將應用程式設定資料匯出至 App Service 或 Azure Functions 的應用程式設定，而不需選取匯出為參考的選項。 若要應用程式取得變更，請在每次對應用程式組態變更後再次匯出資料。
減少對應用程式組態提出的要求
對應用程式組態的過多要求可能會導致節流或超額費用。 若要減少提出的要求數目：
增加重新整理間隔，特別是當您的組態值不常變更時。 使用
SetRefreshInterval方法指定新的重新整理間隔。監看單一 sentinel 金鑰，而不是監看個別金鑰。 只有在 sentinel 金鑰變更時，才重新整理所有設定。 請參閱在 ASP.NET Core 應用程式中使用動態設定，來取得範例。
如果您在 Kubernetes 叢集中執行多個工作負載，每個工作負載都會個別從應用程式組態提取資料，請使用應用程式組態 Kubernetes 提供者。 Kubernetes 提供者會從應用程式組態擷取資料，並讓它以 Kubernetes ConfigMaps 和祕密的形式提供。 如此一來，您的工作負載就可以透過 ConfigMaps 和祕密存取資料，而不需要個別從應用程式組態提取資料。
在應用程式組態存放區中啟用異地複寫，並將要求分散到多個複本。 例如，全域部署的應用程式在每個地理區域都使用不同的複本。 每個應用程式組態複本都有其各自的要求配額。 此設定可讓您的模型在發生暫時性與區域中斷時有更好的可擴縮性和復原能力。
將設定資料匯入應用程式組態
應用程式組態提供選項，可讓您使用 Azure 入口網站或 CLI，從目前的設定檔大量匯入設定。 您也可以使用相同的選項，從應用程式組態匯出索引鍵/值，例如相關存放區之間的索引鍵/值。 如果您採用設定即程式代碼並管理 GitHub 或 Azure DevOps 中的設定，您可以使用 GitHub Actions 或 Azure Pipeline Import 工作來設定進行中的組態檔匯入。
應用程式組態中的多區域部署
如果您的應用程式部署在多個區域中，建議您啟用應用程式組態存放區的異地複寫。 您可以讓應用程式與應用程式執行個體部署區域的複本建立主要連線，並允許容錯移轉至其他區域中的複本。 此設定可將應用程式與應用程式組態之間的延遲降到最低並分散負載，因為每個複本都有個別的節流配額，可增強應用程式在發生暫時性與區域中斷時的復原能力。 如需詳細資訊，請參閱 復原和災害復原。
建置具有高復原能力的應用程式
應用程式通常仰賴設定來啟動，這讓 Azure 應用程式組態的高可用性變得至關重要。 為了改善復原能力，應用程式應該使用應用程式組態的可靠性功能，並考慮根據您的特定需求採取下列措施。
- 使用 Azure 可用性區域支援在區域中佈建。 可用性區域可讓應用程式在資料中心中斷服務時復原。 應用程式組態為所有客戶提供區域備援，無需支付任何額外費用。 建議在支援可用性區域的區域中建立應用程式組態存放區。 您可以參閱區域清單，瞭解哪些區域的應用程式組態已啟用可用性區域支援。
- 啟用異地複寫並允許您的應用程式在複本之間容錯移轉或分散負載。 此設定可讓您的模型在發生暫時性故障與區域中斷時有更好的可擴縮性和復原能力。 如需詳細資訊，請參閱 復原和災害復原。
- 使用安全部署做法部署設定。 不正確或意外的設定變更經常會導致應用程式停機。 您應避免進行會對生產環境造成直接影響的設定變更，例如盡可能使用 Azure 入口網站。 在安全部署實務 (SDP) 中，您可以使用漸進式曝光部署模型，將部署造成的問題潛在爆炸半徑降到最低。 如果您採用 SDP，則可以先建置和測試設定快照集，然後再部署至生產環境。 在部署期間，您可以更新應用程式的執行個體，以漸進方式挑選新的快照集。 如果偵測到問題，您可以重新部署上次已知的良好設定 (LKG) 快照集來復原變更。 快照集是不可變的，以保證所有部署的一致性。 您可以使用快照集以及動態設定。 針對緊急設定覆寫和功能旗標使用基礎設定和動態設定的快照集。
- 將設定納入應用程式。 如果您想要確保應用程式一律可以存取設定複本，或者您想要避免應用程式組態的執行階段相依性，您可以在建置或發行期間從應用程式組態提取設定，並將它納入應用程式中。 若要深入了解，請參閱整合應用程式組態與 CI/CD 管線或 Kubernetes 部署的範例。
- 使用應用程式組態提供者。 應用程式是達成高復原能力的重要關鍵，因為它們可以考慮執行階段期間所產生的問題 (例如網路問題)，並且更快速地回應失敗。 應用程式組態提供者提供一系列的內建復原功能，包括自動複本探索、複本容錯移轉、透過可自訂的逾時設定啟動重試、設定快取，以及重新整理可靠設定的彈性策略。 強烈建議您使用應用程式組態提供者來發揮這些功能的作用。 如果這不是選項，則您應考慮在自訂解決方案中實作類似的功能，以達到最高層級的復原能力。
應用程式組態中的用戶端應用程式
當您在用戶端應用程式中使用應用程式組態時，請確定您考慮兩個主要因素。 首先，如果您在用戶端應用程式中使用連接字串，則可能會將應用程式組態存放區的存取金鑰公開給大眾。 其次，用戶端應用程式的一般規模可能會導致對應用程式組態存放區過多的要求，這可能會導致超額費用或節流。 如需節流的詳細資訊，請參閱常見問題集。
若要解決這些疑慮，建議您在用戶端應用程式與應用程式組態存放區之間使用 Proxy 服務。 Proxy 服務可以安全地向您的應用程式組態存放區進行驗證，而不會發生洩漏驗證資訊的安全性問題。 您可以使用其中一個 App Configuration 提供者程式庫來建置 Proxy 服務，以便利用內建快取和重新整理功能來最佳化傳送至 App Configuration 的要求量。 如需使用 App Configuration 提供者的詳細資訊，請參閱「開始使用」中的文章。 Proxy 服務會將設定從快取提供給用戶端應用程式，並避免本節中討論的兩個潛在問題。
請務必考量，在將組態呈現給用戶端應用程式時，一般使用者可以看到組態值。 應注意避免意外暴露敏感資料。 例如，功能旗標目標設定中的使用者和群組名稱可能會被視為 EUII（終端使用者識別資訊）。 若要降低此風險，請考慮使用專用於用戶端應用程式設定的個別 App Configuration 存放區資源，或使用篩選機制 （例如索引鍵前置詞、標籤或標籤） 來區段設定，並據此在 Proxy 伺服器中篩選。
應用程式組態中的多租用戶應用程式
多租用戶應用程式是以一個架構為基礎，其中應用程式的共用執行個體會為多個客戶或租用戶提供服務。 例如，您可能有一個電子郵件服務，可為使用者提供個別的帳戶和自訂體驗。 您的應用程式通常會為每個租用戶管理不同的組態。 以下是在多租用戶應用程式中使用應用程式組態的一些架構考量。 您也可以參考 多租使用者應用程式設定的範例程式代碼。
設定即程式碼
設定即程式碼是管理原始檔控制系統下設定檔的做法，例如 Git 存放庫。 其提供任何設定變更的可追蹤性和核准程序等優點。 如果您採用設定即程式碼，應用程式組態有工具可協助您管理檔案中的設定資料，並將其部署為組建、發行或 CI/CD 程序的一部分。 如此一來，您的應用程式就可以從應用程式組態存放區存取最新的數據。
- 針對 GitHub，您可以使用 GitHub Actions，將設定檔從 GitHub 存放庫匯入應用程式設定存放區
- 針對 Azure DevOps，您可以在組建或發行管線中包含 Azure 應用程式組態匯入 (一種 Azure 管線工作)，以進行資料同步處理。
- 針對其他項目，您可以使用 Azure CLI 作為 CI/CD 系統的一部分，將組態檔匯入應用程式組態。 如需詳細資訊，請參閱 az appconfig kv import。
此模型可讓您在將資料認可至應用程式組態之前，先包含驗證和測試步驟。 如果您使用多個應用程式組態存放區，您也可以將設定資料以累加方式或全部推送至這些存放區。