config分佈式配置中心和服務總線bus

爲什莫會引入config呢？看下圖：

 config含有客戶端和服務端:

服務3344就是配置中心服務服務端：

創建3344服務步驟： 

 pom.xml:

啓動類：config服務端要添加開啓@EnableConfigServer 

 

application.yml: 

 

配置文件讀取規則：下圖

 config客戶端配置：服務3355

 

 

controller: 

 理解：3344服務作爲config的服務端，3344連接github；3355作爲config的客戶端連接3355；通過上述3355服務的測試接口，和3344服務調用結果一樣。  關係就是3344找github,3355找3344

問題隨之而來，分佈式配置的動態刷新問題？

 手動動態刷新的修改如下：步驟如下圖一，然後需要運維人員再發送POST請求來刷新3355，即可：

 

 運維人員post請求：

到這裏，就避免了客戶端服務重啓！ 但是還不是最優化的最完美的方案，如果微服務有100個，豈不是要運維發送100次請求？

所以需要自動刷新，非上面的手動刷新：

 到這塊就需要引入服務總線的概念了：

 自動刷新總共有兩種方案：看下圖，但是1不怎麼靠譜，所以採用方案2：

 下面分別是方案1和2的思路流程圖：

 

開始改造:config服務端和客戶端都需要引入RabbitMQ：

 服務端3344改造： 

 

客戶端改造3355和3366一樣：

 

 

運維人員在github中如果修改或者變更了配置文件，首先3344是直接連接github的，3344會自動變更對應的配置文件，此時經過上面的配置之後，只需要發送一次POST請求刷新3344就ok,3355和3366也會自動刷新過來最新的配置文件。 

還可以自定義進行刷新：下圖

 第一個是全局通知，3355、3366都會刷新配置文件；第二個是局部刷新，只刷新了3355，其中config-client是服務名。