目標
技術目標: 上行到訊息佇列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 車江毅