Apache RocketMQ 在阿里雲大規模商業化實踐之路

語言: CN / TW / HK

阿里雲訊息佇列 RocketMQ 商業化歷程

Cloud Native

RocketMQ 誕生於 2012 年,誕生即開源。2012~2015 年,RocketMQ 一直在通過內部電商業務打磨自身服務能力,並在 2015 年於阿里雲上線公測。2016 年,阿里雲 RocketMQ 完成商業化,同時被捐贈給 Apache 基金會,同年獲得了年度受歡迎中國開源軟體榮譽。

在 Apache 孵化期間,Apache RocketMQ 經歷了快速發展,2017 年即畢業成為了 Apache 頂級專案。同年,Apache RocketMQ TLP RocketMQ 4.0 正式釋出。此後,RocketMQ 4.0 經歷了長足發展,期間阿里雲商業和開源相輔相成、齊頭並進,直到今天,共同邁入 RocketMQ 5.0 時代。

RocketMQ 5.0 釋出後,阿里雲商業會持續採取 OpenCore 的發展模式,秉承上游優先的社群發展原則,與社群一起將 RocketMQ 打造為一個超融合的資料處理平臺。

阿里雲訊息佇列產品矩陣

Cloud Native

阿里雲基於 RocketMQ 訊息底座,構建了多元化的訊息產品系列。

RocketMQ 是阿里雲主打的訊息品牌,網際網路新興業務領域首選的資料通道。訊息佇列 Kafka 是大資料的首選資料通道,微訊息佇列 MQTT 是移動網際網路和物聯網的資料通道,訊息佇列 RocketMQ 是傳統業務領域的資料通道。訊息服務 MNS 是 RocketMQ 輕量版,主要應用於應用整合領域,為平臺型應用提供簡單的佇列服務。事件匯流排 Event Bridge 定位為雲上事件樞紐,旨在阿里雲上構建統一的事件中心。

阿里雲訊息佇列產品矩陣完全構建在 RocketMQ 之上,基本實現了應用場景全覆蓋,包括微服務解耦、SaaS 整合、物聯網、大資料或日誌收集生態,同時也在內部覆蓋了阿里巴巴所有業務,在雲上為數萬阿里雲企業提供了優質的訊息服務。阿里雲的訊息產品矩陣涵蓋了網際網路、大資料、移動網際網路等領域業務場景,為雲原生客戶提供不可或缺的一站式解決方案。

RocketMQ 在阿里雲商業化歷程中,一直致力於探索業務訊息實踐,也孵化了大量業務訊息特性,並持續反哺到開源社群。

RocketMQ 4.0 業務訊息探索之路

Cloud Native

RocketMQ 在商業化過程中,陸續推出了四種訊息型別來滿足豐富的業務場景。

  • 普通訊息:普通訊息提供極致彈性、海量堆積能力,內建重試與死信佇列來滿足業務對失敗重試的需求,同時具備高吞吐、高可用、低延遲等特性,廣泛應用於應用整合、非同步解耦、削峰填谷等場景。

  • 定時訊息:提供秒級定時精度, 40 天超長定時,主要面向分散式定時排程、任務超時處理等場景,目前正在開源中。

  • 順序訊息: 支援全域性與區域性嚴格有序,從傳送、儲存到消費,保證端到端有序。 面向有序事件處理、撮合交易、資料實時增量同步等場景。

  • 事務訊息:分散式、高效能、高可用的最終一致性事務解決方案,廣泛應用於電商交易系統中服務的一致性協調場景並且已經開源。

RocketMQ 4.0 期間,商業和開源都致力於全方位拓展訊息接入能力,使 RocketMQ 能夠非常輕鬆地連線應用開源和雲產品生態。比如商業上提供了多語言 SDK ,開源也有相應的 SDK 能夠覆蓋 Java、Go、Python 、C++使用 RocketMQ。同時支援 Spring 生態,能夠通過 Spring Cloud 的方式使用 RocketMQ。商業上提供了一組非常簡單易用的 HTTP API,提供了 6-7 種語言的實現。

除了 SDK 接入,RocketMQ 也在積極擁抱社群標準,在雲產品側提供了 AMQP 和 MQTT 的接入能力,其中 MQTT 已開源。

RocketMQ 也大力在發展 connector 生態,能夠通過 RocketMQ connector 接入很多資料來源,包括 Redis、MongoDB、Hudi 等大資料系統。

另外,阿里雲構建的事件匯流排 EventBridge 也已開源,通過該產品能夠將阿里雲的雲產品、SaaS 應用、自建資料平臺的資料引入 RocketMQ。

RocketMQ 4.0 版本做了大量嘗試,提供了全方位的訊息接入能力。

RocketMQ 在服務阿里集團使用者和商業化歷程中,沉澱了大量領先的業務訊息處理與服務能力。比如訊息訂閱方面,RocketMQ 支援叢集分散式消費能力,也支援廣播消費。在訊息處理方面支援基於 Tag 和 SQL 做靈活過濾,其中基於 SQL 過濾是電商交易中非常重要的特性,能夠支援在非常訂閱比的情況下實現較低的投遞比。

全球訊息路由能力具備效能高、實時性強的特點。在雲時代,資料中心天然分佈在各個地域,各個地域之間還有 VPC 網路隔離。但是通過全球訊息路由功能可以將地域與網路打通,能夠滿足更多業務場景。比如在阿里內部基於該能力實現了異地多活、異地容災等企業級特性。

另外,全球訊息路由具備非常高的易用性,提供了視覺化任務管理介面,通過簡單配置即可建立複製鏈路。

訊息治理方面,RocketMQ 提供了訪問控制、名稱空間、例項限流、訊息回放、重試訊息、死信訊息、堆積治理等能力。

服務能力方面,RocketMQ 經歷了非常多沉澱,它在為交易鏈路服務了 12  年,參加了 10 年雙 11,這也保證了 RocketMQ 能夠在阿里雲上提供非常高的可靠性。雙 11 訊息收發 TPS 峰值過億,日訊息收發總量超過 3 萬億。而即使在雙十一萬億級資料洪峰下,訊息也能做到 99.996% 毫秒級響應能力,訊息釋出平均響應時間不超過 3 毫秒,最大不超過 20 毫秒,真正實現了低延遲訊息釋出。

商業化初期,客戶遇到最大難題是在分散式環境下如何完整地追蹤非同步訊息鏈路。基於此背景,我們打造了視覺化全生命週期訊息軌跡追蹤系統,能夠提供豐富的訊息查詢、訊息下載、定點重投、軌跡追蹤能力,通過可觀測系統幫助使用者解決分散式環境中不可觀測的問題。

如上圖所示,一條訊息從產生、傳送至服務端儲存到最終投遞到消費者,整個傳送和消費軌跡都有跡可循,包括投遞給哪些消費者、哪些消費者在什麼地方成功消費或者消費失敗、何時進行重投,真正幫助客戶解決了分散式觀測難題。

除了功能特性,RocketMQ 在穩定性方面也做了很多建設。我們始終堅持,SLA 是雲原生的根本,因此整個研發運維鏈路都有嚴格的穩定性保障措施:

  • 架構開發 :每個方案設計都會面向失敗設計,程式碼開發階段會有嚴格 Code Review 階段,也會完整經歷單元測試、整合測試、效能測試和容災測試流程。

  • 變更管理 :有著非常嚴格的變更制度,要做到每個變更可灰度、可監控、可回滾、可降級。

  • 穩定性防護 :提供了限流、降級、容量評估、應急方案、大促保障等能力,會定期進行故障和預案演練,定期進行風險梳理。

  • 體系化巡檢 :在雲上有全方位的生產環境黑盒巡檢。基於使用者視角,會對全地域所有功能做全功能掃描,包含高達 50 多項檢測項,任意項功能出問題都能立刻被監測到。在白盒巡檢方面,會對 JVM 執行時指標、核心系統、叢集指標進行巡檢。

  • 故障應急 :有完整地故障應急流程,包括監控報警、故障發生、快速止血、排查根因、故障覆盤。

RocketMQ 5.0 雲原生架構升級之路

Cloud Native

雲原生時代,雲上使用者對雲產品服務化程度、彈效能力、可控制性能力以及韌性都有了更高的要求。在此背景之下,我們對 RocketMQ 進行了雲原生架構升級,這也是 RocketMQ 5.0 的誕生背景。

  • 輕量級 SDK:基於雲原生通訊標準 gRPC 開發了一組輕量級 SDK,能夠與當前富客戶端優勢互補。

  • 無狀態訊息閘道器: 在核心資料鏈路推出了無狀態訊息閘道器。 通過搭建無狀態服務節點Proxy,再通過 LB 進行服務暴露,將儲存節點資料分離來獨立負責核心訊息儲存和高可用。 Proxy 與 Store 節點分離部署,獨立彈性。

  • Leaderless 高可用架構: Store 節點身份完全對等,完全 Leaderless 化,去 ZK 和 HA 管控節點,能夠做到非常高的可用性。 同時相比傳統的 Raft 一致性協議,該 Leaderless 架構能夠做到副本數靈活選擇,同步非同步自動升降級,實現秒級故障轉移。 高可用架構目前已經完成開源並與 Dledger 進行了融合。

  • 雲原生基礎設施: 可觀測驗能力雲原生化,OpenTelemetry 標準化。 整體架構走向 Kubernetes 化,能夠充分利用售賣區的資源彈效能力。

RocketMQ 4.0 推薦的接入方式主要是富客戶端。富客戶端提供了諸如客戶端側負載均衡、訊息快取、故障轉移等一系列企業級特性。但在雲原生時代,輕量級、高效能的客戶端更容易被雲原生技術棧所整合。

因此,RocketMQ 5.0 重磅推出了全新多語言輕量級 SDK,具有以下優勢:

  • 全新極簡 API 設計 :不可變 API,有完善的錯誤處理。多語言 SDK 保障 API 在 Native 層面對齊。同時引入了全新的 Simple Consumer,能夠支援按訊息模型進行消費,使用者不再需要關心訊息佇列,只需要關注訊息。

  • 通訊層採用 gRPC 協議 :擁抱雲原生通訊標準,gRPC 能夠使服務更易被整合。多語言 SDK 通訊程式碼也可以通過 gRPC 快速生成,更 Native 。

  • 輕量級實現 :採用無狀態消費模式,能夠大幅降低客戶端的實現複雜度。客戶端更輕量,採用的應用也更容易被 Serverless化、Mesh 化。

  • 雲原生可觀測性 :客戶端實現了 OpenTelemetry 標準,能夠支援以 OpenTelemetry 形式匯出 Metrics 與 Tracing。

RocketMQ 5.0 的另一個重大升級是引入了全新的無狀態消費模型。該消費模型完全構建在原先的佇列模型之上。佇列模型是與儲存模型一致的消費模型,消費者完全按照佇列做負載均衡,也按照佇列做訊息拉取,非常適合批量高速拉取以及對單條訊息狀態不敏感的場景,比如流計算等。

RocketMQ 5.0 推出了 PoP 機制,巧妙地在佇列模型之上構建了訊息模型,實現了魚與熊掌兼得。在此訊息模型的設計上,業務可以只關心訊息而無需關心佇列,所有 API 都能夠支援單條訊息級別的消費、重試、修改不可見時間、刪除。

在訊息模型下,訊息傳送過來被儲存後,即對消費者可見。消費者通過 Receive Message API 對訊息進行消費後,訊息進入定時不可見狀態。訊息超時過後又會重新處於可見狀態,能被其他消費者繼續消費。某消費者確認訊息後,服務端會對該訊息進行刪除,隨即不可見。

基於訊息系模型的消費流程下,API 完全面向訊息而不是面向佇列。而當 PoP 機制遇見了無狀態 Proxy,除了儲存層,其他節點都是無狀態的;客戶端、連線和消費也是無狀態的,可任意在 Proxy 節點上飄移,真正做到輕量級。

經過重構,RocketMQ 5.0 的可觀測性也走向了雲原生標準。

Metrics 側:

  • 指標涵蓋豐富:設計了更豐富的指標,包含訊息量、堆積量、各個階段耗時等指標,每個指標從例項、Topic、消費 GroupID 多維度做聚合和展示。

  • 訊息團隊實踐模板:為使用者提供實踐模板,並持續迭代更新。

  • Prometheus + Grafana:Prometheus 標準資料格式,利用 Grafana 展示。除了模板,使用者也可以自定義展示大盤。

Tracing 側:

  • OpenTelemetry Tracing 標準:RocketMQ Tracing 標準已經合併到 OpenTelemetry 開源標準,提供了規範和豐富的 messaging tracing 場景定義。

  • 訊息領域定製化展示:按照訊息維度重新組織抽象的請求 span資料,展示一對多的消費,多次消費資訊直觀且方便理解。

  • 可銜接 tracing 鏈路上下游:訊息的 tracing 可繼承呼叫上下文,補充到完整的呼叫鏈路中,訊息鏈路資訊串聯了非同步鏈路的上游和下游鏈路資訊。

Logging 側:

  • Error Code 標準化:不同的錯誤有唯一的 Error Code。

  • Error Message 完整:包含完整的錯誤資訊和排序所需要的資源資訊。

  • Error Level 標準化:細化了各種不同錯誤資訊的日誌級別,使用者可根據 Error、Warn 等級別配置更適合的監控告警。

彈性方面,RocketMQ 5.0 商業版能夠充分撬動雲的計算、儲存和網路的池化資源。比如在計算方面,RocketMQ 5.0 所有工作負載完全部署在 ACK 之上,充分利用了 ACK 彈效能力,撬動 ACK 彈性資源。主要依賴 ACK 的兩項技術,一是彈性資源池,另一個是 HPA 支援計算能力快速彈性。同時也會在 ACK 之上做跨可用區部署以提供高可用保障。

網路層面,RocketMQ 5.0 也會充分利用阿里雲網絡設施,為使用者提供更便捷的網路訪問能力。比如 RocketMQ 5.0 例項能夠支援公網隨開隨用,需要依賴公網做測試的時候即開即用,測試完立即關閉,安全與方便兼具。同時支援多種私網型別的網路形態,包括 Single Tunnel、Private Link,另外也基於 CEN 構建了全球互通設計網路。

儲存方面,RocketMQ 5.0 商業版率先引入多級儲存概念,基於 OSS 構建二級儲存,能夠充分利用 OSS 儲存的彈效能力,儲存計費也轉向了按量付費。而使用者能夠在 RocketMQ 之上自定義訊息儲存時長,比如將訊息從 3 天有效時長延長至 30 天,能夠真正將訊息變為資料資產。同時利用二級儲存能力,將冷熱資料分離,為使用者提供一致的冷讀 SLA 。

RocketMQ 5.0 商業版釋出預告

Cloud Native

RocketMQ 4.0 歷經了五年發展,開源和商業版本共同邁入了 5.0 時代。 7 月底,阿里雲訊息佇列將會基於開源版釋出全新的 5.0 商業化版本。 注: 截止發稿前,RocketMQ 5.0 已經在阿里雲訊息佇列 RocketMQ 產品上全新發布,目前支援國內主要地域。

RocketMQ 5.0 版相對於 4.0 版例項主要有以下幾大改變:

第一,新版本、新售賣,更便宜。新版本採取了全新計量方式,有包年、包月型,也有按量付費和公網流量彈性計費。也有更全的售賣體系,比如新增專業版例項,能夠滿足部分使用者需求。同時每個商品系列都新增了測試環境專用例項,能夠方便使用者以低成本的方式搭建自己的開發環境。

第二,更強彈性,降本提效利器。儲存完全走向彈性,能夠通過 Serverless 按需使用,按量付費。預留彈性,例項基礎規格支援實時升降配,使用者可以很方便地在流量到來之前做彈性。此外,專業版支援突發流量彈性,能夠解決線上穩定性風險。

第三,全新架構,增強可觀測運維。無狀態訊息消費模型能夠解決一些老版本的痛點。同時在可觀測上全面採取了雲原生接入棧。

訊息的全新形態:事件匯流排 EventBridge

Cloud Native

事件匯流排 EventBridge 已經開源到 RocketMQ 社群中。 雲原生時代,事件無處不在,雲端計算資源散落在各地,各類生態孤島隨處可見。 因此,以事件和事件驅動的方式來整合這一切是大勢所趨。

基於此,阿里雲推出了全新事件型產品 EventBridge。該產品構建在 RocketMQ 之上,是 RocketMQ 之上的一個事件驅動架構實踐。

EventBridge 的事件源包括阿里雲服務的管控事件比如資源變更事件、審計事件、配置變更事件,阿里雲服務的資料事件,也包括自定義應用、SaaS 應用、自建資料平臺、其他雲廠商服務等。

事件經過 EventBridge 處理後會投遞到事件目標,事件目標包括函式計算、訊息服務、自建閘道器、HTTP(S)、簡訊、郵箱、釘釘等。

事件源到事件目標之間會經歷完整的事件處理,包括事件源接入到 EB 後,可以對事件進行過濾、轉換、歸檔、回放等。事件在 EventBridge 整個流程中也有完善的可觀測性設計,包括事件查詢、鏈路追蹤。事件的接入方式非常豐富,可以通過 OpenAPI 來接入、7 種多語言 SDK、CloudEvents SDK、Web Console 和 Webhook 。

EventBridge 具有如下特點:

  • 能夠大幅度減少使用者開發成本,使用者無需額外開發,通過建立 EventBridge 源、事件目標、事件規則等資源即可實現事件架構。使用者可以編寫事件規則,對事件做過濾、轉換。

  • 提供原生 CloudEvents 支援,擁抱 CNCF 社群,能夠無縫對接社群 SDK 。標準協議也能統一個阿里雲事件規範。

  • 事件 Schema 支援:能夠支援事件 Schema 自動探測和校驗,支援 Source 和 Target 的 Schema 繫結。

  • 全球事件任意互通:組建了全球事件任意互通網路,元件了跨地域、跨賬戶的事件網路,能夠支援跨雲、跨資料中心的事件路由。

EventBridge在雲上生態已經初具規模,已經集成了 255+ 雲產品事件源和 1000+ 事件型別。

EventBridge率先對訊息生態做了融合。阿里雲的訊息產品矩陣生態均通過 EventBridge 做了完全融合。任何一款訊息產品與另一款訊息產品的資料都能互通。同時,依靠 EventBridge 的全球事件網路,能夠為所有訊息產品賦予全球訊息路由的能力。

EventBridge 目前已經在內部接入釘釘 ISV、聚石塔 ISV,外部也有 50+ SaaS 系統可以通過 Webhook 的方式接入。另外,海量事件源可以觸達 10 多種事件目標,已經對接了全系雲產品 API ,任何事件都可以驅動全量雲產品 API。

加入 Apache RocketMQ 社群

Cloud Native

年鑄劍,Apache RocketMQ 的成長離不開全球接近 500 位開發者的積極參與貢獻,相信在下個版本你就是 Apache RocketMQ 的貢獻者,在社群不僅可以結識社群大牛,提升技術水平,也可以提升個人影響力,促進自身成長。感興趣的同學 可以加入釘釘群與 RocketMQ 愛好者一起廣泛討論:

釘釘掃碼加群

作者介紹:

周新宇 - Apache Member,Apache RocketMQ PMC Member,阿里雲訊息佇列 RocketMQ 研發負責人。

點選閱讀原文,進入官網瞭解更多詳情~