引言

Apache RocketMQ 誕生至今，歷經(jīng)十余年大規(guī)模業(yè)務(wù)穩(wěn)定性打磨，服務(wù)了 100% 阿里集團(tuán)內(nèi)部業(yè)務(wù)以及阿里云數(shù)以萬(wàn)計(jì)的企業(yè)客戶。作為金融級(jí)可靠的業(yè)務(wù)消息方案，RocketMQ 從創(chuàng)建之初就一直專注于業(yè)務(wù)集成領(lǐng)域的異步通信能力構(gòu)建。本篇將從業(yè)務(wù)集成場(chǎng)景的訴求開(kāi)始，介紹 RocketMQ 作為業(yè)務(wù)消息集成方案的核心能力和優(yōu)勢(shì)，通過(guò)功能場(chǎng)景、應(yīng)用案例以及最佳實(shí)踐等角度介紹 RocketMQ 普通消息類型的使用。

說(shuō)起業(yè)務(wù)集成場(chǎng)景，RocketMQ 最初的使用場(chǎng)景就是典型代表。RocketMQ 誕生于阿里的電商系統(tǒng)，電商系統(tǒng)經(jīng)常需要做各種大促活動(dòng)，在這類復(fù)雜需求場(chǎng)景下對(duì)消息系統(tǒng)的吞吐性能、端到端延遲、削峰填谷等能力有著極高的要求。

一句話概括今天的核心問(wèn)題，跑在核心交易業(yè)務(wù)鏈路的消息有什么特點(diǎn)，有什么要求，和跑在離線分析等場(chǎng)景的消息有什么不同。下面和大家一起來(lái)探討～

業(yè)務(wù)集成 vs 數(shù)據(jù)集成

集成目標(biāo)不同

做業(yè)務(wù)核心架構(gòu)設(shè)計(jì)時(shí)，很多時(shí)候需要面向上層需求去完成業(yè)務(wù)邏輯的設(shè)計(jì)。以電商交易場(chǎng)景為例，通過(guò)微服務(wù)的拆分，可能在整個(gè)鏈路中會(huì)拆成很多個(gè)環(huán)節(jié)，不同應(yīng)用之間通過(guò)消息去集成時(shí)，更多的是關(guān)注用戶訂單的流轉(zhuǎn)過(guò)程，關(guān)注這個(gè)業(yè)務(wù)邏輯是否會(huì)正常的處理，這個(gè)就是業(yè)務(wù)集成。

對(duì)比一下，數(shù)據(jù)集成是以數(shù)據(jù)為中心，更多的是關(guān)注業(yè)務(wù)集成產(chǎn)生的數(shù)據(jù)，去分析這些業(yè)務(wù)數(shù)據(jù)的價(jià)值。數(shù)據(jù)集成并不關(guān)心這個(gè)數(shù)據(jù)是從哪里來(lái)，只關(guān)心數(shù)據(jù)本身的屬性和數(shù)據(jù)之間的關(guān)系。

關(guān)注重點(diǎn)不同

在業(yè)務(wù)集成里隨著企業(yè)業(yè)務(wù)邏輯的拓寬和復(fù)雜度的提升，調(diào)用和被調(diào)用方之間的耦合性會(huì)逐步增加，鏈路的拓?fù)湟矔?huì)變得越來(lái)越復(fù)雜。經(jīng)常會(huì)出現(xiàn)一條消息的上游是另一條消息的下游，一個(gè)服務(wù)可能既是發(fā)送方也是消費(fèi)方，等等。

而在數(shù)據(jù)集成的場(chǎng)景里面，并不關(guān)注上述鏈路，更多是關(guān)注數(shù)據(jù)的多樣性。也就是說(shuō)，在做數(shù)據(jù)集成分析時(shí)，更多的是從各種異構(gòu)的數(shù)據(jù)源里去提取、匯聚這些數(shù)據(jù)，然后把這些異構(gòu)系統(tǒng)的數(shù)據(jù)聚合在一起做清洗，最終匯聚成結(jié)構(gòu)化的數(shù)據(jù)或報(bào)表去做分析。數(shù)據(jù)集成更多是關(guān)注數(shù)據(jù)的異構(gòu)性和多樣性。

實(shí)時(shí)性不同

業(yè)務(wù)集成簡(jiǎn)單理解就是一種在線的邏輯，或者是一種強(qiáng)實(shí)時(shí)的邏輯。在這個(gè)業(yè)務(wù)集成領(lǐng)域，無(wú)論同步調(diào)用還是異步調(diào)用，都對(duì)調(diào)用和被調(diào)用之間的響應(yīng)協(xié)同機(jī)制有一定的要求。舉個(gè)例子，一個(gè)訂單的處理必須是要在毫秒級(jí)完成，否則用戶的體驗(yàn)會(huì)非常的差。

但是在數(shù)據(jù)集成領(lǐng)域，更多的可能是近實(shí)時(shí)甚至是離線非實(shí)時(shí)的場(chǎng)景，也就是說(shuō)通過(guò)批、實(shí)時(shí)流或近實(shí)時(shí)流的 場(chǎng)景去爬取數(shù)據(jù)之后做分析，具體鏈路對(duì)于用戶來(lái)說(shuō)并不是可見(jiàn)的，這也是數(shù)據(jù)集成和業(yè)務(wù)集成側(cè)重點(diǎn)的差異。

業(yè)務(wù)集成對(duì)消息系統(tǒng)的核心訴求

消息隊(duì)列是企業(yè)業(yè)務(wù)集成的主要模式之一，它是一種異步通信模式。異步模式提供了低耦合、高可靠、可觀測(cè)的異步通信能力。那么業(yè)務(wù)集成鏈路里使用消息之后會(huì)帶來(lái)什么效果呢？這里稍微羅列一下。

上圖就是一個(gè)比較典型的上層的應(yīng)用鏈路，從應(yīng)用 A 到下層的應(yīng)用 B 的一個(gè)單鏈路，通過(guò)發(fā)送初始化或者結(jié)構(gòu)化一個(gè)消息，作為調(diào)用事件發(fā)送到事件通道，這個(gè)通道就是消息系統(tǒng)，比如 RocketMQ、RabbitMQ 等。在時(shí)間通道里存儲(chǔ)后通過(guò)過(guò)濾路由的分發(fā)組件匹配到下游，然后推送處理。與此同時(shí)，還會(huì)有可觀測(cè)、運(yùn)維、監(jiān)控的一些體系去支撐這個(gè)鏈路的可靠運(yùn)行。

完整的功能需求非常多，這里提煉業(yè)務(wù)集成對(duì)消息系統(tǒng)的四個(gè)核心訴求：

1）多類型消息傳輸：支持多樣業(yè)務(wù)場(chǎng)景集成訴求，主要包括普通消息、定時(shí)消息、事務(wù)消息、順序消息等；

2）豐富路由分發(fā)能力：支持多種分發(fā)路由條件，包括 Tag 過(guò)濾、消息屬性過(guò)濾，一對(duì)多、一對(duì)一分發(fā)等；

3）多樣交互模式：支持收發(fā)消息多樣交互方式，支持同步、異步發(fā)送，支持主動(dòng)消費(fèi)、被動(dòng)推送消費(fèi)，支持流式應(yīng)答、單條應(yīng)答；

4）可觀測(cè)體系：支持 Metrics、Trace、Events 分析，支持單鏈路、全鏈路軌跡追蹤，支持 Metrics 分析和監(jiān)控告警，支持系統(tǒng)運(yùn)行事件、業(yè)務(wù)事件透出處理。

RocketMQ 作為非常典型的業(yè)務(wù)消息方案，正是對(duì)應(yīng)上述業(yè)務(wù)集成的訴求，提供了完善的消息功能、豐富的客戶端接口以及完善的可觀測(cè)體系和穩(wěn)定性保障機(jī)制。

接下來(lái)就開(kāi)始逐步拆解 RocketMQ 的多類型消息，本篇主要介紹普通消息。

普通消息原理介紹

功能簡(jiǎn)介

在多種消息類型中，普通消息是最簡(jiǎn)單也最為重要。普通消息是 RocketMQ 的基本消息類型，提供高吞吐、擴(kuò)展、低延遲、異步的通信能力。其他高級(jí)消息類型基本都是在這種普通消息類型的基礎(chǔ)上疊加了獨(dú)有的控制特性，或者是特定的使用的方式。

下面這張圖就是普通消息的一個(gè)典型的拓?fù)?，和消息?duì)列典型場(chǎng)景一樣，生產(chǎn)者發(fā)送消息，發(fā)送普通消息到服務(wù)端去存儲(chǔ)，存儲(chǔ)完之后，會(huì)把消息按照訂閱關(guān)系的匹配，最后推送給下游的消費(fèi)方去做消費(fèi)。

普通消息的特點(diǎn)

1）原子性：消息之間沒(méi)有關(guān)聯(lián)關(guān)系，收發(fā)處理邏輯原子；

2）擴(kuò)展性：普通消息容量、能力可擴(kuò)展，支持多隊(duì)列存儲(chǔ)、水平拆分、并發(fā)消費(fèi)；

3）低延遲：普通消息鏈路短，交互簡(jiǎn)單，狀態(tài)簡(jiǎn)單，鏈路極簡(jiǎn)，毫秒級(jí)低延遲通信。

消息的生命周期

普通消息從初始化發(fā)送開(kāi)始到最終被處理的過(guò)程中會(huì)經(jīng)歷多個(gè)狀態(tài)和過(guò)程，而了解消息的生命周期，可以幫助我們?nèi)ヅ袛嗑€上出現(xiàn)問(wèn)題后如何快速定位和解決。

簡(jiǎn)單來(lái)說(shuō)消息的生命周期可以抽象成五個(gè)狀態(tài)：

• 初始化：普通消息被生產(chǎn)者構(gòu)建初始化完成，待發(fā)送到服務(wù)端的狀態(tài)；
• 待消費(fèi)：消息被傳輸?shù)椒?wù)端，對(duì)下游可見(jiàn)，等待消費(fèi)者獲取處理的狀態(tài)；
• 消費(fèi)中：消息被消費(fèi)者獲取，并按照業(yè)務(wù)邏輯處理過(guò)程，此時(shí)服務(wù)端會(huì)等待消費(fèi)完成，如果一定時(shí)間后沒(méi)有收到消費(fèi)提交的事件，消息還會(huì)重試處理；
• 消費(fèi)提交：消費(fèi)者完成消息處理，并提交應(yīng)答事件到服務(wù)端，服務(wù)端標(biāo)記當(dāng)前消息已經(jīng)被處理（包括消費(fèi)成功和失?。?。RocketMQ默認(rèn)支持所有消息保留，此時(shí)消息數(shù)據(jù)并不會(huì)立即被刪除，只是邏輯標(biāo)記完成，在消息被物理刪除之前，消費(fèi)者仍然可以回溯重新處理消息；
• 消息刪除：RocketMQ 按照消息保存時(shí)間機(jī)制滾動(dòng)清理最早的消息數(shù)據(jù)，將消息從物理文件中刪除。

普通消息應(yīng)用場(chǎng)景和案例

簡(jiǎn)單的了解原理和基本介紹之后，那普通消息主要用在哪里呢？普通消息是RocketMQ應(yīng)用最廣泛，使用規(guī)模最大的一種消息類型，它主要集中在服務(wù)間的解耦調(diào)用，同時(shí)還有一些批量數(shù)據(jù)的采集傳輸?shù)葓?chǎng)景。

使用場(chǎng)景

1）微服務(wù)調(diào)用解耦

• 異步化解耦：普通消息實(shí)現(xiàn)微服務(wù)異步調(diào)用，縮短業(yè)務(wù)流和響應(yīng)時(shí)間。
• 流量削峰填谷：普通消息海量堆積能力，解決流量峰值下游處理能力不足的穩(wěn)定性風(fēng)險(xiǎn)。

2）實(shí)時(shí)數(shù)據(jù)傳輸

• 高吞吐傳輸：普通消息可以實(shí)現(xiàn)無(wú)限水平擴(kuò)展，數(shù)據(jù)傳輸吞吐高，解決采集上報(bào)問(wèn)題。
• 實(shí)時(shí)傳輸：普通消息實(shí)時(shí)傳輸投遞，下游可以及時(shí)消費(fèi)實(shí)現(xiàn)計(jì)算和分析。

案例介紹

1）場(chǎng)景簡(jiǎn)介

交易平臺(tái)是買賣家在線上根據(jù)約定的契約完成錢貨交換的過(guò)程涉及的系統(tǒng)。交易平臺(tái)涉及到和支付、物流、下單、運(yùn)營(yíng)等多個(gè)子系統(tǒng)的交互大多使用 RocketMQ 普通消息做異步解耦，消息的可靠處理是電商大促保障的核心。

2）核心痛點(diǎn)

訂單狀態(tài)機(jī)復(fù)雜，需要縮短鏈路時(shí)間：訂單生命周期長(zhǎng)，涉及下游多個(gè)子系統(tǒng)流轉(zhuǎn)，同步調(diào)用耗時(shí)長(zhǎng)，用戶體驗(yàn)差。

大促場(chǎng)景海量訂單處理，下游壓力大：大促場(chǎng)景訂單流量大，各子系統(tǒng)處理能力不足導(dǎo)致系統(tǒng)崩潰。

分布式場(chǎng)景訂單變化持久化和下游調(diào)用事務(wù)性：訂單狀態(tài)流轉(zhuǎn)需要確保數(shù)據(jù)庫(kù)狀態(tài)變更和下游調(diào)用同時(shí)成功或者失敗，即事務(wù)性。

快速上手收發(fā)消息

說(shuō)了這么多場(chǎng)景和案例，直接看一下代碼怎么用。

發(fā)送普通消息

發(fā)送消息的流程非常簡(jiǎn)單，但這其中需要注意以下幾點(diǎn)：

• 消息初始化應(yīng)盡可能完整：普通消息初始化包括主題、Tag 標(biāo)簽、索引 Key 和負(fù)載。可以按實(shí)際情況設(shè)置完成。
• 消息發(fā)送需要捕獲結(jié)果和異常：消息發(fā)送完成需要獲取響應(yīng)結(jié)果，如果失敗需要捕獲異常并做重試處理。

消費(fèi)普通消息

RocketMQ 支持的消費(fèi)方式有多種，有主動(dòng)獲取的方式，也有被動(dòng)消費(fèi)監(jiān)聽(tīng)器推送的方式。

被動(dòng)消費(fèi)方式只需要注冊(cè)消費(fèi)監(jiān)聽(tīng)器，然后監(jiān)聽(tīng)器內(nèi)部去處理這個(gè)邏輯，最終返回消費(fèi)結(jié)果。如果消費(fèi)失敗，希望 RocketMQ 再做重投，就要返回一個(gè)失敗的結(jié)果；拋異常也是返回失敗。類似于這樣的結(jié)果，返回服務(wù)端就完成了整個(gè)消費(fèi)的過(guò)程。

對(duì)于主動(dòng)獲取的方式，會(huì)更加靈活，由業(yè)務(wù)方主動(dòng)調(diào)用獲取消息，可以按照自己的速率和并發(fā)取消息，處理完成后，再回復(fù) RocketMQ 服務(wù)端消費(fèi)結(jié)果。