最近團隊在做一個集中化配置管理系統，根據運維團隊的需求，要考慮應用灰度發布時配置部分變更的可能，需求是首先變更某個機房的某台服務器上的配置，進一步地，修改該機房所有服務器的配置，最后修改全局服務器的配置。這樣的需求和通常理解的灰度發布有一定區別，暫且叫他灰度配置。本文主要理解下兩種灰度的差異，並且簡要說明兩種灰度的實現方案。
集中管理和灰度概念
集中化配置管理系統：指的是指將原本散亂存放在各個服務器上的配置（通常的配置文件），集中在統一的平台進行管理，配置管理員可以在該平台上對配置進行增刪改查，而每一個需要配置的節點在啟動時主動向平台獲取。進一步地，在配置發生變化時，主動通知到所有使用該配置的節點，以達到動態配置變更的目的。現在大的互聯網公司都有自己的一套集中化配置管理系統，比如阿里巴巴的diamond系統，apache的zookeeper等。
灰度發布
應用的灰度發布指的是，新系統發布時不直接廢止舊的系統，而是有一段新舊系統的共存時間。通過逐漸增加新系統承擔的負載權重，直到完全替代舊的系統。這樣的好處在於避免因為新系統存在功能異常或者設計上的不合理導致的服務完全中斷，通過漸進式觀測新系統替代舊系統的效果，達到平緩升級的目的。理解來說，就是在一段時間內，通過流量源頭的開關控制，動態調整新舊系統承擔的負載。
灰度配置
一個系統的服務器集群中，不同機器使用不同的配置，每一次，調整一批機器的配置，最終達到全系統配置統一。可以這么理解，相同系統的不同服務節點使用不同的配置，叫他灰度配置。
灰度發布和灰度配置的差異和實現
差異
灰度發布和灰度配置概念完全不同，灰度發布的過程像是現在社會的稅收制度，每個人拿一點錢出來貢獻黨國，大家都是一樣的標准，一視同仁。恢復配置更像是建國初期的打地主，圈出社會屬性帶有地主的一群人，把他們財產充公，特點是只是針對一部分人，但每一個被選中的人都要一分不剩。
灰度發布設計
關於灰度發布業界已經有比較成熟的實現，在需要灰度系統系統的前置流量入口系統上增加一個選擇功能，先做一次發布。然后需要灰度發布的下游系統，將新系統部署上去，和老系統共存。灰度發布過程中，通過修改一個權重配置並推送到控制流量的前置入口系統上，將部分流量引向新的系統，並觀察新系統的表現。逐漸地，繼續修改權重配置，增加新系統承擔的流程，直到新系統完全承擔所有流量，下線老系統。
灰度配置設計
關於灰度配置，有一個種設計是，將配置做一個層級的划分。一共分為6層，包括：全局配置，全局灰度配置，機房配置，機房灰度配置，節點配置，節點灰度配置。優先級是，節點灰度配置>節點配置>機房灰度配置>機房配置>全局灰度配置>全局配置。也即是說對業務來說的一個配置，在底層存儲實際上是6個配置。對於一個配置的需求者，每次啟動獲取6個配置的內容，然后根據優先級選擇自己應該加載的配置。進一步地，他需要關注6個配置的變更情況，一旦當前配置被刪除，需要重新根據優先級選擇自己應該加載的配置內容。
灰度配置設計的思考
灰度配置方案存在的缺點
- 配置的設計過於復雜，6個配置很可能讓運維人員陷入混亂。
- 配置級別不靈活，比如新增一個城市級別的配置就足夠讓所有應用跳腳；又在比如，因為服務器可能存在上線，下線或者遷移的情況，一次機房級別的配置變更，如何確認變更的服務器列表是否正確。
灰度配置方案缺陷分析
以上2個缺點，核心的問題在於一個配置管理系統做了一些可能不應該由他做的事情，比如負責節點的定義，機房的定義，灰度的定義等等，導致了設計上復雜和維護上的難度。當然，業務方有這樣的需求，自然是要想方設法去做滿足，以下提供一種新的設計方案，可以解決或者部分解決以上2個問題。
灰度配置新方案
新方案及運行時狀態描述
- 去掉6個級別的配置，改成2個級別，即全局配置和臨時配置，優先級為臨時配置>全局配置。
- 增加機器分組的功能，該功能只在灰度發布時候臨時使用。
- 正常運行時，一個配置需求者只需要關注全局配置以及自身的分組信息，灰度發布前，所有機器使用全局配置正常運行。
- 當灰度發布的時候，建立一個空的群組，為該群組設置臨時配置信息，逐漸地，往該群組中添加機器信息，直到機房所有節點或者全局所有節點都放入。事情發生的時候，每個配置需求者發現自己的分組信息發生變化（即加入某個群組），就去獲取該群組的臨時配置信息，優先使用。
- 直到所有機器都歸入該群組后，即表示灰度完成，所有節點配置一致。這時候，將全局配置更新為灰度配置，並取消組群關系。事情發生時，每個配置需求者發現自己的分組信息發生變化（即分組被刪除），就去獲取全局配置，正常地，因為全局配置的內容和灰度配置內容一致，配置需求者不產生任何變化（因為變化已經在灰度的過程中發生過了）。
新方案的優劣分析
- 該方案將原來多級別的配置設計改成全局和臨時2個級別，而且臨時配置只在灰度發布時使用，設計上簡單可控。
- 群組功能足夠靈活，將機器分組屬性的判斷抽象出來（重點），在滿足業務灰度配置功能的前提下，保持自身的邏輯足夠簡單。
- 對於分組功能，剛開始可以由運維人員手動添加一些模板，每個模板組保存一個機房的服務器列表，然后在實際發布的過程中，可以直接copy模板組的內容，也可以根據實際需要構建一些臨時的分組，以組為單位變更配置，這樣就滿足了運維人員分批推送配置的需求。
- 進一步地，可以構建一個運維管理系統，專門負責管理服務器的信息。將該系統和集中化配置管理系統進行對接，在每次發布時動態地獲取分組信息，就能免去人工維護分組的麻煩。
- 當然，既然是分組，就會遇到一個問題，當遇到一台機器被歸入多個臨時分組的情況應該怎么辦。有一種方法是對臨時分組設置優先級，根據優先級決定讀取哪個臨時分組的配置信息，不過這種方法比較復雜，而且優先級很難定義且有存在重復的可能。另一種方法就是直接互斥，針對同一個配置，一台機器只能被放入一個臨時分組中，這樣邏輯會更簡單。