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