作者｜紹舒
稽核&校對：歲月、佳佳
編輯&排版：雯燕
消息隊列是分布式網際網路架構的重要基礎設施，在以下場景都有着重要的應用：
應用解耦
削峰填谷
異步通知
分布式事務
大資料處理
并涉及互動直播、移動網際網路&物聯網，IM 實時通信、Cache 同步、日志監控等多個領域。
而本文主要圍繞着商業版本的消息隊列 RocketMQ，和開源版本 RocketMQ 進行比較，并結合一些實踐中的場景來展示大型分布式應用的上雲最佳實踐。
商業版本消息隊列 RocketMQ 相比較開源版本 RocketMQ 和其他競品，主要有以下幾點優勢。
開箱即用、功能豐富
高性能、無限擴充能力
可觀測、免運維能力
高 SLA 和穩定性保證
消息隊列 RocketMQ 提供了定時、事務、順序等多類型消息的支援，且支援廣播、叢集兩種消費模式；另外在協定層面，提供 TCP/HTTP 多協定支援，還提供了 TAG/SQL 屬性過濾功能，極大程度地拓寬了使用者的使用場景。
消息隊列 RocketMQ 經受了阿裡核心電商曆年雙十一洪峰的考驗，支援千萬級 TPS 消息收發和億級消息堆積的能力，并且能夠為消息提供毫秒級端到端延遲保障，另外還提供分級存儲，支援海量消息的任意儲存時間。
消息隊列 RocketMQ 提供了一個可觀測性大盤，支援細粒度資料大盤，提供了消息全鍊路生命周期追蹤和查詢能力，對各個名額提供了相應的監控報警功能；此外，還提供了消息回溯和死信隊列功能，能夠保證使用者的消息能夠随時回溯消費。
消息隊列 RocketMQ 的穩定性是我們一貫、持續、穩定投入的重要領域，提供了高可用部署和多副本寫入功能；另外也支援同城多 AZ 容災和異地多活。
接下來，我們會從以上的産品核心能力中挑選幾個剖面，并且結合具體的場景和實踐來做進一步的介紹。
商業版本消息隊列 RocketMQ 使用的順序消息我們稱之為高可用順序消息。在介紹高可用順序消息之前，首先簡要介紹下開源版本 RocketMQ 的順序消息。
順序消息分為兩種類型，全局順序消息和分區順序消息。
全局順序消息：在 RocketMQ 存儲層隻會配置設定一個分區，也就是說全局順序 Topic 的可用性跟單一副本的可用性強相關，且不具備可擴充的能力。
分區順序消息：所有消息根據 Sharding Key 進行分區。同一個分區内的消息按照嚴格的 FIFO 順序進行釋出和消費。Sharding Key 是順序消息中用來區分不同分區的關鍵字段。
下圖是分區順序消息的應用場景，order ID 即為此時順序消息的 Sharding Key。
可以看到，無論是全局順序消息還是分區順序消息，都依賴了單一分區天然的 FIFO 特性來保證順序，是以順序性也隻能在同一個分區内保證，當此分區所在的副本不可用時，順序消息并不具備重試到其他副本的能力，此時消息的順序性就難以得到保證。
為了解決這一問題，我們設計并實作了高可用順序消息。
高可用順序消息有以下幾個特點：
一個邏輯順序分區（PartitionGroup）下有多個實體分區。
其中任意一個實體分區是可寫的，那麼整個邏輯分區是可寫且有序的。
我們基于 happened-before 的原則設計了一套基于分區位點的排序算法。
根據該算法，消費者在消費某一邏輯分區時，會從其所屬的各個實體分區中拉取消息并進行合并排序，得出正确的消息順序流。
通過這樣的設計，高可用順序消息解決了下列幾點問題：
可用性問題：高可用順序消息将具備與普通消息一緻的可用性，在某副本不可用時，可快速重試至其它副本。
可擴充性問題：普通順序消息，特别是普通全局順序消息，不具備良好的擴充能力，隻能固定在特定的副本中。高可用順序消息的邏輯順序分區可以将實體順序分區分散在多個副本中。
熱點問題：普通順序消息根據 Key 将一類消息 Hash 至同一個分區中，熱點 Key 會導緻熱點分區，高可用順序消息具備橫向擴充能力，可以為邏輯順序分區添加多個實體分區來消除熱點問題。
單點問題：普通全局順序消息，僅包含單分區，極易出現單點故障，高可用順序消息可以消除全局順序消息的單點問題。
尤其需要注意的是熱點問題，在阿裡巴巴内部某電商業務大促時，因發送到順序 Topic 的某一特定的 ShardingKey 數量過多，叢集中一個副本接收到了大量該 ShardingKey 的消息，導緻該副本超出其負荷上限，造成了消息的延遲和堆積，一定程度上影響了業務。在使用了高可用順序消息之後，由于其在多實體分區中的負載均衡特性，提升了叢集順序消息的承載能力，進而避免了熱點問題的出現。
定時消息，是指用戶端目前發送但希望在未來的某個時間内收到的消息。定時消息廣泛應用于各類排程系統或者業務系統之中。比如支付訂單，産生一個支付消息，系統通常需要在一定時間後處理該消息，判斷使用者是否支付成功，然後系統做相應處理。
開源版本的 RocketMQ 隻支援幾個指定的延遲級别，并不支援秒級精度的定時消息。而面向集團内和雲上多樣化的需求，開源版本的定時消息并不能滿足我們的需求，是以我們推出了秒級精準定時消息。
如下圖所示，我們基于時間輪設計并實作了支援任意定時時間的秒級精準定時消息，同時滿足以下特性：
任意定時時間
超長定時時間
海量定時消息
删除定時消息
高可用
高性能
内部某使用者有這樣的場景，期望在未來的某一分鐘的 30s 時刻處理這樣一個定時請求，開源版本的定時消息并不符合其需要，而秒級精準定時消息在保證高可用、高性能的同時，滿足了其業務需求。
如下圖所示，在傳統的事務進行中，多個系統之間的互動耦合到一個事務中，造成整體的相應時間長，復原過程複雜，進而潛在影響了系統的可用性；而 RocketMQ 提供的分布式事務功能，在保證了系統松耦合和資料最終一緻性的前提下，實作了分布式事務。
消息隊列 RocketMQ 提供的事務消息處理步驟如下：
發送方将半事務消息發送至消息隊列 RocketMQ 版服務端。
消息隊列 RocketMQ 版服務端将消息持久化成功之後，向發送方傳回 Ack 确認消息已經發送成功，此時消息為半事務消息。
發送方開始執行本地事務邏輯。
發送方根據本地事務執行結果向服務端送出二次确認（Commit 或是 Rollback），服務端收到 Commit 狀态則将半事務消息标記為可投遞，訂閱方最終将收到該消息；服務端收到 Rollback 狀态則删除半事務消息，訂閱方将不會接受該消息。
基于這樣的實作，我們通過消息實作了分布式事務特性，即本地事務的執行結果會最終反應到訂閱方是否能接收到該條消息。
消息隊列 RocketMQ 的分布式事務消息廣泛地應用于阿裡巴巴核心交易鍊路中，通過分布式事務消息，實作了最小事務單元；交易系統和消息隊列之間，組成一個事務處理；下遊系統（購物車、積分、其它）互相隔離，并行處理。
随着雲上客戶的不斷增多，存儲逐漸成為 RocketMQ 運維的重要瓶頸，這包括并且不限于：
記憶體大小有限，服務端不能将所有使用者的資料全部緩存在記憶體中；在多租戶場景下，當有使用者拉取冷資料時，會對磁盤造成較大 IO 壓力，進而影響共享叢集的其他使用者，亟需做到資料的冷熱分離。
雲上有單租戶定制化消息存儲時長的需求。而 RocketMQ Broker 中所有使用者的消息是放在一個連續檔案中進行存儲的，無法針對任何單一使用者定制存儲時長，即現有的存儲結構無法滿足這樣的需求。
如果能對海量資料提供更低成本的存儲方式，可以大幅降低雲上 RocketMQ 的磁盤存儲成本。
基于以上現狀，分級存儲方案應運而生。
分級存儲的整體架構如下：
connector 節點負責将 broker 上的消息實時同步到 OSS 上
historyNode 節點将使用者對冷資料的拉取請求轉發至 OSS 上
在 OSS 中是按照 Queue 粒度來組織檔案結構的，即每個 Queue 會由獨立的檔案進行存儲，進而保證了我們可以針對于租戶定義消息的存儲時長。
通過這樣的設計，我們實作了消息資料的冷熱分離。
基于分級存儲，我們進一步拓展了使用者的使用場景：
自定義存儲時間：在消息資料的冷熱分離之後，我們将冷資料存儲到 OSS 這樣的存儲系統中，能夠實作使用者自定義的存儲時間。
消息審計：在消息的存儲之間從數天擴充到自定義後，消息的屬性從一個臨時性的中轉資料變成了使用者的資料資産，而消息系統也從資料中樞轉變成了資料倉庫；使用者能夠基于資料倉庫實作更多樣的審計、分析、處理功能。
消息回放：在流計算場景中，消息回放是非常重要的一個場景；通過拓展消息的存儲時間之後，流計算能夠實作更加豐富的計算分析場景。
消息隊列 RocketMQ 的穩定性是我們一貫、持續、穩定投入的重要領域。在介紹我們在穩定性的最新工作之前，首先帶大家回顧下 RocketMQ 高可用架構的演進路線。
2012 年，RocketMQ 作為阿裡巴巴全新一代的消息引擎問世，并随後開源至社群，第一代 RocketMQ 高可用架構也随之誕生。如下圖所示，第一代高可用架構采取當時流行的 Master-Slave 主從架構，寫流量經過 Master 節點同步至 Slave 節點，讀流量也經過 Master 節點并将消費記錄同步至 Slave 節點。當 Master 節點不可用時，整個副本組可讀不可寫。
2016 年，RocketMQ 雲産品正式開始商業化，雲時代單點故障頻發，雲産品需要完全面向失敗而設計，是以 RocketMQ 推出了第二代多副本架構，依托于 Zookeeper 的分布式鎖和通知機制，引入 Controller 元件負責 Broker 狀态的監控以及主備狀态機轉換，在主不可用時，備自動切換為主。第二代架構是消息雲産品規模化程序中的核心高可用架構，為雲産品規模化立下了汗馬功勞。
2018 年，RocketMQ 社群對 Paxos 和 Raft 引入分布式協定有極大的熱情，RocketMQ 研發團隊在開源社群推出了基于 Raft 協定的 Dledger 存儲引擎，原生支援 Raft 多副本。
RocketMQ 高可用架構已經走過了三代，在集團、公有雲和專有雲多樣場景的實踐中，我們發現這三套高可用架構都存在一些弊端：
第一代主備架構隻起到了冷備的作用，且主備切換需要人工介入，在大規模場景下有較大的資源浪費以及運維成本。
第二代架構引入了 Zookeeper 和 Controller 節點，架構上更加複雜，在主備切換做到了自動化，但故障轉移時間較長，一般是 10 秒左右完成選主。
第三代 Raft 架構目前暫未在雲上和阿裡集團内大規模應用，且 Raft 協定就決定了需要選主，新主還需要被用戶端路由發現，整個故障轉移時間依然較長；另外，強一緻的 Raft 版本并未支援靈活的降級政策，無法在可用性和可靠性之間做靈活的權衡。
為了應對雲上日益增長的業務規模、更嚴苛的 SLA 要求、複雜多變的專有雲部署環境，目前的消息系統需要一種架構簡單、運維簡單、有基于目前架構落地路徑的方案，我們将其稱作秒級 RTO 多副本架構。
秒級 RTO 多副本架構是消息中間件團隊設計實作的新一代高可用架構，包含副本組成機制、Failover 機制、對現有元件的侵入性修改等。
整個副本組有以下特點：
Strong Leader/No Election：Leader 在部署時确定，整個生命周期内不會發生切換，但可在故障時被替換。
僅 Leader 支援消息寫入：每一個副本組僅 Leader 接受消息寫入，Leader 不可用時，整個副本組不可寫入。
所有的副本支援消息讀取：雖然 Leader 上擁有全量的消息，Follower 上的消息量不對等，但所有的副本都支援消息的讀取。
靈活的副本組數量：可以基于可靠性、可用性和成本自由選擇副本組的數量。
靈活的 Quorum 數量：最終所有的消息都會同步到整個副本組上，但副本組内可以靈活配置寫成功最小副本數。例如 2-3 模式，3 副本情況下，2 副本成功即為寫成功。同時，在副本不可用的情況下，Quorum 數量也可以動态自行降級。
在上述副本組的概念下，故障轉移可以複用目前 RocketMQ 用戶端的機制來完成。如下圖所示：
Producer 在主不可用時，靈活快速地切換至另一個副本組。
Consumer 在某個副本不可用時可快速切換至同副本組另一個副本上進行消息消費。
我們在可觀測性方面也做了大量的工作，為使用者提供了一個消息系統的可觀測性健康資料大盤。如下圖所示，使用者能夠清晰的看到執行個體級别、topic 級别、group 級别的各種監控資料，能夠全方面地監控、診斷問題。
另外我們還基于消息軌迹提供了消息全鍊路軌迹追蹤功能。如下圖所示，使用者能夠在控制台上看到完整的消息生命周期、從消息的發送、存儲、到消費，整個鍊路都能被完整地記錄下來。
客戶痛點：業務出現消費堆積的使用者需要根據消息軌迹抽樣資料，綜合分析後才能大緻判斷引起問題原因，排查困難。
核心價值：提高線上運作問題排查的效率，和問題定位的準确性。直接在健康大盤上快速發現風險最高的 Topic 和 Group，并根據各個名額的變化情況快速定位原因。例如消息處理時間過長可以擴容消費者機器或優化消費業務邏輯，如果是失敗率過高可以快速檢視日志排除錯誤原因。
大家一定非常熟悉 Gartner，在2018年的一個評估報告裡，Gartner 将 Event-Driven Model，列為了未來10大戰略技術趨勢之一，并且，做出了兩個預測：
2022年，超過 60% 的新型數字化商業解決方案，都會采用事件通知的軟體模型。
2022年，超過 50% 的商業組織，将會參與到EDA生态系統當中去。
同一年，CNCF 基金會也提出了 CloudEvents，意在規範不同雲服務之間的事件通訊協定标準。到目前為止，CloudEvents也已經釋出了多個消息中間件的綁定規範。
可見事件驅動是未來業務系統的一個重要趨勢，而消息天然具備和事件的親近性，是以消息隊列 RocketMQ，是堅決擁抱事件驅動的。
談到消息和事件，這裡做一個簡單的闡述：消息和事件是兩種不同形态的抽象，也意味着滿足不同的場景：
消息：消息是比事件更通用的抽象，常用于微服務調用之間的異步解耦，微服務調用之間往往需要等到服務能力不對等時才會去通過消息對服務調用進行異步化改造；消息的内容往往綁定了較強的業務屬性，消息的發送方對消息處理邏輯是有明确的預期的。
事件：事件相對于消息更加具像化，代表了事情的發送、條件和狀态的變化；事件源來自不同的組織和環境，是以事件總線天然需要跨組織；事件源對事件将被如何響應沒有任何預期的，是以采用事件的應用架構是更徹底的解耦，采用事件的應用架構将更加具備可擴充性和靈活性。
在2020年，阿裡雲釋出了事件總線 EventBridge 這一産品，其使命是作為雲事件的樞紐，以标準化的 CloudEvents 1.0 協定連接配接雲産品和雲應用，提供中心化的事件治理和驅動能力，幫助使用者輕松建構松耦合、分布式的事件驅動架構；另外，在阿裡雲之外的雲市場上有海量垂直領域的 SaaS 服務，EventBridge 将以出色的跨産品、跨組織以及跨雲的內建與被內建能力，助力客戶打造一個完整的、事件驅動的、高效可控的上雲新界面。
而借助事件總線 EventBridge 提供的事件源功能，我們能夠打通消息到事件的鍊路，使得消息隊列 RocketMQ 具備事件驅動的動力，進而擁抱整個事件生态。接下來我們将借助一個案例，如下圖所示，為大家展示這一功能。
我們基于容器服務快速建立一個事件驅動的服務，計算負載 Deployment 的 yaml 如下，該服務能夠響應事件并将結果列印到标準輸出中。
前往容器服務控制台，進入服務與路由的服務頁面，建立一個私網通路類型的 Service，并做好端口映射。
我們來到事件總線 EventBridge 控制台，建立一個自定義總線 demo-with-k8s。
我們為總線 demo-with-k8s 建立一個規則，并選擇 HTTP 作為事件目标，選擇專有網絡類型，選中對應的 VPC、 VSwitch 以及安全組，并指定目标URL，如下圖所示：
我們為該自定義事件總線添加消息隊列 RocketMQ 版的自定義事件源。
接下來我們回到消息隊列 RocketMQ 控制台，通過控制台的快速體驗消息生産功能發送一條内容為 hello eventbridge 的消息到對應的主題中去。
接下來我們就可以發現，這條 RocketMQ 消息，以 CloudEvent 的形式被投遞到了對應的服務中去，我們進而打通了消息到事件的鍊路。同時，基于我們上述提到的分級存儲功能，消息隊列 RocketMQ 轉變成了一個能夠源源不斷提供事件的資料倉庫，為整個事件生态提供了更加廣闊的場景。
事件驅動是未來商業組織和業務系統的重要趨勢，而消息隊列 RocketMQ 會堅定地擁抱這一趨勢，将消息融入到事件的生态中。
我們選取了消息隊列 RocketMQ 的幾個産品剖面，從多消息類型、分級存儲到穩定性、可觀測性，再到面向未來的事件驅動，并結合與開源 RocketMQ 的對比，及具體應用場景的分析，為大家展示了基于消息隊列 RocketMQ 的大型分布式應用上雲最佳實踐。