配置文件的構成和管理

不一樣的類型的配置最開始可能均可以以配置文件的形式將就一下，可是其對管理和使用的需求倒是相差很大的。etcd提供了一個很好的機制作爲開頭，可是未必適合全部的場景。

配置分類

在配置文件中的配置能夠分爲如下幾類：

• 組網配置，也稱爲服務註冊和發現，以ip，端口，用戶名，密碼四個屬性爲主要表明

• A/B測試，小流量，降級開關等流量控制配置

• 營銷規則，運營規則，計價規則類配置

• 文案等純k/v配置

最開始的時候，這些配置都是保存在配置文件中的。可是不一樣類型的配置其實有不一樣的需求，妄圖用一個etcd來解決全部問題是典型的有錘子去找釘子的行爲。

組網配置

組網配置是很是值得從配置文件中抽取來好好管理的東西。不少軟件工程中的困難問題，都來自於你們不能很容易的「搭環境」。各類場合均可以聽到抱怨說搭個環境太難了。而其中最困難的就是把一個十多個模塊的系統用配置文件給拼裝到一塊兒。

組網配置的核心需求是四點：

• 對「服務」的抽象建模

• set（或者region）模型的支持

• （可選）上下游依賴管理

• 生效速度與一致性

組網配置實際上是對集羣進行建模。把集羣一個集羣抽象爲一個set或者一個region。而後一個set裏有多種名稱的服務，一個服務會有多個實例。每一個實例又有本身的ip端口這些屬性。etcd自身是沒有規定如何去創建這個抽象的。須要使用etcd的人去建模。

比較挫的實現是一個set裏的服務是對全部服務均可見的，而這就隱含了全部人在依賴全部人。比較好的方式是一個服務申明本身全部依賴的服務，配置裏只引用本身所依賴的服務。可是依賴管理比較難推廣，因此不是必須的。

大部分業務系統裏對組網配置沒有很強的一致性要求以及生效速度的要求。與數據系統不一樣，主從切換一致性出了問題，會致使嚴重的數據丟失。因此etcd的強一致和生效速度在數據庫領域有一些應用範圍。可是其實深究下去，數據庫也更多的是把paxos/raft作在數據庫自身的分佈式協議內部了，而不是外掛一個etcd來使用。在業務層，etcd的強一致性真沒有多大用處。那麼剩下的就是一個基於watch的即時生效了。可是業務系統真的須要依賴watch即時生效來得到高可用性嗎？顯然是否認的。大部分的探活和故障節點摘除都是利用單機的投票機制來實現的（好比nginx的upstream管理）。靠etcd這樣上報數據，告警，而後中央節點摘除，必然是要慢一步的。因此對於生效速度和一致性來講，etcd未必有多實用。

流量開關

流量開關就是第二個上線系統。經過第一個上線系統把代碼上線到生產環境，而後再經過第二個上下系統把開關打開，讓新代碼真正開始被使用起來。流量開關的好處是能夠有多個開關同時獨立控制，以及精確的流量比例控制，還有快速的的回滾。

流量開關對於配置管理的需求有兩點：

• 規則的下發

• 很是快的生效速度

流量開關須要下發的配置實際上是一堆規則。好比北京，某個產品線，流量打開。可是由於規則數量通常不會特別多，能夠全量下發，並對規則進行全量順序求值。可是假如規則多到了幾萬條，而使用方是php這樣的無狀態的系統，每次業務請求對規則匹配的速度又要求很高的話，仍然是很難用全量下發去實現的。

生效速度是流量開關最重要的功能。當咱們發現開的流量在線上引發了問題，這個時候是分秒必爭的。能不能快速地把流量切回去決定了損失的大小。etcd的watch機制對於流量開關來講很是有用。

營銷等業務規則

營銷等業務規則的特色是數量通常會比較多，好比分城市分場景分車型的計價配置。簡單的順序求值不能知足要求。並且這些業務規則通常會有指定的生效時間段，因此沒有像流量開關那樣突發的要求規則改變的需求。明天的規則，今天能發到線上就能夠了。

營銷等業務規則對於配置的需求有：

• 複雜條件的規則檢索和匹配（按生效時間，按地理圍欄，按人羣分類，按產品屬性等）

• 不依賴於快速生效

• 讀取的可靠性

etcd的樹狀結構能夠實現必定程度的索引。可是對於複雜規則的檢索和匹配仍然是有很大欠缺的，除非咱們願意在寫入的時候創建不一樣檢索維度的樹狀索引，不然在讀取時的匹配成本是沒法接受的。

etcd的快速生效機制並無多大用處。

etcd的http接口依賴於etcd自身服務的可靠性。相對於分發到本地的配置文件，應該是相對來講不可靠一些。與A/B測試這樣的流量控制配置不一樣，業務規則的配置不能是返回true能夠，返回false也行的。

文案等純k/v配置

這類配置最單純，依賴最少。可是若是是大量讀取的界面上的文案，其實還要考慮一下每次讀取的延遲。若是一個頁面須要一百多個文案項的讀取，把會用到的配置都預讀到業務進程內存裏是必然的選擇

因此對配置讀取的需求：

• 在量大的時候須要低延遲的讀取

etcd提供了一個基本的機制，可是對於那些配置會一塊兒使用實際上是不清楚的。若是不能全量緩存到本地，預讀沒有判斷好的話，可能會形成讀取配置的總耗時過長。

總結

配置其實也有本身的業務邏輯。沒有通用的配置系統一說。配置須要理解其對應的管理和使用場景去設計定製的解決方案。