本文作者：古崟佑，阿里云中間件開發，
RocketMQ 5.0 版本擁有非常多新特性，比如存盤計算分離、 batch 能力的提升等，它是具有里程碑意義的版本，
提到新版本，我們往往會首先想到服務端架構的設計變動，很容易忽略客戶端的設計理念，客戶端也是訊息產品的必要組成部分，許多特性需要 client 與 server 兩端互相協作，才能更好地實作，
輕量化、云原生以及統一模型是 RocketMQ 5.0 客戶端的三個設計理念，
01 輕量化
輕量化的重點在于輕邏輯、輕流程，化繁為簡，減少多語言生態發展的阻礙，
上圖列舉了 RocketMQ 4.x 版本和 RocketMQ 5.0 版本的差異，
①4.x 版本的序列化使用 JsonCodecs 和 RocketMQCodecs，5.0 版本使用的則是標準的 Protobuf 協議，多語言發展的阻礙包括許多不規范，比如 RocketMQ 自定義序列化對于其他的語言需要自己實作一套協議以實作正反序列化決議，而 Json 作為標準序列化協議，基本可以實作所有語言的正反序列化，但缺點也非常明顯，冗余資訊過多，體積占用太大，因此更多用于 restful 架構等前后端互動的場景，此外，訊息中間件場景無需關心傳輸資料時是否可讀，因此， Protobuf 成為了選擇，它原生支持多語言，且傳輸時體積占用非常小，成熟且標準，
②此前客戶端使用 consumer 消費資訊時，會存在計算邏輯比如重平衡 以及系統級 topic 處理，但是 RocketMQ 5.0 版本將所有計算邏輯上移到了服務端，客戶端只需簡單地呼叫 Receive 介面，也無需額外處理系統級 topic ，整體邏輯變得非常輕量，
③4.x版本的實作和維護成本非常高，因此5.0版本并沒有基于4.x進行迭代和更新，設計之初有一種思路為直接在4.x客戶端上增加 gRPC 協議，迭代升級成為5.0，但這相當于扛著歷史包袱往前走，也違背了輕量化原則，因此被否定，
02 云原生
云的彈性、高可用性以及互動運維能力在 RocketMQ 5.0 客戶端中均有體現，分別對應極致彈性伸縮、低耦合以及云端一體，
上圖為 4.x版本和5.0版本的客戶端，在4.x版本中， 一個 Queue 最多對應一個 consumer，增加 consumer 不一定能提升消費并發，其彈性有上限，但在 RocketMQ 5.0，每一個 consumer 可以向所有 broker 發起 Pop 請求，此前為 push 模式，現在改為 pop 請求，提升 consumer 數量能夠提升消費并發，即使只有一個佇列，也可以生成數百數千個消費者統一拉取佇列訊息，
比如購物網站突發退貨流量高峰，此前最簡單有效的方式為增加業務應用數量、增加處理并發，比如增加退貨系統和客戶系統核心的應用資料，但如果一開始佇列數設定并沒有這么多，則需要先擴容佇列，再擴容核心業務數，同時，擴容后也僅對新入隊的訊息處理速度有提升，已經造成堆積的佇列消費速度依然緩慢，此時會出現一種情況，先提交的退貨申請后被處理，會對用戶體驗造成影響，
而 RocketMQ 5.0 的 pop 消費模型只需直接增加業務處理節點數即可解決問題，
已堆積佇列無法通過擴容的方式加速消費，與低耦合場景相似，比如在4.x版本中，假如某消費節點發生 FullGC ，消費比較慢，但是沒有完全下線，依然與服務端保持著心跳，因此佇列依然會被分配至該節點，分配佇列逐漸堆積可能會引發一系列問題，
但在 RocketMQ 5.0，如果某節點發生 FullGC，分配粒度會從佇列退化為訊息，分配的訊息消費緩慢，不會產生堆積，
因此，從極致彈性和低耦合上可以看出 RocketMQ 5.0 之后使用 Pop 協議的優越性，只需要簡單地在消費能力不足時擴容、富余時縮容，單一節點故障也不會影響到全域，
云可以理解為遠在機房的服務端，端則嵌在業務 SDK，此前，在控制臺上進行運維操作時，只能控制服務端，對客戶端的掌控非常有限，使用體驗非常割裂，比如更改服務端配置，除了白屏也可以通過命令工具輕松修改配置，且及時生效，但如果客戶端修改配置，則會涉及到業務發布，很容易出現問題，
RocketMQ 5.0 采用 telemetry 遙測協議與服務端進行協同，遙測協議的作用為使云和端之間通過 telemetry 進行互動，包括但不限于限流策略、重試策略、發布和訂閱關系管控、可觀測開關、接入點資訊、堆疊資訊等，主要實作方式為直接由 SDK 向服務端發起 telemetry 請求，然后往 observer 讀寫上圖所示的指令即可，
指令型別包括設定、列印堆疊、驗證訊息、消費以及事務訊息回查，其中比較關鍵的能力為可觀測開關以及 OTLP 接入點資訊，
以往的可觀測是基于訊息軌跡實作，在發送訊息和消費訊息時，將背景關系中的引數添加進軌跡訊息，在后臺攢批異步發送，上圖為發送訊息的所有 context，包括MessageQueue、MessageID 、IP 等資訊，
上圖為消費時的 context ，對于單個 MessageID ，端對端會產生三條軌跡訊息，分別為發送后、消費前和消費后，如果想要跟蹤訊息輪轉軌跡，可以通過查詢軌跡的訊息資料找到它，因其將 MessageID 作為 key 值插入到 topic ，而此前需要在控制臺根據 MessageID 查詢軌跡訊息，
RocketMQ 此前已經具備可觀測能力，但自定義可觀測方式無法很好地對接現有的可觀測產品和能力，而5.0版本擁有了標準化的可觀測協議，可以使用更豐富、更專業的分析和展示工具，讓可觀測資料有了更高的價值，
Telemetry 遙測協議是將可觀測開關以及接入點下發到客戶端，Proxy 會默認將接入點資訊設定為自己，可以將客戶端上報的所有可觀測訊息在服務端做收斂，再統一使用標準的 OpenTelemetry 和 Opencensu 兩個協議上報到 SLS ， SLS 再通過 TLog 的方式與 Prometheus、Grafana 進行對接，
Tracing 的資料鏈路比較復雜，也需要先經過 proxy 將可觀測資料導到 proxy 上，而Tracing 的資料量較大，此前也曾考慮過直接通過用戶自定義配置匯出接入點，不經過 proxy ，但這會引發其他問題，比如4.x用戶希望接入 RocketMQ 5.0 服務端使用可觀測能力，則需要通過軌跡訊息解碼進行決議再通過標準化可觀測協議輸出，
多語言方面，最新出的 OpenTelemetry 支持不一定足夠全面，因此也會需要一些舊的可觀測協議比如 Opencensu，但整體來說，它們都是標準的協議，
03 統一模型
此前的 RocketMQ API 缺乏精心設計的訊息模型，很多概念沒有明確的定義，比如發送訊息時有兩個 ID ，分別是用戶自己定義的 MessageID 和服務端下發的 offsetID ，但是在消費時，下發的 offsetID 又變成了 MessageID ，模棱兩可的定義使得預測客戶行為變得更加困難，并且，此前大多以執行為導向，對開發者并不友好，許多功能是基于實作而不是介面，因此用戶需要觸及到很多細節，需要面對過多冗余和復雜界面，出錯概率極大，
另外，發展多語言生態時，也需要統一模型引導多語言的發展實作，
主題型別是其中一個明顯的改變，
此前，客戶端不做 topic 型別校驗，任何一種型別訊息都可以發往 topic ，但是在RocketMQ 5.0 之后會對 topic 型別做校驗，真正從 topic 主題型別上做了區分，比如順序訊息 topic 只能發順序訊息，此前的 delay 訊息為分級別延時訊息，而現在為支持毫秒級精度的定時訊息，可以支持任意時間精度，
同時，模型定義了各種各樣的消費者，有不同的消費者實作，比如 PushConsumer 、PullConsumer 以及 SimpleConsumer ，底層均使用 pop 協議實作，比如以前的PushConsumer 是基于手動拉的方式，而現在采用了 pop 方式，
SimpleConsumer 的使用方法非常簡單，直接呼叫 receive message 介面，獲取到訊息之后進行消費，消費成功則進行 Ack；如果消費失敗，則更改可見時間，整體流程非常直觀，完全基于介面定義，
新版本的啟動流程增加了準備作業，為了能夠更早地捕捉到明顯的錯誤以及例外，比如嘗試從服務端獲取設定，可以對此類設定進行熱更新，稱為服務器和客戶遙測，任何準備失敗都會導致客戶端啟動失敗，而以往可以強行將客戶端拉起，然后不斷進行重試，
增加了準備作業后，配置問題或本身網路問題可以提前被發現，比如 topic 路由資訊不存在，啟動時會先對 bonding topic 做檢查，每一個發送者、生產者可以提前設定預留 topic 資訊，再根據錯誤資訊進行檢查，判斷是否可以啟動，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/541177.html
標籤：其他