引言

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

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

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

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

集成目標(biāo)不同

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

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

關(guān)注重點不同

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

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

實時性不同

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

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

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

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

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

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

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

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

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

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

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

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

普通消息原理介紹

功能簡介

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

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

普通消息的特點

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

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

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

消息的生命周期

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

簡單來說消息的生命周期可以抽象成五個狀態(tài)：

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

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

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

使用場景

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

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

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

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

案例介紹

1）場景簡介

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

2）核心痛點

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

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

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

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

說了這么多場景和案例，直接看一下代碼怎么用。

發(fā)送普通消息

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

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

消費普通消息

RocketMQ 支持的消費方式有多種，有主動獲取的方式，也有被動消費監(jiān)聽器推送的方式。

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

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

分享標(biāo)題：RocketMQ消息集成：多類型業(yè)務(wù)消息-普通消息
URL分享：http://uogjgqi.cn/article/dhhgejc.html