[[434490]]

1. 關于配置管理

1.1 名稱解釋

• 配置項

一個 key=value 組合

• 配置集

一組配置項的集合，key1=value, key2=value2

• 配置實例

一份完整的，可供應用程序直接使用的配置項的集合。

1.2 配置管理的功能

• 版本控制

對所創建的配置項、配置集、配置實例進行版本跟蹤，支持回滾等操作。

• 變更控制

對配置的變更進行控制、操作、分類、記錄。

• 配置審計

審查配置的一致性、規范性、正確性。

1.3 配置管理的難點

在開發迭代的過程中，隨時隨地隨人都可以對配置進行變更。在不同的時間、應用的不同拓撲層級、不同的人，都有可能會對配置項、配置集、配置實例進行修改。我們需要一種靈活的方式，以支持這些復雜的場景。

配置具有復雜、敏感、影響大的特點。一個配置實例可能有上百個配置項，其中還會包含一些賬戶、密碼等敏感信息，而錯誤的配置可能導致整個服務不可用。

配置管理的靈活與對配置實例的約束是配置管理產品需要平衡的地方。如何在滿足各種使用場景的情況下，通過一定的約束規避一些錯誤發生，是配置管理的難點。

2. 常見的配置管理模型

2.1 CICO 模型

CICO 模型主要關注的是單個文件的版本控制，文件被版本化并存儲到庫中。

• 用戶必須 checkout 文件以存取
• 修改后的文件被 checkin 到庫中產生新版本

2.2 組織模型

組織模型下的配置由兩部分組成:

系統模型，列出了組成系統的所有構件

版本選擇規則，指出了組成配置的每個構件的版本

2.3 長事務模型

長事務模型將配置管理當做是開發人員對配置的事務操作。一系列的變更結果生成一些列的配置版本，稱之為開發路徑。

2.4 變更集模型

變更集模型將配置描述為基線和一組變更集組成。基線可以理解為里程碑版本，也就是一個迭代的結束點、下一個迭代的起始點。

3. 新的配置管理模型

3.1 遇到的問題

CICO 等模型是一些比較老的論文、書籍中提到的，但是在開發 PaaS 平臺管理配置時，卻無法直接套用。

比如，CICO 模型，用 SVN、GIT 管理文件，并沒有強調配置存儲于文件，這個文件到底是指的什么。而組織模型，更像是對一個大型的 PaaS 平臺進行配置管理，由若干個子模塊組成，每個模塊都有獨立的配置，適用于一組微服務的應用配置管理形態。

3.2 組裝模型

古老的模型無法滿足 PaaS 平臺的場景。但是卻能給予一定的啟發，將實物構件泛化為要素，組織模型可以演化出組裝模型。如下圖：

配置實例 = 默認配置集 + 環境配置集 + 集群配置集

利用應用拓撲的定義，根據應用所屬的層級，通過定義一定的優先級關系，將各個層級定義的配置集，合并在一起形成一份配置實例。

組裝模型通過組裝若干要素的方式得到配置實例，但是同一個應用的不同配置實例包含的 Key 集合可能不一樣。這種差異會增加配置管理的成本，也會增加配置錯誤導致的風險，無法直接滿足對配置完整性的約束。

3.3 模板模型

基于對完整性的要求，在變更集模型的啟發下，可以得到模板模型。如下圖:

模板模型需要定義配置實例的模板，根據應用拓撲的結構，形成若干個變更集，對配置實例模板進行覆蓋，得到最終的配置實例。

模板模型增強了對配置實例 Key 的約束，保證了強的一致性，可以避免漏配 Key 導致的事故。

但是強一致性約束，也導致了靈活性受損，需要配合配置項、配置集的發布狀態進行使用。