springcloud(九)：配置中心和消息總線（配置中心終結版）

Spring Cloud Bus
Spring cloud bus經過輕量消息代理鏈接各個分佈的節點。這會用在廣播狀態的變化（例如配置變化）或者其餘的消息指令。Spring bus的一個核心思想是經過分佈式的啓動器對spring boot應用進行擴展，也能夠用來創建一個多個應用之間的通訊頻道。目前惟一實現的方式是用AMQP消息代理做爲通道，一樣特性的設置（有些取決於通道的設置）在更多通道的文檔中。

Spring cloud bus被國內不少都翻譯爲消息總線，也挺形象的。你們能夠將它理解爲管理和傳播全部分佈式項目中的消息既可，其實本質是利用了MQ的廣播機制在分佈式的系統中傳播消息，目前經常使用的有Kafka和RabbitMQ。利用bus的機制能夠作不少的事情，其中配置中心客戶端刷新就是典型的應用場景之一，咱們用一張圖來描述bus在配置中心使用的機制。

根據此圖咱們能夠看出利用Spring Cloud Bus作配置更新的步驟:

一、提交代碼觸發post給客戶端A發送bus/refresh
二、客戶端A接收到請求從Server端更新配置而且發送給Spring Cloud Bus
三、Spring Cloud bus接到消息並通知給其它客戶端
四、其它客戶端接收到通知，請求Server端獲取最新配置
五、所有客戶端均獲取到最新的配置
客戶端spring-cloud-config-client改造

一、添加依賴

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
</dependency>

須要多引入spring-cloud-starter-bus-amqp包，增長對消息總線的支持

二、配置文件

## 刷新時，關閉安全驗證
management.security.enabled=false
## 開啓消息跟蹤
spring.cloud.bus.trace.enabled=true
 
spring.rabbitmq.host=192.168.9.89
spring.rabbitmq.port=5672
spring.rabbitmq.username=admin
spring.rabbitmq.password=123456

配置文件須要增長RebbitMq的相關配置，這樣客戶端代碼就改造完成了。

三、測試
依次啓動spring-cloud-eureka、spring-cloud-config-server、spring-cloud-config-client項目，在啓動spring-cloud-config-client項目的時候咱們會發現啓動日誌會輸出這樣的一條記錄。

2017-05-26 17:05:38.568  INFO 21924 --- [           main] o.s.b.a.e.mvc.EndpointHandlerMapping     : Mapped "{[/bus/refresh],methods=[POST]}" onto public void org.springframework.cloud.bus.endpoint.RefreshBusEndpoint.refresh(java.lang.String)

說明客戶端已經具有了消息總線通知的能力了，爲了更好的模擬消息總線的效果，咱們更改客戶端spring-cloud-config-client項目的端口爲800三、8004依次啓動，這樣測試環境就準備好了。啓動後eureka後臺效果圖以下：

咱們先分別測試一下服務端和客戶端是否正確運行，訪問：http://localhost:8001/neo-config/dev，返回信息：
 

{
    "name": "neo-config", 
    "profiles": [
        "dev"
    ], 
    "label": null, 
    "version": null, 
    "state": null, 
    "propertySources": [
        {
            "name": "https://github.com/ityouknow/spring-cloud-starter/config-repo/neo-config-dev.properties", 
            "source": {
                "neo.hello": "hello im dev"
            }
        }
    ]
}

說明server端都正常讀取到了配置信息。

依次訪問：http://localhost:8002/hello、http://localhost:8003/hello、http://localhost:8004/hello，返回：hello im dev。說明客戶端都已經讀取到了server端的內容。

如今咱們更新neo-config-dev.properties 中neo.hello的值爲hello im dev update並提交到代碼庫中，訪問：http://localhost:8002/hello 依然返回hello im dev。咱們對端口爲8002的客戶端發送一個/bus/refresh的post請求。在win下使用下面命令來模擬webhook.
 

curl -X POST http://localhost:8002/bus/refresh

執行完成後，依次訪問：http://localhost:8002/hello、http://localhost:8003/hello、http://localhost:8004/hello，返回：hello im dev update。說明三個客戶端均已經拿到了最新配置文件的信息，這樣咱們就實現了圖一中的示例。

改進版本
在上面的流程中，咱們已經到達了利用消息總線觸發一個客戶端bus/refresh,而刷新全部客戶端的配置的目的。但這種方式並不優雅。緣由以下：

打破了微服務的職責單一性。微服務自己是業務模塊，它本不該該承擔配置刷新的職責。
破壞了微服務各節點的對等性。
有必定的侷限性。例如，微服務在遷移時，它的網絡地址經常會發生變化，此時若是想要作到自動刷新，那就不得不修改WebHook的配置。
所以咱們將上面的架構模式稍微改變一下

這時Spring Cloud Bus作配置更新步驟以下:

一、提交代碼觸發post請求給bus/refresh
二、server端接收到請求併發送給Spring Cloud Bus
三、Spring Cloud bus接到消息並通知給其它客戶端
四、其它客戶端接收到通知，請求Server端獲取最新配置
五、所有客戶端均獲取到最新的配置
這樣的話咱們在server端的代碼作一些改動，來支持bus/refresh

總體架構以下：

完整項目的源碼來源

願意瞭解框架技術或者源碼的朋友直接求求交流分享技術： 貳一四七七七五六叄叄