本節介紹了通過組態管理降低配置變更風險的實踐方法。
組織配置
ACM 提供了 dataId、group、app、namespace 等四個維度來協助管理配置。勤於梳理且善用這些維度，能減少在組態管理過程中發生失誤，提高系統穩定性。
- 配置組織方式
-
dataId
-
用來表示一組相關的 key=value 的配置項的集合。
-
規範 dataId 命名，例如： com.company.trade.threadpool.params，trade.p1.props。
-
-
group
一般使用模組名或者雲資源名。若一個應用使用了 Nginx，SLB， 此處 group 命名即 nginx，slb。
-
app
應用分組，一般是一個簡單的業務單元或者微服務分組，由一個小型或中型團隊開發和維護。
-
namespace
粗粒度隔離多個應用的配置，例如多環境。
-
-
配置影響分級
每個配置項的變更對系統的影響均不同。例如：記錄層級的變更出現錯誤，會改變系統的日誌量，此外一般不會有其它負面的影響。而串連池、線程池、限流閾值、主機配置等的變更往往是一個 Server 層級或者一個應用服務叢集層級的影響。
分布式系統如全域路由規則、負載平衡策略、網路設定等是重量級的配置，錯誤的變更往往會帶來嚴重的後果。因此需要按照配置影響力，將配置等級分為 P0~P4。
以下是樣本說明。
層級 影響力 例子 P0 全網 全域路由規則，網路設定，負載平衡配置 P1 應用叢集 叢集限流閾值，叢集服務端點 P2 主機分級關鍵配置 主機資源配置，線程池大小 P3 進程層級非關鍵配置 記錄層級 P4 無關緊要的配置 版本資訊 -
避免配置項集中於一個檔案
若將應用的所有配置項都放在一個配置裡，則意味著所有的人都在一個配置集上修改，這將導致配置變更、推送變得相對頻繁，且增加了互相衝突以及誤操作的風險，不利於更好的配置授權和分級的變更流程管控。
-
重要配置變更使用灰階發布
重要的配置（如 P0、P1 級）需設定變更審核、灰階等發布策略來降低變更風險。
確保配置安全
敏感配置資訊請加密後儲存在 ACM 裡
ACM Server 的主機和配置儲存中預設不做資料加密處理。對於一些敏感配置資訊，如密碼、Token、AccessKey 等資訊，必須加密後才可以儲存在 ACM 裡。
ACM 的 API 和控制台均有提供配置資訊加密工具，協助您將資訊加密之後再儲存到 ACM 裡。