轉載自本人博客
原文地址：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。
<!--more-->
方法一：用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的能力。