今天給大家分享一份較為完整的億級消息中心的架構方案!  

[[407053]]

設計目標

• 技術目標：上行到消息隊列 API 吞吐量 10000 條/秒，下發第三方平臺 1000 條/秒(僅平臺自身處理能力，第三方看第三方處理能力極限指標為準);保證消息中心 100% 高可用。
• 業務目標：對接新需求，明確消息中心的負責人(架構組)，及時響應業務處理或者反饋。
• 產品目標：支持消息處理狀態查詢，簡單的消息規范消息對接(初級開發 5 分鐘實現接入成本)，規范化消息模板辦理。

需求原型

需求原型如下圖：

功能需求：

• 支持阿里云短信，微信公眾號，App 推送，統一站內信，企業微信(應用，個人)等第三方推送。
• 包含消息模板管理，賬戶管理，消息搜索，批量消息發送等。

技術方案

業務部署交互圖：

業務核心邏輯交互圖：

技術選型

①RocketMQ

• 優勢：性能好，單個吞吐量能達 10 萬/秒，并行推送能力(消費能力)可以通過 RocketMQ 的分區(分區細節需要設計)數量進行擴展。性能上面是一個亮點和優勢。
• 缺點：部分功能不支持，一旦進入 RocketMQ 隊列，推送消息不可撤回。很多數據庫層面的功能特性(MQ 不支持)在設計上就會舍棄。

②ES

• 優勢：性能好，可以支撐上億的數據量的關鍵詞搜索，實時同步的性能和吞吐量都還可以。
• 缺點：并發插入能力略差，假設消息下發吞吐量高,需要批量對消息進行同步，這樣可以優化 ES 吞吐量。高并發對 ES 同步，ES 承載能力可能會出問題(可以投入測試進行驗證)。

概要設計描述

• RocketMQ 設計正常消息隊列(正常投遞消息)，重試消息隊列(支持多種延遲機制，發送失敗重試的消息)，發送結果消息隊列(發送超限或者成功的消息)。
• ES 同步以上三種隊列的消息，以最終一致性(最晚時間戳校驗)保持消息信息最新。
• MySQL 僅支持管理模板，賬號等基礎管理功能。

底層框架設計、運維層面描述

①統一網關：Spring Cloud Gateway/Kong，僅做 API 層面的路由支持。

②基礎框架：選定 jar 包版本，ES，RocketMQ，實時報警，性能監控，對這些接口做二次封裝，ES 支持 SQL 模式插入查詢;RocketMQ 做底層實現剝離。

參考 bsf 統一基礎框架：

https://gitee.com/yhcsx/csx-bsf-all 

③業務框架：標準輸入輸出 Http RPC 等業務框架工具或協議層面支持。

④服務高可用：K8s&Docker 及 DevOps 線上一體化部署的支持，要做到一鍵發布，一鍵回滾，滾動發布，不停機發版。

作者：車江毅

編輯：陶家龍

出處：cnblogs.com/chejiangyi/p/14884931.html