億級訊息中心架構方案概述【原創】

車江毅發表於2021-06-15
目標
技術目標: 上行到訊息佇列api吞吐量10000條/秒,下發第三方平臺1000條/秒(僅平臺自身處理能力,第三方看第三方處理能力極限指標為準);保證訊息中心100%高可用。
業務目標: 對接新需求,明確訊息中心的負責人(架構組),及時響應業務處理或者反饋。
產品目標: 支援訊息處理狀態查詢,簡單的訊息規範訊息對接(初級開發5分鐘實現接入成本),規範化訊息模板辦理。
 
需求原型
功能需求:
支援阿里雲簡訊,微信公眾號,app推送,統一站內信,企業微信(應用,個人)等第三方推送。
包含訊息模板管理,賬戶管理,訊息搜尋,批量訊息傳送等。
 
技術方案
業務部署互動圖

 

 

業務核心邏輯互動圖

 

 

 
技術選型
優勢
缺點
rocketmq
【效能好】單個吞吐量能達10萬/秒,並行推送能力(消費能力)可以通過rocketmq的分割槽(分割槽細節需要設計)數量進行擴充套件。效能上面是一個亮點和優勢
【部分功能不支援】一旦進入rocketmq佇列,推送訊息不可撤回。很多資料庫層面的功能特性(mq不支援)在設計上就會捨棄。
es
【效能好】可以支撐上億的資料量的關鍵詞搜尋,實時同步的效能和吞吐量都還可以。
【併發插入能力略差】假設訊息下發吞吐量高,需要批量對訊息進行同步,這樣可以優化es吞吐量。高併發對es同步,es承載能力可能會出問題(可以投入測試進行驗證)。
 
概要設計描述
1. rocketmq 設計正常訊息佇列(正常投遞訊息),重試訊息佇列(支援多種延遲機制,傳送失敗重試的訊息),傳送結果訊息佇列(傳送超限或者成功的訊息)。
2. es 同步以上三種佇列的訊息,以最終一致性(最晚時間戳校驗)保持訊息資訊最新。
3. mysql 僅支援管理模板,賬號等基礎管理功能。
 
底層框架設計、運維層面描述
1. 統一閘道器: spring cloud gateway/kong,僅做api層面的路由支援。
2. 基礎框架: 選定jar包版本,es,rocketmq,實時報警,效能監控 對這些介面做二次封裝,es支援sql模式插入查詢;rocketmq做底層實現剝離。
參考: bsf 統一基礎框架 https://gitee.com/yhcsx/csx-bsf-all
3. 業務框架: 標準輸入輸出http rpc等業務框架工具或協議層面支援。
4. 服務高可用:k8s&docker 及devops 線上一體化部署的支援,要做到一鍵釋出,一鍵回滾,滾動釋出,不停機發版。
 
by 車江毅
 

相關文章