RocketMQ 訊息整合：多型別業務訊息-普通訊息

引言

Apache RocketMQ 誕生至今，歷經十餘年大規模業務穩定性打磨，服務了 100% 阿里集團內部業務以及阿里雲數以萬計的企業客戶。作為金融級可靠的業務訊息方案，RocketMQ 從建立之初就一直專注於業務整合領域的非同步通訊能力構建。本篇將從業務整合場景的訴求開始，介紹 RocketMQ 作為業務訊息整合方案的核心能力和優勢，通過功能場景、應用案例以及最佳實踐等角度介紹 RocketMQ 普通訊息型別的使用。

關注【阿里云云原生】公眾號，回覆關鍵詞【普通訊息】獲取完整 PPT 下載地址！

說起業務整合場景，RocketMQ 最初的使用場景就是典型代表。RocketMQ 誕生於阿里的電商系統，電商系統經常需要做各種大促活動，在這類複雜需求場景下對訊息系統的吞吐效能、端到端延遲、削峰填谷等能力有著極高的要求。

一句話概括今天的核心問題，跑在核心交易業務鏈路的訊息有什麼特點，有什麼要求，和跑在離線分析等場景的訊息有什麼不同。下面和大家一起來探討～

業務整合 vs 資料整合

整合目標不同

做業務核心架構設計時，很多時候需要面向上層需求去完成業務邏輯的設計。以電商交易場景為例，通過微服務的拆分，可能在整個鏈路中會拆成很多個環節，不同應用之間通過訊息去整合時，更多的是關注使用者訂單的流轉過程，關注這個業務邏輯是否會正常的處理，這個就是業務整合。

對比一下，資料整合是以資料為中心，更多的是關注業務整合產生的資料，去分析這些業務資料的價值。資料整合並不關心這個資料是從哪裡來，只關心資料本身的屬性和資料之間的關係。

關注重點不同

在業務整合裡隨著企業業務邏輯的拓寬和複雜度的提升，呼叫和被呼叫方之間的耦合性會逐步增加，鏈路的拓撲也會變得越來越複雜。經常會出現一條訊息的上游是另一條訊息的下游，一個服務可能既是傳送方也是消費方，等等。

而在資料整合的場景裡面，並不關注上述鏈路，更多是關注資料的多樣性。也就是說，在做資料整合分析時，更多的是從各種異構的資料來源裡去提取、匯聚這些資料，然後把這些異構系統的資料聚合在一起做清洗，最終匯聚成結構化的資料或報表去做分析。資料整合更多是關注資料的異構性和多樣性。

實時性不同

業務整合簡單理解就是一種線上的邏輯，或者是一種強實時的邏輯。在這個業務整合領域，無論同步呼叫還是非同步呼叫，都對呼叫和被呼叫之間的響應協同機制有一定的要求。舉個例子，一個訂單的處理必須是要在毫秒級完成，否則使用者的體驗會非常的差。

但是在資料整合領域，更多的可能是近實時甚至是離線非實時的場景，也就是說通過批、實時流或近實時流的 場景去爬取資料之後做分析，具體鏈路對於使用者來說並不是可見的，這也是資料整合和業務整合側重點的差異。

業務整合對訊息系統的核心訴求

訊息佇列是企業業務整合的主要模式之一，它是一種非同步通訊模式。非同步模式提供了低耦合、高可靠、可觀測的非同步通訊能力。那麼業務整合鏈路裡使用訊息之後會帶來什麼效果呢？這裡稍微羅列一下。

上圖就是一個比較典型的上層的應用鏈路，從應用 A 到下層的應用 B 的一個單鏈路，通過傳送初始化或者結構化一個訊息，作為呼叫事件傳送到事件通道，這個通道就是訊息系統，比如 RocketMQ、RabbitMQ 等。在時間通道里儲存後通過過濾路由的分發元件匹配到下游，然後推送處理。與此同時，還會有可觀測、運維、監控的一些體系去支撐這個鏈路的可靠執行。

完整的功能需求非常多，這裡提煉業務整合對訊息系統的四個核心訴求：

1）多型別訊息傳輸：支援多樣業務場景整合訴求，主要包括普通訊息、定時訊息、事務訊息、順序訊息等；

2）豐富路由分發能力：支援多種分發路由條件，包括 Tag 過濾、訊息屬性過濾，一對多、一對一分發等；

3）多樣互動模式：支援收發訊息多樣互動方式，支援同步、非同步傳送，支援主動消費、被動推送消費，支援流式應答、單條應答；

4）可觀測體系：支援 Metrics、Trace、Events 分析，支援單鏈路、全鏈路軌跡追蹤，支援 Metrics 分析和監控告警，支援系統執行事件、業務事件透出處理。

RocketMQ 作為非常典型的業務訊息方案，正是對應上述業務整合的訴求，提供了完善的訊息功能、豐富的客戶端介面以及完善的可觀測體系和穩定性保障機制。

接下來就開始逐步拆解 RocketMQ 的多型別訊息，本篇主要介紹普通訊息。

普通訊息原理介紹

功能簡介

在多種訊息型別中，普通訊息是最簡單也最為重要。普通訊息是 RocketMQ 的基本訊息型別，提供高吞吐、擴充套件、低延遲、非同步的通訊能力。其他高階訊息型別基本都是在這種普通訊息型別的基礎上疊加了獨有的控制特性，或者是特定的使用的方式。

下面這張圖就是普通訊息的一個典型的拓撲，和訊息佇列典型場景一樣，生產者傳送訊息，傳送普通訊息到服務端去儲存，儲存完之後，會把訊息按照訂閱關係的匹配，最後推送給下游的消費方去做消費。

普通訊息的特點

1）原子性：訊息之間沒有關聯關係，收發處理邏輯原子；

2）擴充套件性：普通訊息容量、能力可擴充套件，支援多佇列儲存、水平拆分、併發消費；

3）低延遲：普通訊息鏈路短，互動簡單，狀態簡單，鏈路極簡，毫秒級低延遲通訊。

訊息的生命週期

普通訊息從初始化傳送開始到最終被處理的過程中會經歷多個狀態和過程，而瞭解訊息的生命週期，可以幫助我們去判斷線上出現問題後如何快速定位和解決。

簡單來說訊息的生命週期可以抽象成五個狀態：

• 初始化：普通訊息被生產者構建初始化完成，待發送到服務端的狀態；

• 待消費：訊息被傳輸到服務端，對下游可見，等待消費者獲取處理的狀態；

• 消費中：訊息被消費者獲取，並按照業務邏輯處理過程，此時服務端會等待消費完成，如果一定時間後沒有收到消費提交的事件，訊息還會重試處理；

• 消費提交：消費者完成訊息處理，並提交應答事件到服務端，服務端標記當前訊息已經被處理（包括消費成功和失敗）。RocketMQ預設支援所有訊息保留，此時訊息資料並不會立即被刪除，只是邏輯標記完成，在訊息被物理刪除之前，消費者仍然可以回溯重新處理訊息；

• 訊息刪除：RocketMQ 按照訊息儲存時間機制滾動清理最早的訊息資料，將訊息從物理檔案中刪除。

普通訊息應用場景和案例

簡單的瞭解原理和基本介紹之後，那普通訊息主要用在哪裡呢？普通訊息是RocketMQ應用最廣泛，使用規模最大的一種訊息型別，它主要集中在服務間的解耦呼叫，同時還有一些批量資料的採集傳輸等場景。

使用場景

1）微服務呼叫解耦

• 非同步化解耦：普通訊息實現微服務非同步呼叫，縮短業務流和響應時間。
• 流量削峰填谷：普通訊息海量堆積能力，解決流量峰值下游處理能力不足的穩定性風險。 

2）實時資料傳輸

• 高吞吐傳輸：普通訊息可以實現無限水平擴充套件，資料傳輸吞吐高，解決採集上報問題。
• 實時傳輸：普通訊息實時傳輸投遞，下游可以及時消費實現計算和分析。 

案例介紹

1）場景簡介

交易平臺是買賣家在線上根據約定的契約完成錢貨交換的過程涉及的系統。交易平臺涉及到和支付、物流、下單、運營等多個子系統的互動大多使用 RocketMQ 普通訊息做非同步解耦，訊息的可靠處理是電商大促保障的核心。

2）核心痛點

訂單狀態機複雜，需要縮短鏈路時間：訂單生命週期長，涉及下游多個子系統流轉，同步呼叫耗時長，使用者體驗差。

大促場景海量訂單處理，下游壓力大：大促場景訂單流量大，各子系統處理能力不足導致系統崩潰。

分散式場景訂單變化持久化和下游呼叫事務性：訂單狀態流轉需要確保資料庫狀態變更和下游呼叫同時成功或者失敗，即事務性。

快速上手收發訊息

說了這麼多場景和案例，直接看一下程式碼怎麼用。

傳送普通訊息

傳送訊息的流程非常簡單，但這其中需要注意以下幾點：

• 訊息初始化應儘可能完整：普通訊息初始化包括主題、Tag 標籤、索引 Key 和負載。可以按實際情況設定完成。
• 訊息傳送需要捕獲結果和異常：訊息傳送完成需要獲取響應結果，如果失敗需要捕獲異常並做重試處理。

消費普通訊息

RocketMQ 支援的消費方式有多種，有主動獲取的方式，也有被動消費監聽器推送的方式。

被動消費方式只需要註冊消費監聽器，然後監聽器內部去處理這個邏輯，最終返回消費結果。如果消費失敗，希望 RocketMQ 再做重投，就要返回一個失敗的結果；拋異常也是返回失敗。類似於這樣的結果，返回服務端就完成了整個消費的過程。

對於主動獲取的方式，會更加靈活，由業務方主動呼叫獲取訊息，可以按照自己的速率和併發取訊息，處理完成後，再回復 RocketMQ 服務端消費結果。

產品預告：新一代 RocketMQ 5.0 版例項

最後預告一下，阿里雲訊息佇列 RocketMQ 版在八月份釋出新版本，新版本具備更強彈性、更低成本、更易運維等特點，歡迎保持關注。

點選此處，進入官網瞭解更多詳情～