<本文已參與 RocketMQ Summit 優(yōu)秀案例征文活動，點此了解詳情>

緣起

對于Apache RocketMQ的了解，追溯起來，可以說是從開源初始，就認(rèn)識到了它。那時候的它，還是個幼年，沒有成熟的社區(qū)，也沒有好的機制去運作。本身，也不算是成熟的產(chǎn)品。

但是，在阿里強大的技術(shù)背景驅(qū)動下，隨著業(yè)務(wù)的支撐，它慢慢得到了長遠(yuǎn)的發(fā)展，更多的走向了大眾的視野，也慢慢成為了一款優(yōu)秀的消息隊列中間件。

在技術(shù)選型中，可以作為一名佼佼者，為各個技術(shù)負(fù)責(zé)人提供技術(shù)支持。

緣與業(yè)務(wù)

對于我司傳統(tǒng)的業(yè)務(wù)場景以及相關(guān)產(chǎn)品中，一般不會涉及到消息中間件的涉及。很有幸，公司的發(fā)展以及壯大，新的產(chǎn)品、新的業(yè)務(wù)場景進行了拓展。我司，也參與了智慧城市的相關(guān)業(yè)務(wù)場景建設(shè)。

很多的產(chǎn)品，屬于互聯(lián)網(wǎng)平臺，因此，對于消息隊列中間件的需求，就隨之誕生，也就比較迫切。借助消息隊列其減少相應(yīng)所需的時間和削峰，降低系統(tǒng)耦合性的相關(guān)特性，構(gòu)建更加健壯的平臺產(chǎn)品。

實踐從業(yè)務(wù)中來，到業(yè)務(wù)中去。本次分享便從一個企業(yè)服務(wù)平臺的建設(shè)才講述。

業(yè)務(wù)場景如下所示：

我司與政府大數(shù)據(jù)局，參與共建一個企業(yè)與企業(yè)、企業(yè)與政府之間互聯(lián)互通的、信息交互的一個新型互聯(lián)網(wǎng)平臺。平臺中，為企業(yè)提供了最便捷的溝通入口。

根據(jù)政府的需求，企業(yè)可以在線，實現(xiàn)政策申報、政策享受等一系列先進的、優(yōu)秀的、便捷、快速的政府服務(wù)。同時，企業(yè)在平臺中，跟其他企業(yè)可以實現(xiàn)在線服務(wù)申請、在線溝通。其中，平臺上企業(yè)個人中心中會有個模塊會消息中心。展示了，企業(yè)收到的來自各個方面的消息通知。

場景如下圖所示：

緣與技術(shù)

本身作為分布式消息業(yè)務(wù)需要，同時為了降低系統(tǒng)耦合性，選擇消息隊列中間件，來完成消息中心的建設(shè)。

技術(shù)選型

四種常用的分布式消息隊列開源軟件：Kafka、ActiveMQ、RabbitMQ?及?RocketMQ。

在分布式消息隊列的江湖里，Kafka 憑借其優(yōu)秀的性能占據(jù)重要一席。

Kafka 作為流平臺具有以下三種能力：

發(fā)布和訂閱記錄流，類似于消息隊列或企業(yè)消息系統(tǒng)；

具有容錯能力，且可以持久化的方式存儲記錄流；

當(dāng)記錄流產(chǎn)生時（發(fā)生時），可及時對其進行處理。

Kafka 適用于兩類應(yīng)用：

建立實時流數(shù)據(jù)管道，在系統(tǒng)或應(yīng)用之間可靠地獲取數(shù)據(jù)；

建立對數(shù)據(jù)流進行轉(zhuǎn)換或反應(yīng)的實時流應(yīng)用程序。

目前，Kafka更多的用于數(shù)據(jù)量大的大數(shù)據(jù)平臺項目。

ActiveMQ 由 Apache 出品，據(jù)官網(wǎng)介紹，它是最流行和最強大的開源消息總線。ActiveMQ 非?？焖?#xff0c;支持多種語言的客戶端和協(xié)議，而且可以非常容易地嵌入到企業(yè)的應(yīng)用環(huán)境中，并有許多高級功能。

ActiveMQ 基于 Java 語言開發(fā)，從使用的便捷性與開源程度，是可以承擔(dān)起更多的職責(zé)。但是，目前由于

社區(qū)活躍度較低，更新慢，增加維護成本；

網(wǎng)絡(luò)資料顯示，ActiveMQ 存在一些莫名其妙的問題，會丟失消息；

目前，官方將重心放到 ActiveMQ 6.0 下一代產(chǎn)品 Apollo 上，對 5.x 的維護較少；

不適合用于上千個隊列的應(yīng)用場景。

因此，不適合更新迭代速度的互聯(lián)網(wǎng)平臺。

RabbitMQ 是流行的開源消息隊列系統(tǒng)，支持多種客戶端，如 Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX、持久化。用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息，在易用性、擴展性、高可用性等方面表現(xiàn)不俗。但是，目前由于

盡管結(jié)合 Erlang 語言本身的并發(fā)優(yōu)勢，性能較好，但是不利于做二次開發(fā)和維護；

實現(xiàn)了代理架構(gòu)，意味著消息在發(fā)送到客戶端之前可以在中央節(jié)點上排隊。此特性使得 RabbitMQ 易于使用和部署，但使得其運行速度較慢，因為中央節(jié)點增加了延遲，消息封裝后也比較大；

需要學(xué)習(xí)比較復(fù)雜的接口和協(xié)議，學(xué)習(xí)和維護成本較高。

因此，綜合考慮沒有選擇。

RocketMQ 由阿里研發(fā)團隊開發(fā)的分布式隊列，側(cè)重于消息的順序投遞，具有高吞吐量、可靠性等特征。RocketMQ 與ActiveMQ一樣，用 Java 語言實現(xiàn)，在設(shè)計時參考了 Kafka，并做出了自己的改進，在消息可靠性上比 Kafka 更好，RocketMQ 已經(jīng)被業(yè)界多個大型互聯(lián)網(wǎng)公司采用。

所謂實踐是檢驗真理的唯一標(biāo)準(zhǔn)，實際應(yīng)用中的表現(xiàn)比文字更具說服力。在阿里內(nèi)部，RocketMQ 很好地服務(wù)了集團大大小小上千個應(yīng)用，在每年的雙十一當(dāng)天，更有不可思議的萬億級消息通過 RocketMQ 流轉(zhuǎn)（在 2017 年的雙 11 當(dāng)天，整個阿里巴巴集團通過 RocketMQ 流轉(zhuǎn)的線上消息達到了萬億級，峰值 TPS 達到 5600 萬），在阿里大中臺策略上發(fā)揮著舉足輕重的作用。

目前，社區(qū)活躍，開源程度高，本身經(jīng)得起業(yè)務(wù)場景的考驗，因此最終選型為RocketMQ。

部署架構(gòu)

RocketMQ支持部署場景的自定義，同時支持高可用的部署方案。

對于當(dāng)前平臺的建設(shè)，存在DMZ區(qū)、金宏網(wǎng)區(qū)網(wǎng)絡(luò)隔離環(huán)境。對于平臺的中間件部署存在一些復(fù)雜的網(wǎng)絡(luò)要求。

借用官網(wǎng)對于部署架構(gòu)的圖示：

對于我們在實踐中的部署，同樣采用了官方的部署實踐。采用了多Master、多Slave異步復(fù)制的方式，即使磁盤損壞，消息丟失得非常少，消息實時性不會受影響，因為 Master 宕機后，消費者仍然可以從 Slave 消費，此過程對應(yīng)用透明，不需要人工干預(yù)，性能同多 Master 模式幾乎一樣。

技術(shù)實現(xiàn)

對于RocketMQ的客戶端消費者、服務(wù)端生產(chǎn)者來講，采用Springboot作為技術(shù)開發(fā)框架，實現(xiàn)起來非常簡單。

引入對應(yīng)的POM依賴

<dependency><groupId>org.apache.rocketmq</groupId><artifactId>rocketmq-spring-boot-starter</artifactId><version>2.0.3</version> </dependency>

應(yīng)用配置文件修改

rocketmq:name-server: xxxx:9876producer:group: base_group_syncMsgsend-message-timeout: 5000retry-times-when-send-failed: 2max-message-size: 4194304

對應(yīng)的添加相關(guān)注解、實現(xiàn)業(yè)務(wù)代碼即可。

使用方便，功能強大，對于開發(fā)者來說非常友好，是一個很好的選擇。

緣與分布式事務(wù)

寫到這里，同時也描述下，采用了微服務(wù)技術(shù)解決方案后，在很多場景下，會產(chǎn)生分布式事務(wù)。那么，除了自實現(xiàn)，分布式事務(wù)框架，同時，我們可以采用消息隊列來實現(xiàn)。

在本次實踐中，我們有過進一步的實踐。在此，就不多說。

緣與未來

實踐看來，對于RocketMQ的落地過程中，雖有坎坷，但是達到了預(yù)想的效果。社區(qū)的文檔也是比較滿足實際落地需要，總體來說，是不錯的。

在此，也希望社區(qū)越做越好吧，未來可期。

總結(jié)

以上是生活随笔為你收集整理的Apache RocketMQ在我司的最佳实践--智慧政务场景下的分布式消息与分布式事务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。