Application Configuration Management(Deprecated)：利用配置中心規範構建 PaaS 服務配置

遷移到MSE Nacos

ACM進入下線狀態，所有組態管理相關的需求由MSE中的Nacos承接（ACM獨享版，更好的安全和穩定性）。您需要在ACM控制台匯出配置，然後在MSE控制台匯入之前置出的配置即可完成遷移。具體操作，請參見將應用配置從ACM遷移到MSE Nacos。

配置規範問題的產生

如果是單一應用的單一屬性配置，使用以下設定檔即可完成，沒有配置規範的問題。

//配置目錄結構
--app
   |--src
      |--config
         |--application.properties
//配置內容
RCV_INTERVAL_TIME=20

但是，如果是為分布式 PaaS 服務編寫分布式規則，PaaS 服務提供者（而非應用方）在設計配置時會遇到許多問題。以 MQ 限流情境為例，可能遇到的問題有：

• 如何區分全域配置和局部應用配置：例如，PaaS 服務方在統一管控平台提供的服務時，如何既有全域的規則配置，又能針對某個應用進行特殊配置。
• 如何區分不同叢集 MQ 服務：例如，在保證配置命名統一的情況下，如何區分 MQ1 Cluster 和 MQ2 Cluster 的配置。
• 如何使用同一套配置中心來隔離 Dev、Test、Staging、Prod 等不同環境。

以上 MQ 限流情境需求如圖所示。

顯然，不恰當的配置命名規範將影響以上配置的易用性。

下文詳細介紹了以規範的配置命名格式來進行限流設定的方法。為了說明配置命名規範，首先需要介紹配置中心的配置結構組織的能力。

配置中心的配置結構功能

除了集中管理配置和訂閱推送等能力，配置中心還具備配置結構化能力，能協助管理員大幅簡化各種複雜應用情境下的組態管理。

1. 配置中心的配置結構能力說明

• 租戶隔離：配置中心根據使用者或情境對配置進行隔離。使用租戶隔離，不同的配置在不同的租戶可以重名，且具有不同的鑒權機制。
• 最小配置集合：若干配置通過配置中心組合成一個配置集合。使用最小配置集合來更改和發布不同配置，可實現統一發布和統一處理。配置路徑的概念類似於檔案路徑或者網路網域名稱，它讓不同配置集合之間具有層級關係。
• 具體配置的 Key-Value 形式：在配置中心中設定具體配置內容。

2. 配置中心配置結構能力產品比較

為了更直觀地說明，我們對比了幾個配置中心產品：

• 阿里雲 ACM：阿里雲Application Configuration Manangement，前身為 Diamond，是中國最早的配置中心產品。目前在 Git 上有不同開源版本，在阿里雲上有商業版可供使用。
• Spring Cloud Config：Spring Cloud 官方配置中心工具，主要用於 Java Spring 領域。
• ZooKeeper：雖然具備部分配置中心能力，但是由於定位於分布式協調資訊管理，因此只適合在應用規模不大的情況下用作配置中心。鑒於其使用廣泛，此處也將其納入對比範圍。

對比詳情如下：

綜上所述，ACM 在租戶隔離和最小配置集合方面都有較大的靈活性。下文介紹如何利用 ACM 的 Namespace、Group、DataID 等配置功能來設計一個用於執行 QoS限流策略的合理配置結構。

基於配置中心的分布式服務配置設計最佳實務

1. 配置結構

為了滿足 MQ 配置的功能需求，結合 ACM 的特點，可採用以下配置方法。

• 以不同 Namespace 隔離不同環境的 MQ 配置。例如：

  • ProdEnv 命名空間用於生產環境，TestEnv 用於測試環境，DevEnv 用於開發環境。
  • 不同環境通過 AK/SK 天然隔離，安全性進一步加強。

• 用 Group 來區分不同叢集提供的 MQ 服務，可以達到隔離配置和簡化訪問形式的效果。

  • 例如，對於專門為子部門的核心交易部門服務的 MQ 叢集，和為子部門的交易類目部門服務的 MQ 叢集，可通過 Group 區分不同的全域配置。這種方法使所有應用採用同一（子）公司的 AK/SK（或類似認證體系密鑰），因而簡化了部署，有效隔離了不同叢集的配置，降低了配置複雜性。

    DataID: mq.global.qos
    Group: Trading
    
    DataID: mq.global.qos
    Group: ProductCategory

• 全域配置以全域統一 DataID 命名配置項存放。

  • 其中，配置 ID 以 mq 開頭，global 表示全域配置，QoS 表示 QoS 方面的配置，Group 可使用預設值。

    DataID: mq.global.qos
    Group: Default_Group

• 應用局部配置以相同尾碼 .qos 來命名 ID。

  • 配置 ID 以 mq 開頭，app.[appname] 表示需要重載的 app 配置項，Group 可使用預設值。

    DataID: mq.app.app1.qos
    Group: Default_Group
    DataID: mq.app.app2.qos
    Group: Default_Group

3. 配置具體 KV 的設定

在很多配置中心產品（例如 Appolo、ACM System Manager Parameter Store）中，每個具體的配置是配置中心最小粒度的嵌入式管理單元，使用者需要在某個粒度上逐一設定配置的 KV，但是 ACM 並沒有該限制。常用做法有兩種：

• 仿照以上配置中心，將每個 Key 存在一個獨特的 DataID上，例如：
  • mq.global.qos.RCV_INTERVAL_TIME 設定為 50
  • mq.global.qos.MAX_THREAD 設定為 20

• 將常用配置彙總成一個 DataID，並編輯為一個設定檔（格式不限，例如 Properties、JSON、XML 等）

  • 例如 mq.global.qos 設定如下：

    //MQ 限流 QoS設定
    RCV_INTERVAL_TIME = 50
    MAX_THREAD = 20

在實踐中發現第二種方法不但具有更大的靈活性，而且支援多個配置在一次變更中同時發布，既降低了效能開銷，理論上也達到了變更批量變化的原子操作效果。

4. 配置結構示意圖

以上設計的配置結構示意圖如下：

5. 方案優點總結

• 通過 Namespace 隔離不同環境，使 MQ 配置項在不同 Namespace 可重複。不同 Namespace 通過管理員、程式 AK/SK 等使用權限設定得到隔離保護，達到配置項統一且各個環境互不干擾的效果。

• 通過 Group 隔離相同環境的不同叢集，既能保證不同叢集下配置的統一性（如配置名不變等），使代碼更加簡單，又能在邏輯上隔離不同的叢集配置。

• 通過最小配置集 DataID 的規範命名設定，各 MQ 用戶端即可方便地尋找 MQ Default 全域配置和應用特殊配置。此外，在配置列表頁面上，管理員可通過在關鍵字兩端各加一個星號（*），方便地找出所有 MQ 規則。樣本如下：

  

參考

• 配置變更風險管理