一、簡介

在微服務架構的系統中，我們通常會使用輕量級的訊息代理來構建一個共用的訊息主題讓系統中所有微服務例項都連線上來，由於該主題中產生的訊息會被所有例項監聽和消費，所以我們稱它為訊息匯流排。

二、訊息代理

訊息代理(Message Broker)是一種訊息驗證、傳輸、路由的架構模式。它在應用程式之間起到通訊排程並最小化應用之間的依賴的作用，使得應用程式可以高效地解耦通訊過程。訊息代理是一箇中間件產品，它的核心是一個訊息的路由程式，用來實現接收和分發訊息， 並根據設定好的訊息處理流來轉發給正確的應用。 它包括獨立的通訊和訊息傳遞協
議，能夠實現組織內部和組織間的網路通訊。設計代理的目的就是為了能夠從應用程式中傳入訊息，並執行一些特別的操作，下面這些是在企業應用中，我們經常需要使用訊息代理的場景：

• 將訊息路由到一個或多個目的地。
• 訊息轉化為其他的表現方式。
  
• 執行訊息的聚集、訊息的分解，並將結果傳送到它們的目的地，然後重新組合響應返回給訊息使用者。
  
• 呼叫Web服務來檢索資料。
  
• 響應事件或錯誤。
  
• 使用釋出－訂閱模式來提供內容或基千主題的訊息路由。
  

• ActiveMQ
• Kafka
  
• RabbitMQ
  
• RocketMQ
  
• 等......

三、SpringCloud+RabbitMQ

（1）RabbitMQ簡介、安裝不贅述。

（2）pom.xml

<dependencies>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-amqp</artifactId>
	</dependency>

	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-test</artifactId>
		<scope>test</scope>
	</dependency>
</dependencies>
 

spring:
  application:
    name: rabbitmq-hello
  rabbitmq:
    host: ***.***.***.***
    port: 5672
    username: guest
    password: guest

@Component
public class Sender {

    private static final Logger log = LoggerFactory.getLogger(Sender.class);
    @Autowired
    private AmqpTemplate amqpTemplate;

    public void send() {
        String context = "hello " + new Date();
        log.info("Sender : " + context);
        this.amqpTemplate.convertAndSend("hello", context);
    }
}
 

@Component
@RabbitListener(queues = "hello")
public class Receiver {

    private static final Logger log = LoggerFactory.getLogger(Receiver.class);

    @RabbitHandler
    public void process(String hello) {
        log.info("Receiver : " + hello);
    }
}

@Configuration
public class RabbitConfig {

    @Bean
    public Queue helloQueue(){
        return new Queue("hello");
    }
}

@RunWith(SpringJUnit4ClassRunner.class)
@SpringBootTest(classes = SpringcloudbusrabbitmqApplication.class)
public class HelloApplicationTests {

    @Autowired
    private Sender sender;

    @Test
    public void hello() throws Exception {
        sender.send();
    }
}

（9）訪問host:15672

四、改造Config-Client（整合springcloud bus）

（1）pom.xml

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

	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-test</artifactId>
		<scope>test</scope>
	</dependency>
</dependencies>

spring.application.name=configspace
spring.cloud.config.label=master
spring.cloud.config.profile=dev
spring.cloud.config.uri= http://localhost:5588/
eureka.client.serviceUrl.defaultZone=http://localhost:5555/eureka/

server.port=5589

spring.rabbitmq.host=118.89.237.88
spring.rabbitmq.port= 5672
spring.rabbitmq.username=guest
spring.rabbitmq.password=guest

management.security.enabled=false

五、測試

（1）測試準備

1. 一個服務註冊中心，EUREKASERVER，埠為5555；
2. 一個分散式配置中心，ConfigServer，埠為5588；
3. 二個分散式配置，ConfigClient，埠為5589、5590；

（3）訪問http://localhost:5590/from

RabbitMQ：

（4）去倉庫修改password的值

from=git-dev-v1.0 by springcloud config-server
username=springcloud
password=1234567890

• 成功請求後config-client會重新讀取配置檔案

（6）再次訪問

• 如果POST請求的是：http://localhost:5589/bus/refresh，請訪問http://localhost:5590/from
• 如果訪問出現401，則配置需要加上management.security.enabled=false

• 如果POST請求的是：http://localhost:5590/bus/refresh，請訪問http://localhost:5589/from

• 另/bus/refresh介面可以指定服務，即使用“username”引數，比如 “/bus/refresh?destination=username:**”即重新整理服務名為username的所有服務，不管ip地址。

（7）架構

（8）架構調整

既然SpringCloud Bus的/bus/refresh介面提供了針對服務和例項進行配置更新的引數，那麼我們的架構也可以相應做出一些調整。在之前的架構中，服務的配置更新需要通過向具體服務中的某個例項傳送請求，再觸發對整個服務叢集的配置更新。雖然能實現功能，但是這樣的結果是，我們指定的應用例項會不同千叢集中的其他應用例項，這樣會增加叢集內部的複雜度，不利於將來的運維工作。比如， 需要對服務例項進行遷移，那麼我們不得不修改Web Hook中的配置等。所以要儘可能地讓服務叢集中的各個節點是對等的。

因此， 我們將之前的架構做了 一些調整， 如下圖所示：

主要做了以下這些改動：

1. 在ConfigServer中也引入SpringCloud Bus,將配置服務端也加入到訊息匯流排中來。
2. /bus/refresh請求不再發送到具體服務例項上，而是傳送給Config Server,並通過des巨nation引數來指定需要更新配置的服務或例項。

參考資料《Spring Cloud微服務實戰》

新手一枚，歡迎拍磚~ ~ ~