springcloud(九)：配置中心和訊息匯流排（配置中心終結版）

我們在springcloud(七)：配置中心svn示例和refresh中講到，如果需要客戶端獲取到最新的配置資訊需要執行refresh，我們可以利用webhook的機制每次提交程式碼傳送請求來重新整理客戶端，當客戶端越來越多的時候，需要每個客戶端都執行一遍，這種方案就不太適合了。使用Spring Cloud Bus可以完美解決這一問題。

Spring Cloud Bus

Spring cloud bus通過輕量訊息代理連線各個分佈的節點。這會用在廣播狀態的變化（例如配置變化）或者其他的訊息指令。Spring bus的一個核心思想是通過分散式的啟動器對spring boot應用進行擴充套件，也可以用來建立一個多個應用之間的通訊頻道。目前唯一實現的方式是用AMQP訊息代理作為通道，同樣特性的設定（有些取決於通道的設定）在更多通道的文件中。

Spring cloud bus被國內很多都翻譯為訊息匯流排，也挺形象的。大家可以將它理解為管理和傳播所有分散式專案中的訊息既可，其實本質是利用了MQ的廣播機制在分散式的系統中傳播訊息，目前常用的有Kafka和RabbitMQ。利用bus的機制可以做很多的事情，其中配置中心客戶端重新整理就是典型的應用場景之一，我們用一張圖來描述bus在配置中心使用的機制。

根據此圖我們可以看出利用Spring Cloud Bus做配置更新的步驟:

1、提交程式碼觸發post給客戶端A傳送bus/refresh
2、客戶端A接收到請求從Server端更新配置並且傳送給Spring Cloud Bus
3、Spring Cloud bus接到訊息並通知給其它客戶端

4、其它客戶端接收到通知，請求Server端獲取最新配置
5、全部客戶端均獲取到最新的配置

專案示例

我們選擇上一篇文章springcloud(八)：配置中心服務化和高可用版本的示例程式碼來改造,MQ我們使用RabbitMQ來做示例。

客戶端spring-cloud-config-client改造

1、新增依賴

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

需要多引入spring-cloud-starter-bus-amqp包，增加對訊息匯流排的支援

2、配置檔案

## 重新整理時，關閉安全驗證
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的相關配置，這樣客戶端程式碼就改造完成了。

3、測試

依次啟動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專案的埠為8003、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做配置更新步驟如下:

1、提交程式碼觸發post請求給bus/refresh
2、server端接收到請求併發送給Spring Cloud Bus
3、Spring Cloud bus接到訊息並通知給其它客戶端
4、其它客戶端接收到通知，請求Server端獲取最新配置
5、全部客戶端均獲取到最新的配置

這樣的話我們在server端的程式碼做一些改動，來支援bus/refresh

1、新增依賴

<dependencies>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-config-server</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-starter-bus-amqp</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-starter-eureka</artifactId>
	</dependency>
</dependencies>

需要多引入spring-cloud-starter-bus-amqp包，增加對訊息匯流排的支援

2、配置檔案

server:
  port: 8001
spring:
  application:
    name: spring-cloud-config-server
  cloud:
    config:
      server:
        git:
          uri: https://github.com/ityouknow/spring-cloud-starter/     # 配置git倉庫的地址
          search-paths: config-repo                             # git倉庫地址下的相對地址，可以配置多個，用,分割。
          username: username                                        # git倉庫的賬號
          password: password                                    # git倉庫的密碼
  rabbitmq:
    host: 192.168.0.6
    port: 5672
    username: admin
    password: 123456

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8000/eureka/   ## 註冊中心eurka地址


management:
  security:
     enabled: false

配置檔案增加RebbitMq的相關配置，關閉安全驗證。這樣server端程式碼就改造完成了。

3、測試

依次啟動spring-cloud-eureka、spring-cloud-config-server、spring-cloud-config-client專案，改動spring-cloud-config-client專案埠為8003、8004依次啟動。測試環境準備完成。

按照上面的測試方式，訪問server端和三個客戶端測試均可以正確返回資訊。同樣修改neo-config-dev.properties中neo.hello的值為hello im dev update並提交到程式碼庫中。在win下使用下面命令來模擬webhook觸發server端bus/refresh.

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

其它

區域性重新整理

某些場景下（例如灰度釋出），我們可能只想重新整理部分微服務的配置，此時可通過/bus/refresh端點的destination引數來定位要重新整理的應用程式。

例如：/bus/refresh?destination=customers:8000，這樣訊息總線上的微服務例項就會根據destination引數的值來判斷是否需要要重新整理。其中，customers:8000指的是各個微服務的ApplicationContext ID。

destination引數也可以用來定位特定的微服務。例如：/bus/refresh?destination=customers:**，這樣就可以觸發customers微服務所有例項的配置重新整理。

跟蹤匯流排事件

一些場景下，我們可能希望知道Spring Cloud Bus事件傳播的細節。此時，我們可以跟蹤匯流排事件（RemoteApplicationEvent的子類都是匯流排事件）。

跟蹤匯流排事件非常簡單，只需設定spring.cloud.bus.trace.enabled=true，這樣在/bus/refresh端點被請求後，訪問/trace端點就可獲得類似如下的結果：

{
  "timestamp": 1495851419032,
  "info": {
    "signal": "spring.cloud.bus.ack",
    "type": "RefreshRemoteApplicationEvent",
    "id": "c4d374b7-58ea-4928-a312-31984def293b",
    "origin": "stores:8002",
    "destination": "*:**"
  }
  },
  {
  "timestamp": 1495851419033,
  "info": {
    "signal": "spring.cloud.bus.sent",
    "type": "RefreshRemoteApplicationEvent",
    "id": "c4d374b7-58ea-4928-a312-31984def293b",
    "origin": "spring-cloud-config-client:8001",
    "destination": "*:**"
  }
  },
  {
  "timestamp": 1495851422175,
  "info": {
    "signal": "spring.cloud.bus.ack",
    "type": "RefreshRemoteApplicationEvent",
    "id": "c4d374b7-58ea-4928-a312-31984def293b",
    "origin": "customers:8001",
    "destination": "*:**"
  }
}

這個日誌顯示了customers:8001發出了RefreshRemoteApplicationEvent事件，廣播給所有的服務，被customers:9000和stores:8081接受到了。想要對接受到的訊息自定義自己的處理方式的話，可以新增@EventListener註解的AckRemoteApplicationEvent和SentApplicationEvent型別到你自己的應用中。或者到TraceRepository類中，直接處理資料。

這樣，我們就可清晰地知道事件的傳播細節。

`/bus/refresh` BUG

/bus/refresh 有一個很嚴重的BUG，一直沒有解決：對客戶端執行/bus/refresh之後，掛到匯流排的上的客戶端都會從Eureka註冊中心撤銷登記；如果對server端執行/bus/refresh,server端也會從Eureka註冊中心撤銷登記。再用白話解釋一下，就是本來人家在Eureka註冊中心註冊的好好的，只要你對著它執行一次/bus/refresh，立刻就會從Euraka中掛掉。

其實這個問題挺嚴重的，本來你利用/bus/refresh給所有的節點來更新配置資訊呢，結果把服務從Euraka中給搞掉了，那麼如果別人需要呼叫客戶端的服務的時候就直接歇菜了。不知道國內有童鞋公司在生產中用到這個功能沒有，用了不就很慘烈。在網上搜索了一下，國內網友和國外網友都遇到過很多次，但是一直沒有解決，很幸運就是我在寫這篇文章的前三天，Netflix修復了這個問題，使用Spring Cloud最新版本的包就可以解決這個問題。由此也可以發現Spring Cloud還在快速的發展中，最新的版本可能也會有一些不穩定性，可見路漫漫而修遠兮。

在pom中使用Spring Cloud的版本，解決這個bug.

<properties>
	<project.build.sourceEncoding>UTF-8
              
           
              
              
            
            相關推薦
			   
            
            
            
 

    

    
    Java B2B2C o2o多使用者商城 springcloud架構(九)：配置中心和訊息匯流排（配置中心終結版）
       
 
 Spring Cloud Bus 
 Spring cloud bus通過輕量訊息代理連線各個分佈的節點。這會用在廣播狀態的變化（例如配置變化）或者其他的訊息指令。Spring bus的一個核心思想是通過分散式的啟動器對spring boot應用進行擴充套件，也可以用來建立一個多個應用之間的通訊頻道 

  
 

    

    
    springcloud(九)：配置中心和訊息匯流排（配置中心終結版）
      我們在springcloud(七)：配置中心svn示例和refresh中講到，如果需要客戶端獲取到最新的配置資訊需要執行refresh，我們可以利用webhook的機制每次提交程式碼傳送請求來重新整理客戶端，當客戶端越來越多的時候，需要每個客戶端都執行一遍，這種方案就不太適合了。使用Spring Cloud  

  
 

    

    
    Spring Cloud：配置中心和訊息匯流排（終結版）（09）
       
 
 我們在springcloud(七)：配置中心svn示例和refresh中講到，如果需要客戶端獲取到最新的配置資訊需要執行refresh，我們可以利用webhook的機制每次提交程式碼傳送請求來重新整理客戶端，當客戶端越來越多的時候，需要每個客戶端都執行一遍，這種方案就不太適合了。使用Spring C 

  
 

    

    
    微服務SpringCloud之配置中心和訊息匯流排
       在微服務SpringCloud之Spring Cloud Config配置中心SVN部落格中每個client重新整理配置資訊時需要post請求/actuator/refresh,但客戶端越來越多時，，需要每個客戶端都執行一遍，這種方案就不太適合了。使用Spring Cloud Bus可以完美解決這 

  
 

    

    
    java B2B2C電子商務平臺分析之十一------配置中心和訊息匯流排
      Spring Cloud Bus 
Spring cloud bus通過輕量訊息代理連線各個分佈的節點。這會用在廣播狀態的變化（例如配置變化）或者其他的訊息指令。Spring bus的一個核心思想是通過分散式的啟動器對spring boot應用進行擴充套件，也可以用來建立一個多個應用之間的通訊頻道。目前唯一實 

  
 

    

    
    Spring Cloud（十二）配置中心和訊息匯流排
       
 
  
  
 Spring Cloud（十二）配置中心和訊息匯流排 
 Spring Cloud Bus 
 Spring cloud bus通過輕量訊息代理連線各個分佈的節點。這會用在廣播狀態的變化（例如配置變化）或者其他的訊息指令。Spring bus的一個核心思想是通過分散式的啟動器對sprin 

  
 

    

    
    quartznet任務排程和訊息排程（JAVA與C#版對比）
      
                
quartznet任務排程和訊息排程

1.  作用
自動執行任務。
2.  下載地址






NET版本


JAVA版本




1下載


http://quartznet.sourceforge.net/downlo 

  
 

    

    
    Java 8 新特性：Lambda 表示式之方法引用（Lambda 表示式補充版）
      
								
								            
						
                

方法引用

文 | 莫若吻     

（注：此文乃個人查詢資料然後學習總結的，若有不對的地方，請大家指出，非常感謝！）

1.方法引用簡述



方法引用是用來直接訪問類或者例項的已經存在的方法或 

  
 

    

    
    SpringCloud 配置中心Config和訊息匯流排Bus
      
                
一、概述
二、Config
三、Refresh
四、配置中心服務化
五、基於Webhook和訊息匯流排的解決方案
一、概述
SpringCloud配置中心包括Config和Bus兩個組成部分，只要這樣，才能保證主動推送。
下面主要分為四個部分，
Confi 

  
 

    

    
    SpringCloud學習系列之五-----配置中心(Config)和訊息匯流排(Bus)完美使用版
      
                                        
                                                前言
在上篇中介紹了SpringCloud Config的使用，本篇則介紹基於SpringCloud(基於SpringBoot2. 

  
 

    

    
    SpringCloud基於訊息匯流排的配置中心
      @https://www.cnblogs.com/ityouknow/p/6931958.html 
Spring Cloud Bus 
Spring cloud bus通過輕量訊息代理連線各個分佈的節點。這會用在廣播狀態的變化（例如配置變化）或者其他的訊息指令。Spring bus的一個核心思想是通過分散式 

  
 

    

    
    走進Spring Cloud之十一 SpringCloud bus 訊息匯流排重新整理配置（Greenwich版本）
       
  
  
 
 
  走進Spring Cloud之十一 SpringCloud bus 訊息匯流排重新整理配置（Greenwich版本）
  
   SpringCloud Bus
   改造config-client
   
    pom.xml
    bootstrap.yml
   
    

  
 

    

    
    SpringCloud04 服務配置中心、訊息匯流排、遠端配置動態重新整理
      
1 環境說明
　　JDK：1.8
　　MAVENT：3.5
　　SpringBoot：2.0.5.RELEASE
　　SpringCloud：Finchley.SR1


2 建立服務註冊中心（Eureka服務端）
　　說明：本博文僅僅以一個單例的註冊中心為例，高可用的服務註冊中心請參見
　　2.1 引入依 

  
 

    

    
    SpringCloud（十四）springCloud bus 訊息匯流排重新整理配置
      
                前言：     在微服務中，我們將使用輕量級訊息代理，通過一個共用的訊息主題，讓系統中所有微服務都連上來，主題中的訊息會被所有監聽者消費，所以稱為訊息匯流排。spring cloud bus將分散式節點用輕量級訊息連線起來，他可以用於服務間通訊，例如：配置檔案的更改。可以用k 

  
 

    

    
    跟我學SpringCloud | 第八篇：Spring Cloud Bus 訊息匯流排
      SpringCloud系列教程 | 第八篇：Spring Cloud Bus 訊息匯流排

Springboot: 2.1.6.RELEASE


SpringCloud: Greenwich.SR1


如無特殊說明，本系列教程全採用以上版本

前面兩篇文章我們聊了Spring Cloud Config配置 

  
 

    

    
    Chapter2 訊息匯流排 ConfigClient配置自動重新整理
       
 
 
 Chapter2 訊息匯流排ConfigClient配置自動重新整理
 Spring Cloud Bus：
 Spring Cloud Bus提供了批量重新整理配置的機制，它使用輕量級的訊息代理（例如RabbitMQ、Kafka等）連線分散式系統的節點，這樣就可以通過Spring Cloud B 

  
 

    

    
    Windows程式和訊息機制（三）：訊息與程序間通訊
       
 
  
  
  
 自定義訊息與程序間通訊 
  
  
 視窗程式可以接收自定義的訊息型別，前提是通訊的程序聲明瞭這種訊息型別，宣告的方法很簡單，WM_USER加一個值就可以了，一般加的值從0x400開始，其他的值已經被系統使用了。 
  
  
 實現一個完整的自定義訊息需要進行以下步驟： 
   

  
 

    

    
    Windows程式和訊息機制（二）：訊息有關的函式
       
 
  
  
  
 不同視窗程式可以通過訊息進行互動，主要用到的函式如下： 
  
  
 FindWindow 
  
  
 獲取一個視窗的控制代碼。 
  
  
 HWND FindWindow( LPCTSTR lpClassName,// 類名 LPCTSTR lpWindowName// 

  
 

    

    
    SpringCloud系列第09節之訊息匯流排Bus
      
                

其中提到，每次熱載入屬性時，都要逐次呼叫每個應用的 /refresh 介面（或者維護 Git 倉庫的 Webhooks）來觸發屬性更新

隨著系統的擴充，應用的增加，若所有的觸發動作都要手工去做（或者維護 Git 倉庫的 Webhooks），這是不人道的

所以我們希望配 

  
 

    

    
    十一：Spring Cloud 之訊息匯流排-
      
							
							
							
1. 簡介

Spring Cloud Bus links the nodes of a distributed system with a lightweight message broker. This broker can then be used to

springcloud(九)：配置中心和訊息匯流排（配置中心終結版）

Spring Cloud Bus

專案示例

1、新增依賴

2、配置檔案

3、測試

改進版本

1、新增依賴

2、配置檔案

3、測試

其它

區域性重新整理

跟蹤匯流排事件

/bus/refresh BUG

相關推薦

`/bus/refresh` BUG