為什么我們在微服務架構中需要引入配置管理這個組件呢？

這里所說的配置管理就是配置中心。

首先我們著眼下需求，從業(yè)務場景上來說，為什么需要一個中心化的配置管理的集群，而不是將所有配置都放到你的服務本地。一般應用上，作為配置管理是非常簡單的，甚至沒有額外的配置中心，那么這種模式我們就是把一個應用部署在一個服務器上面，同時與這個應用一同部署的，還有一份配置文件，比如里面可以約定你的數(shù)據庫連接Url，userName，Password，還有等等其他各種的配置。在SpringBoot項目上，大家非常熟悉Resources這個目錄，在這個目錄下，我們可以定義如application.yml這個樣的各種配置文件。它隨著你的應用一同部署在一個jar里面，這里面的配置項，隨著你應用的加載一同被加載到上下文當中，這是一個比較典型的部署的模式。

這里有一個需求上的變化，如果有一天你的產品經理跟你說啊，我們不能再用王大錘的名號招搖撞騙，我們要把這個userName改成叫王大炮。那這一改不要緊，如果用上面那種經典模式，我們應該怎么做呢？很簡單，配置文件當中把這個屬性名改掉，然后去做一個重啟，把應用重啟，重新去加載配置文件到上下文當中。

這看起來似乎沒什么問題，對于小型應用來說，往往我們也是采用的這種方式，非常的廉價而易于操作，但是我們想過沒有，對于一些大型用，動輒成百上千的微服務，成千上萬臺服務器，如果我們還采用這種基于本地文件的管理方式，那每次有新的變更都要一頓操作猛如虎，把所有集群當中的服務器全部重啟一遍，不要說BATJ這種巨無霸型應用，就是一些小型應用服務器，數(shù)量稍微那么一多，這種方式都不是一種很有效的方式。

那這就是我們配置中心的一個重要的功能，它要達到了一個目的，就是屬性分發(fā)，讓配置文件的內容，如何發(fā)到每一個服務器集群當中，每一臺服務器上。這就是一個配置中心所需要滿足的一個用戶的場景。

從業(yè)務層面來看下，如果現(xiàn)在有三臺服務器，每臺服務器都有自己對應的配置文件，現(xiàn)在有這樣的一個需求場景，它通過一個業(yè)務的開關來控制一個功能的開啟和關閉。比如，我通過一個屬性控制你服務的注冊功能，是開啟還是關閉？比如說我們有一些非常著名的論壇，他需要你提供一些注冊碼，邀請碼，比如1024才能去注冊，那么，它的注冊功能呢就是處于一個關閉狀態(tài)，如果有一天，我的網站搞活動，我想把網站的注冊功能給開啟，在這種情況下來，我們在傳統(tǒng)的屬性分發(fā)過程當中，就像前面提到的，我需要修改靜態(tài)文件，然后再做一個重新的部署。一來操作非常麻煩，要處理整個集群的屬性刷新；二來，你修改文件，重啟服務器，這個時間的開銷也是相當長的。與其使用靜態(tài)文件的分發(fā)，不如我們有一個中心化的配置中心，可以實現(xiàn)屬性變更的實時推送。

這樣一來，就可以玩轉很多不一樣的業(yè)務場景。比如，我可以把一個屬性推送到一個特定的服務器當中，這是什么場景?。窟@就是我們典型的一個金絲雀測試的場景，在一臺服務器上開啟業(yè)務開關去驗證你的業(yè)務。同時我們還可以做一些批量推送，對一些特定的服務器，把屬性變更推送到他們上面，這就是咱們的一些藍綠測試的場景。如果你的配置服務中心可以滿足這樣的實時推送。那么就是好處多多，你的操作節(jié)省了時間，節(jié)省了操作成本，并且增加了你的業(yè)務玩法，什么金絲雀測試、藍綠測試都可以去正常執(zhí)行。

再看一個跟寫代碼比較相關的一個場景。比如，這里有一個訂單服務，一個訂單服務從開始編寫需求到最后上線，通常會經過很多個環(huán)境的驗證，有日常的開發(fā)環(huán)境（Dev），測試環(huán)境（SIT），用戶驗收環(huán)境（UAT），還有在上線之前做的一個預發(fā)測試環(huán)境（Pre），以及最終正式版的線上環(huán)境（PRD），這每一個環(huán)境它的數(shù)據庫連接串、賬號、密碼、以及各種的業(yè)務屬性，通常來講是完全不一樣的。因此，我需要對每一個環(huán)境指定一個配置文件，如此一來，你就要把所有的配置文件都保存在你的本地項目當中，resource文件夾下面就會列出各個不同環(huán)境所需要用到的資源文件。

從這個角度，其實并沒有很好的實踐一個隔離的職責，因為你的配置文件，它和你的業(yè)務邏輯是緊密的聯(lián)合在一塊兒的，如果可以從業(yè)務層面把它剝離出來，也就是說不隨著你的業(yè)務代碼一同部署，而是在一個相對中心化的集群當中去統(tǒng)一的管理這些配置文件，這就可以做到一個職責的隔離，也就是我們常說的低耦合高內聚。

這樣一來，其實本地并不需要保存這四份配置文件，你只有保存一份配置文件就夠了。那系統(tǒng)如何知道該拉取哪一個配置項呢？很簡單，我們在啟動腳本，啟動jar包的腳本當中，我可以把環(huán)境參數(shù)傳入進去。在dev環(huán)境里面，可以傳入dev啟動參數(shù)，在uat環(huán)境里面，可以傳入uat啟動參數(shù)，以此類推。接下來，你的應用可以去配置中心上面，把對應環(huán)境的配置文件拉取到本地，這樣一來，對于你本地的訂單服務這個業(yè)務層面來說，它就做到了一個環(huán)境隔離，你不用關心當前是開發(fā)環(huán)境還是生產環(huán)境，所有配置屬性的環(huán)境隔離，都交有配置中心那邊來處理。

除了環(huán)境隔離以外，還可以做什么呢？一個系統(tǒng)當中有很多的微服務，例如訂單、商品庫存服務等，每個服務在不同環(huán)境還有多種不同的配置文件。如果商品服務也參考我們訂單服務的做法，把以上的配置文件全部交由中心化的一個配置中心來管理，這樣又對我們的配置中心提出了另外一個需求，什么需求呢？從服務層面要做一個隔離，它要知道哪些配置文件是給訂單服務的，哪些配置文件是發(fā)放給商品服務的。

總結一下，對配置中心的三個需求點：

第一個，業(yè)務隔離。將配置文件從具體的業(yè)務代碼當中抽離出來，放到一個中心化的配置中心里面。

第二點，環(huán)境隔離。業(yè)務代碼層并不需要去關心自己當前部署的環(huán)境，由中心化的配置中心集群對不同環(huán)境的配置項做一個隔離，把它們分門別類的放到不同的文件當中。業(yè)務代碼在啟動的時候，根據當前啟動參數(shù)中的環(huán)境名去拉取對應的文件。

第三點，服務隔離，既然是一個中心化的配置服務，那必須要有能力去識別哪些配置文件是屬于哪些服務的。

下篇預告：配置中心的高可用