[[434490]]

1. 關于配置管理

1.1 名稱解釋

• 配置項

一個 key=value 組合

• 配置集

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

• 配置實例

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

1.2 配置管理的功能

• 版本控制

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

• 變更控制

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

• 配置審計

審查配置的一致性、規(guī)范性、正確性。

1.3 配置管理的難點

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

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

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

2. 常見的配置管理模型

2.1 CICO 模型

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

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

2.2 組織模型

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

系統(tǒng)模型，列出了組成系統(tǒng)的所有構件

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

2.3 長事務模型

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

2.4 變更集模型

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

3. 新的配置管理模型

3.1 遇到的問題

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

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

3.2 組裝模型

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

配置實例 = 默認配置集 + 環(huán)境配置集 + 集群配置集

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

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

3.3 模板模型

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

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

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

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