阿里雲基於全新RocketMQ 5.0核心的落地實踐

語言: CN / TW / HK

簡介: 在上個月結束的 RocketMQ Summit 全球開發者峰會中,Apache RocketMQ 社群釋出了新一代 RocketMQ 的能力全景圖,為眾多開發者闡述 RocketMQ 5.0 這一大版本的技術定位與發展方向。

在過去七年大規模雲端計算實踐中,RocketMQ 不斷自我演進,今天,RocketMQ 正式邁進 5.0 時代。

從社群關於5.0版本的解讀可以看到,在雲原生以及企業全面上雲的大潮下,為了更好地匹配業務開發者的訴求,Apache RocketMQ 做了很多的架構升級和產品化能力的適配。那麼如何在企業的生產實踐中落地RocketMQ 5.0呢?本篇文章 的核心 就訊息架構以及產品能力的雲原生化,介紹 阿里雲是如何基於全新的RocketMQ 5.0核心做出自己的判斷和演進, 以及 如何適配越來越多的企業客戶 技術和能力 方面的 訴求。

雲原生訊息服務的演進方向

首先我們來看下雲原生訊息服務有哪些演進?

面向未來,適應雲原生架構的訊息產品能力應該在以下方面做出重要突破:

  • 大規模彈性: 企業上雲的本質是解放資源供給的負擔和壓力,專注於業務 整合和發展。作為訊息服務的運維方,應該為上層業務提供 模型匹配的資源供給能力,伴隨業務流量的發展提供最貼合的彈效能力。一方面可以解決面向不確定突發流量的系統風險,另一方面也可以實現資源利用率的提升。
  • 易用性: 易用性是整合類中介軟體的重要能力,訊息服務應該從API設計到整合開發、再到配置運維,全面地降低使用者的負擔,避免犯錯。低門檻才能開啟市場,擴大心智和群體。
  • 可觀測性: 可觀測性對於訊息服務的所有參與方來說都很重要,服務提供方應提供邊界清晰、標準開放的觀測診斷能力,這樣才能解放訊息運維方的負擔,實現使用者自排查 邊界責任 清晰化。
  • 穩定性高SLA: 穩定性是生產系統必備的核心能力,訊息來說往往整合在核心交易鏈路,訊息系統應該明確服務的可用性、可靠性指標。使用方 基於明確的SLA去設計自己的故障兜底和冗餘安全機制。

立足於這個四個關鍵的演進方向,下面為大家整體介紹 下阿里雲 RocketMQ 5.0在這些方面是如何落地實踐的。

大規模彈性:提供匹配業務模型的最佳資源供給能力

訊息服務一般整合在業務的核心鏈路,比如交易、支付等場景,這一類場景往往存在波動的業務流量,例如大促、秒殺、早高峰等。

面對波動的業務場景,阿里雲RocketMQ 5.0的訊息服務可以伴隨業務的訴求進行自適應實現資源擴縮。一方面在比較穩定的業務處理基線範圍內,按照最低的成本預留固定的資源;另一方面在偶爾存在的突發流量毛刺 ,支援自適應彈性,按量使用,按需付費。兩種模式相互結合,可以實現穩定安全的高水位執行,無需一直為不確定的流量峰值預留大量資源。

除了訊息處理流量的彈性適應外,訊息系統也是有狀態的系統,儲存了大量高價值的業務資料。當系統呼叫壓力變化時,儲存本身也需要具備彈效能力,一方面需要保障資料不丟 ,另一方面還需要節省儲存的成本,避免浪費。傳統的基於本地磁碟的架構天然存在擴縮 問題, 其一 本地磁碟容量有限,當需要擴大容量時只能加節點,帶來計算資源的浪費; 其二 本地磁碟無法動態縮容,只能基於業務側流量的隔離下線才能縮減儲存成本,操作非常複雜。

阿里雲RocketMQ 5.0的訊息儲存具備天然的Serverless能力,儲存空間按需使用,按量付費,業務人員只需要按照需求設定合理的TTL時間 即可保障長時間儲存 的資料完整性。

整合易用性:簡化業務開發,降低心智負擔和理解成本

整合易用性是一種系統設計約束,要求訊息服務應該從API設計到整合開發、再到配置運維,全面地降低使用者的負擔,避免犯錯。舉個典型場景,在訊息佇列例如RocketMQ 4.x版本或Kafka中,業務消費訊息時往往被負載均衡策略所困擾,業務方需要關注當前訊息主題的佇列數(分割槽數)以及當前消費者的數量。因為消費者是按照佇列粒度做負載均衡和任務分配,只要消費者能力不對等,或者數量不能平均分配,必然造成部分消費者堆積、無法恢復的問題。

在典型的業務整合場景,客戶端其實只需要以 無狀態的訊息模型進行消費,業務只需關心訊息本身是否處理即可,而不應該關心內部的儲存模型和策略。

阿里雲RocketMQ 5.0正是基於這種思想提供了全新的SimpleConsumer模型,支援任意單條訊息粒度的消費、重試和提交等原子能力。

可觀測性:提供邊界清晰、標準開放的自助診斷能力

有運維訊息佇列經驗 的同學 都會發現 訊息系統耦合了業務的上游生產和下游消費處理,往往業務側出問題時無法清晰地界定是訊息服務異常還是業務處理邏輯的異常。

阿里雲RocketMQ 5.0的可觀測性就是為這種模糊不確定的邊界提供解法, 事件、軌跡、指標這三個 方面為基礎 ,依次從點、線、面的緯度覆蓋鏈路中的所有細節。關於事件、軌跡、指標的定義涵蓋如下內容:

  • 事件:覆蓋服務端的運維事件,例如宕機、重啟、變更配置;客戶端側的變更事件,例如觸發訂閱、取消訂閱、上線、下線等;
  • 軌跡:覆蓋訊息或者呼叫鏈的生命週期,展示一條訊息從生產到儲存,最後到消費完成的整個過程,按時間軸抓出整個鏈路的所有參與方,鎖定問題的範圍;
  • 指標:指標則是更大範圍的觀測和預警,量化訊息系統的各種能力,例如收發TPS、吞吐、流量、儲存空間、失敗率 成功率等。

阿里雲RocketMQ 在可觀測性方面也是積累良多,不僅率先支援了完善的訊息軌跡鏈路查詢,而且在5.0新版本中還支援將客戶端和服務端的Trace、Metrics資訊以標準的OpenTelemetry協議上報到第三方Trace、Metrics中儲存,藉助開源的Prometheus和Grafana等產品可以實現標準化的展示和分析。

穩定性SLA:提供可評估、可量化、邊界明確的服務保障能力

穩定性是生產系統必備的核心能力,訊息系統往往整合在核心交易鏈路,訊息系統是否穩定直接影響了業務是否完整和可用。但穩定性的保障本身並不只是運維管理,而是要從系統架構的設計階段開始梳理,量化服務邊界和服務指標,只有明確了服務的可用性 可靠性指標,使用方才能設計自己的故障兜底和冗餘安全機制。

傳統的基於運維手段的被動保障方式,只能做基本的擴縮容和系統指標監控,對於訊息的各種複雜邊界場景,例如訊息堆積、冷讀、廣播等並不能很好的提供量化服務能力。一旦上層業務方觸發這些場景,系統則會被打穿, 從而 喪失服務能力。

阿里雲RocketMQ 5.0體系化的穩定性建設 是從系統設計階段就提供對訊息堆積、冷讀等場景量化服務的能力,確定合理的訊息傳送RT、端到端延遲和收發吞吐TPS能力等,一旦系統觸發這些情況,可在承受範圍內做限制和保護。

本篇文章從大規模彈性、整合易用性、可觀測性和穩定性SLA等方面介紹了RocketMQ 5.0的演進和方向,同時針對性介紹了阿里雲 訊息佇列 RocketMQ 5.0在這些方面的實踐和落地。

阿里雲訊息佇列RocketMQ 5.0目前已正式商業化, 在功能、彈性、易用性和運維便捷性等方面進行了全面增強,同時定價相比上一代例項最高降低50%,助力企業降本增效,以更低的門檻實現業務開發和整合。新一代例項支援0~100萬TPS規模自由伸縮、支援突發流量彈性和儲存Serverless;在可觀測性方面,支援全鏈路軌跡整合和自定義Metrics整合;在整合易用性方面,支援新一代輕量原生多語言 SDK,更加穩定和易用。

點選閱讀原文, 即可進入RocketMQ 5.0 商業化版本釋出會直播間~

https://www. aliyun.com/page-source/ developer/special/rocketmq5

版權宣告: 本文內容由阿里雲實名註冊使用者自發貢獻,版權歸原作者所有,阿里雲開發者社群不擁有其著作權,亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容,填寫侵權投訴表單進行舉報,一經查實,本社群將立刻刪除涉嫌侵權內容。