*作者：洛浩*

## 訊息典型應用場景

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d51863dc278c4fc4a15413c24b9bb8fe~tplv-k3u1fbpfcp-zoom-1.image "1.png")

阿里雲擁有豐富的訊息產品家族，除了 RocketMQ 以外，還有大家熟知的對標開源的雲 Kafka、支援 AMQP 協議的開源訊息佇列 RabbitMQ、物聯網通訊閘道器 MQTT、 對標 AWS SQS/SNS 的 Serverless 版訊息 MNS（現在也是輕量版 RocketMQ）以及雲上事件匯流排、事件中心 EeventBridge 。

阿里雲所有訊息產品均採用 RocketMQ 作為底層儲存引擎，為使用者提供穩定、可靠、高效能的訊息通訊能力，比如百萬 TPS、百萬佇列、毫秒級通訊延遲、分級儲存、 Serverless 彈性等眾多的訊息產品。也帶來了豐富的應用場景，分為應用整合和資料整合兩大類。

應用整合以 RocketMQ 為主，應用最為廣泛，本文也將分享 RocketMQ 在微服務解耦、電商交易、金融支付等場景下的最佳實踐，比如銀行的交易流水、保單的支付流轉等。RabbitMQ 、MQTT 也主要用於應用整合場景，比如物聯網、 IoT 雙向通訊、雲產品的事件通知以及後處理等。對於新建的業務場景，一般首推 RocketMQ 作為訊息選型，因為 RocketMQ 擁有最豐富的功能特性；而對於存量的業務遷移，則可以根據具體使用的訊息產品來進行選擇，以降低遷移成本。

資料整合以雲 Kafka 為主，在大資料分析、日誌採集分析等場景下應用最為廣泛，比如遊戲的玩家操作、廣告埋點、資料分析、應用資料監控等。各種 SaaS 類的整合、聚石塔、電商資料打通等場景，則主要使用 EventBridge。更多的產品選型對比，可以參考專題頁中的訊息佇列產品選型。

> <https:>

## 業務訊息使用場景

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f7c6c88732b649bc93751c28da27e685~tplv-k3u1fbpfcp-zoom-1.image "2.png")

RocketMQ 經過阿里集團內部十年錘鍊，經過雙 11 大促等萬億級規模的實時場景驗證，SLA 最高可支援 4 個9，資料可靠性支援 9 個9。

以微服務解耦、訂單交易、金融支付等場景為例，在網際網路、電商、零售、金融等行業，訊息的使用量非常大。尤其是在秒殺大促時，為了保障系統的穩定執行，需要 RocketMQ 進行削峰填谷。另外金融客戶對每筆交易、每個訂單也都要求資料不能丟失。因此在此類場景普遍對訊息的可靠傳輸、海量併發、低延遲、穩定性與容災等有著非常高的要求。RocketMQ 提供了豐富的訊息型別，比如事務訊息、定時訊息、順序訊息等。

在交易系統裡，為了簡化交易流程，一般使用事務訊息和定時訊息。同時 RocketMQ 也提供了訊息軌跡查詢、訊息 dashboard ，可以非常方便地對每個訊息進行回溯，對每個 topic 或者 group 進行監測。RocketMQ 5.0 也提供了豐富的例項規格，從百級別 QPS 到百萬級 QPS ，可以覆蓋大部分應用場景。RocketMQ 預設提供多副本、多可用區部署，也提供了跨地域訊息路由能力，支援客戶構建高可用容災或多活，且 RocketMQ 能夠支援 99.9%的訊息 RT 在 10ms 傳輸。

## RocketMQ 事務訊息舉例

### 實現訂單狀態機非同步流轉

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6cd5197665904b23b9bdaec467979aae~tplv-k3u1fbpfcp-zoom-1.image "3.png")

以訂單狀態機非同步流轉為例。此前，如果收到一筆訂單交易，需要逐個通知下游的服務模組，比如需要更新購物車、更新積分等。每個業務模組耦合在一起會導致大促時的流量峰值非常大，需要每個服務模組保障其處理效能。而基於 RocketMQ 的事務訊息能力，即可輕鬆實現訂單子流程系統的非同步解耦和流量的削峰填谷，事務訊息可以確保資料庫訂單狀態持久化和下游通知的事務性。

收到 LBL 訂單交易時，可以先向 RocketMQ 傳送一條半事務訊息，此時 RocketMQ 會 hold 住訊息，等核心交易事務完成後再向 MQ 提交確認半事務訊息的狀態，並執行下游服務模組的通知。假設核心交易模組失敗，則會廢棄之前提交的半事務訊息，不通知下游。

對比此前的傳統事務模組，使用 RocketMQ 可以大幅簡化交易鏈路，縮短下單耗時。尤其是在大促場景下，可以解耦下游的服務模組，提供削峰填谷的能力。

### 超時中心

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d3ba8fc522b74ee8a0226f86267f77ec~tplv-k3u1fbpfcp-zoom-1.image "4.png")

RocketMQ 的定時訊息場景也是常見的使用方式。

比如雙 11 等大促場景存在大量預售訂單、定點尾款等，會帶來大量定時任務。在電商交易過程中，訂單流轉也存在多個超時狀態的任務，處理超時狀態的任務需要確保可靠及時。以傳統的方案進行構建分散式排程機制實現的時候，比如基於定時器排程延遲大,可能會存在效能瓶頸。

而採用 RocketMQ 的定時訊息，實現將變得非常簡單。定時任務只需提交一條延遲訊息到 RocketMQ ，由 RocketMQ 保障定時訊息達到秒級的精度，最高可支援百萬級別的 TPS 能力，同時也能支援訊息的消費重試，保障任務可靠觸發，相比傳統的使用方式大大簡化了定時的複雜度。

## RocketMQ 灰度策略舉例

### 微服務全鏈路灰度

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/865953641eac442daa84a2cb0a47c8cb~tplv-k3u1fbpfcp-zoom-1.image "5.png")

微服務場景下，精準地控制灰度流量並進行灰度版本驗證，是保障線上業務穩定執行的關鍵。大部分情況下，使用者透過劃分不同的環境來進行灰度釋出，對應 RocketMQ 的不同例項。但是很多使用者希望能夠簡化環境管理，儘可能複用線上資源，結合訊息來提供微服務全鏈路灰度能力。如上圖所示，線上已經在執行的微服務模組遊 A、B、C，C 模組會產生訊息，並由 A 模組進行消費。此時對服務模組 A 和 C 做灰度釋出，則線上會存在兩條泳道，一條是正常的業務流量，一條是灰度鏈路。我們希望線上版本 C 模組生產的訊息能夠被線上版本 A 模組進行消費，灰度版本 C 模組生產的訊息能夠被灰度版本 A 模組進行消費。RocketMQ 支援透傳環境標籤，可在生產端給訊息屬性新增標籤，然後開啟 RocketMQ 的 SQL 92 語法過濾，服務端即可完成訊息的過濾和路由，從而降低客戶端的壓力。本文講述了 RocketMQ 的業務訊息場景、一些功能特性的使用方法，包括事務訊息、定時訊息、訊息全鏈路灰度等，歡迎大家嘗試使用，如果您對 RocktMQ 的業務訊息感興趣，也歡迎您掃描下方二維碼加入釘釘群一起溝通交流～

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/34db1b3396f34ea0bf2ed3220444dd99~tplv-k3u1fbpfcp-zoom-1.image "6.png")

點選[此處](https://www.aliyun.com/product/rocketmq)，進入官網瞭解更多詳情～</https:>

行業實踐：RocketMQ 業務整合典型行業應用和實踐

相關文章