怎麼用好Spring Config

轉載自本人博客
原文地址： https://www.deanwangpro.com/2...

配置其實分爲結構和內容兩個方面，結構對應的是代碼，好比1.0.0新開發的代碼上有一個功能開關${feature.switchA}，但master上尚未，這就是結構的變化。另外一方面是內容，1.0.0的開發分支有兩個測試環境，連着不一樣的數據庫，那麼對應的${mysql.url}的內容確定不一樣。

內容的類別上也能夠分爲三種：業務配置，功能開關，服務配置。

Spring Cloud的配置中心是Spring Config，通過兩年的使用，發現了其中很多的問題，有些是使用問題，有些是Spring Config自己的管理能力致使的問題。

Spring Config首推基於git的管理方式，提供了兩個管理維度，一個是label(即branch)，一個是profile。當服務foo在一套代碼下要安裝多套環境，好比預發佈環境有2套，一套在shanghai機房，一套在beijing機房。那麼比較天然的管理維度就是利用profile，foo-shanghai.yaml以及foo-beijing.yaml。當生產環境也依然須要2臺時，怎麼處理呢？這時候就會有兩種作法，一種利用增長label維度作區分，一種依然只用profile。

方法一：用label + profile區分

Name	Branch	Profile
foo-shanghai.yaml	stg	shanghai
foo-beijing.yaml	stg	beijing
foo-shanghai.yaml	prd	shanghai
foo-beijing.yaml	Prd	beijing

branch其實表示的是結構，即對應不一樣的代碼，而profile對應的是內容。

這種方式有什麼問題？通常應用都是隻有profile來區分環境，好比logback要分環境區分配置也是經過<springProfile>來指定。一旦採用兩個維度來肯定惟一的配置，那麼全部項目都須要有label這個變量。

試想若是foo這個應用在線上有個bug須要fix，勢必會增長一個hotfix的branch在配置中心，同時還須要增長相應的profile，對應foo的label變量設置爲hotfix，profile設置爲beijing或者shanghai。

再考慮另外一種狀況，foo在prd的代碼須要放到stg進行驗證如何處理？foo的代碼版本確定是prd的（由於stg的配置結構也許已經變了），但profile須要用stg的環境。這時實際上只能在配置中心的prd分支上新建一個新的profile來臨時知足這種需求。

方法二：只使用profile區分

Name	Branch	Profile
foo-stg-shanghai.yaml	master	stg-shanghai
foo-stg-beijing.yaml	master	stg-beijing
foo-prd-shanghai.yaml	master	prd-shanghai
foo-prd-beijing.yaml	master	prd-beijing

這種方式能夠下降管理維度，即放棄label的維度，只有profile的維度。一樣的問題，若是foo這個應用在線上有個bug須要fix，那麼須要新增兩個profile，hotfix-beijing和hotfix-shanghai。雖然維度下降了，可是管理上卻有些麻煩。由於master的這個分支沒法保護起來，若是有開發人員直接修改了prd-XXX的環境就會致使線上問題。

一樣的，foo在prd的代碼須要放到stg進行驗證如何處理？foo的代碼版本確定是prd的（由於stg的配置結構也許已經變了），但profile須要用stg的環境。這時實際上只能再配置中心新建一個profile，好比stg-oldshanghai，來知足這種需求。

然而咱們知道，增長新的profile其實仍是挺麻煩的事情，若是代碼中有直接比較profile的邏輯，那麼每每容易出現問題。

有沒有不臨時增長profile的辦法呢？其實仔細思考一下，在stg環境驗證prd的服務，真正的邏輯是什麼？是但願用stg環境的配置內容，以及stg某個歷史版本（與prd匹配的）的配置結構。因此縱向維度咱們須要的實際上是version，profile都是stg-shanghai，而version一個是1.0.0，一個是latest。

方法三：綜合一下

好了，如今咱們來綜合一下兩種方式，可使用git的分支做爲version，profile依然仍是按照方法二來區分。畢竟頻繁增長環境的可能性不高。可是若是要同時維護一個profile兩個分支，其實仍是要來回切換的，比較麻煩，這也是Spring Config爲人詬病的管理功能弱。好在Spring Cloud也支持mysql，用mysql同時管理多個label的內容仍是方便很多，只是git自帶的「後悔藥」(history)功能沒有了。因此說仍是有利有弊。

小結

若是想要更完善的配置管理工具，建議仍是使用Apollo。要想用好Spring Cloud，必須能夠忍受它比較弱的管理能力，而且作好前期規劃，結合項目特色來使用label和profile的能力。