Apache RocketMQ 作為阿里開源的業務訊息的首選，通過雙11業務打磨，在訊息和流處理領域被廣泛應用。而微服務生態Spring框架也是業務開發中最受開發者歡迎的框架之一，兩者的完美契合使得RocketMQ成為Spring Messaing實現中最受歡迎的訊息實現。

在Spring生態中使用RocketMQ到底有多少種方式？他們各自適用於什麼場景？各自有什麼優劣勢？

如何開始實戰？本書將一一解答。

我們先會帶領各位開發者：

• 回顧羅美琪（RocketMQ）和春波特（SpringBoot）故事開始的時候，rocketmq-spring經過6個多月的孵化，作為Apache RocketMQ的子專案正式畢業。
• 回顧rocketmq-spring畢業後的兩年，是如何成為Spring 生態中最受歡迎的 messaging 實現的？

最後將通過圖文和實操地方式帶來給位開發者玩轉在Spring生態中使用RocketMQ的三種主流方式。

RocketMQ與Spring的碰撞

在介紹RocketMQ與Spring故事之前，不得不提到Spring中的兩個關於訊息的框架，Spring Messaging和Spring Cloud Stream。它們都能夠與Spring Boot整合並提供了一些參考的實現。和所有的實現框架一樣，訊息框架的目的是實現輕量級的訊息驅動的微服務，可以有效地簡化開發人員對訊息中介軟體的使用複雜度，讓系統開發人員可以有更多的精力關注於核心業務邏輯的處理。

Spring Messaging

Spring Messaging是Spring Framework 4中新增的模組，是Spring與訊息系統整合的一個擴充套件性的支援。它實現了從基於JmsTemplate的簡單的使用JMS介面到非同步接收訊息的一整套完整的基礎架構，Spring AMQP提供了該協議所要求的類似的功能集。 在與Spring Boot的整合後，它擁有了自動配置能力，能夠在測試和執行時與相應的訊息傳遞系統進行整合。

單純對於客戶端而言，Spring Messaging提供了一套抽象的API或者說是約定的標準，對訊息傳送端和訊息接收端的模式進行規定，比如訊息 Messaging 對應的模型就包括一個訊息體 Payload 和訊息頭 Header。不同的訊息中介軟體提供商可以在這個模式下提供自己的Spring實現：在訊息傳送端需要實現的是一個XXXTemplate形式的Java Bean，結合Spring Boot的自動化配置選項提供多個不同的傳送訊息方法；在訊息的消費端是一個XXXMessageListener介面（實現方式通常會使用一個註解來宣告一個訊息驅動的POJO），提供回撥方法來監聽和消費訊息，這個介面同樣可以使用Spring Boot的自動化選項和一些定製化的屬性。

 在Apache RocketMQ生態中，RocketMQ-Spring-Boot-Starter（下文簡稱RocketMQ-Spring）就是一個支援Spring Messaging API標準的專案。該專案把RocketMQ的客戶端使用Spring Boot的方式進行了封裝，可以讓使用者通過簡單的annotation和標準的Spring Messaging API編寫程式碼來進行訊息的傳送和消費，也支援擴展出RocketMQ原生API來支援更加豐富的訊息型別。在RocketMQ-Spring畢業初期，RocketMQ社群同學請Spring社群的同學對RocketMQ-Spring程式碼進行review，引出一段羅美琪（RocketMQ）和春波特（Spring Boot）故事的佳話[1]，著名Spring佈道師Josh Long向國外同學介紹如何使用RocketMQ-Spring收發訊息[2]。RocketMQ-Spring也在短短兩年時間超越Spring-Kafka和Spring-AMQP（注:兩者均由Spring社群維護），成為Spring Messaging生態中最活躍的訊息專案。

Spring Cloud Stream

Spring Cloud Stream結合了Spring Integration的註解和功能，它的應用模型如下：

Spring Cloud Stream框架中提供一個獨立的應用核心，它通過輸入(@Input)和輸出(@Output)通道與外部世界進行通訊，訊息源端(Source)通過輸入通道傳送訊息，消費目標端(Sink)通過監聽輸出通道來獲取消費的訊息。這些通道通過專用的Binder實現與外部代理連線。開發人員的程式碼只需要針對應用核心提供的固定的介面和註解方式進行程式設計，而不需要關心執行時具體的Binder繫結的訊息中介軟體。

在執行時，Spring Cloud Stream能夠自動探測並使用在classpath下找到的Binder。這樣開發人員可以輕鬆地在相同的程式碼中使用不同型別的中介軟體：僅僅需要在構建時包含進不同的Binder。在更加複雜的使用場景中，也可以在應用中打包多個Binder並讓它自己選擇Binder，甚至在執行時為不同的通道使用不同的Binder。

Binder抽象使得Spring Cloud Stream應用可以靈活的連線到中介軟體，加之Spring Cloud Stream使用利用了Spring Boot的靈活配置配置能力，這樣的配置可以通過外部配置的屬性和Spring Boot支援的任何形式來提供（包括應用啟動引數、環境變數和application.yml或者application.properties檔案），部署人員可以在執行時動態選擇通道連線destination（例如，RocketMQ的topic或者RabbitMQ的exchange）。

Spring Cloud Stream 遮蔽了底層訊息中介軟體的實現細節，希望以統一的一套 API 來進行訊息的傳送/消費，底層訊息中介軟體的實現細節由各訊息中介軟體的 Binder 完成。Spring官方實現了Rabbit binder和Kafka Binder。Spring Cloud Alibaba實現了RocketMQ Binder[3]，其主要實現原理是把傳送訊息最終代理給了RocketMQ-Spring的RocketMQTemplate，在消費端則內部會啟動RocketMQ-Spring Consumer Container 來接收訊息。以此為基礎，Spring Cloud Alibaba還實現了Spring Cloud Bus RocketMQ， 使用者可以使用RocketMQ作為Spring Cloud 體系內的訊息匯流排，來連線分散式系統的所有節點。通過Spring Cloud Stream RocketMQ Binder，RocketMQ可以與Spring Cloud生態更好的結合。比如與 Spring Cloud Data Flow、Spring Cloud Funtion結合，讓RocketMQ可以在Spring流計算生態、Serverless(FaaS)專案中被使用。

如今Spring Cloud Stream RocketMQ Binder和Spring Cloud Bus RocketMQ做為Spring Cloud Alibaba的實現已登陸Spring的官網[4]，Spring Cloud Alibaba也成為Spring Cloud 最活躍的實現。

如何在Spring生態中選擇RocketMQ實現？

通過介紹Spring中的訊息框架，介紹了以RocketMQ為基礎與Spring訊息框架結合的幾個專案，主要是RocketMQ-Spring、Spring Cloud Stream RocketMQ Binder、Spring Cloud Bus RocketMQ、Spring Data Flow和Spring Cloud Function。它們之間的關係可以如下圖表示。

 如何在實際業務開發中選擇相應專案進行使用？下表列出了每個專案的特點和使用場景。

RocketMQ作為業務訊息的首選，在訊息和流處理領域被廣泛應用。而微服務生態Spring框架也是業務開發中最被，兩者的完美契合使得RocketMQ成為Spring Messaing實現中最受歡迎的訊息實現。書的後半部分講給各位開發者詳細講述在Spring生態中使用RocketMQ的三種主流的方式。

轉載：https://developer.aliyun.com/article/783533?utm_content=g_1000262850