本文由騰訊云架構(gòu)師技術(shù)同盟策劃，作者章為忠，原題“如何設(shè)計一個企業(yè)級消息推送系統(tǒng)架構(gòu)？”，下文有修訂和重新排版。

1、引言

想象一下這樣的場景：隨著企業(yè)規(guī)模擴大，業(yè)務(wù)系統(tǒng)日益增多，而幾乎每個系統(tǒng)都包含消息通知的功能模塊。此時，各業(yè)務(wù)系統(tǒng)不得不重復(fù)開發(fā)消息推送功能，不僅耗費大量人力與時間成本，功能質(zhì)量也難以統(tǒng)一保障。更麻煩的是，郵件、短信、企業(yè)微信等推送渠道各自為戰(zhàn)，推送效果參差不齊不說，還讓管理工作陷入混亂。加之不同渠道的消息分散在各處，員工稍不留意就可能錯過重要通知，影響工作效率與決策及時性。

如果你是技術(shù)負責人，該如何搭建一套能解決這些問題的企業(yè)級統(tǒng)一消息推送平臺？今天我們就從核心挑戰(zhàn)出發(fā)，拆解一套可落地的統(tǒng)一推送服務(wù)架構(gòu)方案。

2、面臨的技術(shù)挑戰(zhàn)

在動手畫圖做方案之前，我們必須先明確設(shè)計一個消息推送系統(tǒng)面臨哪些核心挑戰(zhàn)。

這些是架構(gòu)設(shè)計的關(guān)鍵所在：

1）多渠道集成難題：郵件、短信、企業(yè)微信等渠道的接口規(guī)范和推送邏輯存在較大差異，如何將它們完美集成？這背后需要解決接口適配、協(xié)議轉(zhuǎn)換等底層問題。

2）高并發(fā)與高性能要求：隨著業(yè)務(wù)的增長或是促銷活動期間，消息量可能從日均 10 萬飆升至 100 萬，系統(tǒng)必須能夠扛住高并發(fā)，保證 “推得快、不卡頓”，同時要具備足夠大的吞吐量和足夠低的延遲。

3）可靠性與可用性要求：核心消息（訂單提醒、會議通知等）一旦丟失或重復(fù)發(fā)送都會造成嚴重問題，因此必須確保100% 送達；系統(tǒng)還需實現(xiàn) 7×24 小時不間斷運行，杜絕單點故障。

4）靈活的模板與個性化推送：不同的業(yè)務(wù)需要配置不同的消息模版（營銷活動需要活潑的模板，財務(wù)通知則需要嚴謹?shù)母袷剑?；此外，還要能夠根據(jù)用戶偏好進行推送（例如用戶只查看企業(yè)微信消息），以提高觸達效果。

5）易于集成與擴展：各業(yè)務(wù)系統(tǒng)要能夠 “即插即用” 地接入推送服務(wù)；而且，未來新增渠道、新業(yè)務(wù)時，需要確保無需對平臺進行大規(guī)模修改就能快速支持。

在深入了解當前消息推送工作中存在的各類問題與潛在挑戰(zhàn)之后，我們再來梳理一條消息從發(fā)送到接收都經(jīng)歷了哪些過程和處理？推送系統(tǒng)在企業(yè)整體架構(gòu)中處于什么位置？請接著往下讀。。。

3、系統(tǒng)架構(gòu)核心流程解析（消息推送的全鏈路步驟）

消息推送從發(fā)起至接收的核心流程步驟如下：

第1步：在各應(yīng)用系統(tǒng)發(fā)送通知內(nèi)容到消息網(wǎng)關(guān)；既可以單條推送，也可以支持批量推送；例如常見的訂單通知和支付通知。

第2步：接下來，由消息網(wǎng)關(guān)轉(zhuǎn)發(fā)到消息分發(fā)服務(wù)，在這一層，將會對消息進行驗證、確定好優(yōu)先級、套用格式模板（這里對應(yīng)在后臺維護一個模板庫）和確定發(fā)送的時間。

第3步：進入到消息路由，也就是技術(shù)上常說的異步消息隊列。

第4步：通過各個消息渠道，進行具體的消息發(fā)送，如：APP站內(nèi)通知/郵件通知/短信通知/社交賬號通知/辦公群通知等。

第5步：通知的發(fā)送記錄和狀態(tài)，以及統(tǒng)計分析（例如同一個賬號同一天發(fā)送多少條）。

第6步：就是整體的推送統(tǒng)計，例如：每周總共發(fā)送多少次、觸達多少用戶、打開閱讀量有多少、轉(zhuǎn)化多少，從而不斷提升你產(chǎn)品的用戶體驗。

4、推送系統(tǒng)在全局系統(tǒng)架構(gòu)中的位置

從架構(gòu)結(jié)構(gòu)來看，一個復(fù)雜業(yè)務(wù)平臺通常涵蓋表現(xiàn)層、接入層、應(yīng)用層、服務(wù)層（含中臺）及基礎(chǔ)層等核心模塊。作為業(yè)務(wù)系統(tǒng)中不可或缺的組成部分，推送服務(wù)并不直接面向終端用戶，而是支撐各類應(yīng)用穩(wěn)定運行的基礎(chǔ)性服務(wù)。

它在整體架構(gòu)中的具體位置如下所示：

（▲ 圖中紅色部分為統(tǒng)一消息推送平臺）

5、推送系統(tǒng)整體架構(gòu)設(shè)計

5.1 概述

接下來將正式啟動并著手設(shè)計一套更為完整、系統(tǒng)且具備可擴展性的統(tǒng)一消息推送架構(gòu)體系。平臺采用「接入層 - 業(yè)務(wù)層 - 服務(wù)層 - 數(shù)據(jù)存儲」的四層架構(gòu)，通過各層協(xié)同實現(xiàn)消息推送的標準化與高效化。

具體架構(gòu)如下圖所示：

上圖展示了統(tǒng)一推送平臺的整體架構(gòu)。每一層的功能和作用將在下面的小節(jié)中分別介紹。

5.2 接入層

作為外部請求進入系統(tǒng)的第一道關(guān)口，接入層核心作用是「過濾無效請求，筑牢系統(tǒng)安全防線」。

這一層通過 API 網(wǎng)關(guān)集中管理所有推送請求，重點完成三項管控：

1）身份驗證：僅授權(quán)業(yè)務(wù)系統(tǒng)憑有效憑證調(diào)用，阻斷非法訪問。

2）權(quán)限校驗：按規(guī)則限定不同系統(tǒng)的推送渠道，比如 A 系統(tǒng)可用短信、B 系統(tǒng)僅開放企業(yè)微信，避免越權(quán)。

3）流量控制：設(shè)置閾值（如單系統(tǒng)每秒最多發(fā) 1000 條）實現(xiàn)削峰，防范攻擊或突發(fā)流量壓垮系統(tǒng)。

舉例來說：營銷系統(tǒng)調(diào)用推送接口時，API 網(wǎng)關(guān)會先驗 token 有效性，確認其有短信和郵件權(quán)限后，再限制請求頻率，確保消息推送節(jié)奏在系統(tǒng)承載范圍內(nèi)，從接入環(huán)節(jié)保障流程安全穩(wěn)定。

5.3 業(yè)務(wù)層

負責解析請求、做核心決策，是業(yè)務(wù)規(guī)則的集中處理中心。

收到請求后，先解析內(nèi)容：要推給誰？用什么模板？什么時候推？優(yōu)先級高不高？

比如：收到訂單系統(tǒng)「訂單支付成功」的推送請求，會先匹配「支付通知」模板，確定接收人，設(shè)為消息推送的優(yōu)先級「高」（必須立即推），再判斷發(fā)送渠道，調(diào)用對應(yīng)的消息推送服務(wù)。

5.4 服務(wù)層

集成所有推送渠道，把統(tǒng)一格式的消息「翻譯」成各渠道能識別的格式。

核心是「適配器模式」：每個渠道對應(yīng)一個適配器（如短信適配器、企業(yè)微信適配器），適配器負責格式轉(zhuǎn)換和接口調(diào)用。

比如：企業(yè)微信適配器，會把業(yè)務(wù)邏輯層生成的消息，按企業(yè)微信 API 要求的格式組裝（加簽名、填應(yīng)用 ID），再調(diào)用企業(yè)微信的接口發(fā)送。需要接入新渠道時，只需開發(fā)一個對應(yīng)的適配器即可，不用改其他層，擴展性拉滿。

5.5 數(shù)據(jù)存儲層

數(shù)據(jù)存儲層主要是對全流程數(shù)據(jù)、消息進行系統(tǒng)化管理。

即存儲原始消息內(nèi)容、推送參數(shù)等業(yè)務(wù)數(shù)據(jù)，也記錄各環(huán)節(jié)的處理日志、渠道反饋結(jié)果與用戶交互行為數(shù)據(jù)。

通過統(tǒng)一的數(shù)據(jù)模型與存儲規(guī)范，為后續(xù)的推送效果分析、業(yè)務(wù)優(yōu)化與數(shù)據(jù)追溯提供可靠的數(shù)據(jù)支撐，形成 “接入 - 處理 - 分發(fā) - 存儲” 的閉環(huán)管理體系。

6、推送系統(tǒng)技術(shù)架構(gòu)設(shè)計

6.1 應(yīng)用集成架構(gòu)

業(yè)務(wù)系統(tǒng)（ERP、OA、CRM、IM聊天、客服系統(tǒng)等）通過接口方式接入統(tǒng)一消息平臺，能夠接入短信、郵件、站內(nèi)信、企業(yè)微信等多種信息渠道，支持以操作界面形式實現(xiàn)統(tǒng)一消息發(fā)送?？赏ㄟ^平臺界面，編輯消息內(nèi)容或引用消息模板，實現(xiàn)信息的多渠道統(tǒng)一發(fā)送。

平臺應(yīng)用集成架構(gòu)如下圖所示：

6.2 平臺技術(shù)架構(gòu)

我們將整個平臺系統(tǒng)拆解為多個關(guān)鍵服務(wù)模塊，比如：

1）消息融合接收服務(wù)；

2）消息處理分發(fā)服務(wù)；

3）消息模版服務(wù)；

4）渠道發(fā)送服務(wù)；

5）后臺管理服務(wù)等。

這些服務(wù)模塊全面覆蓋從請求接入到消息推送、再到后續(xù)分析的全流程。

完整的技術(shù)架構(gòu)圖如下：

7、本文小結(jié)

企業(yè)級統(tǒng)一基礎(chǔ)推送服務(wù)，是一個通用特性，適用于所有現(xiàn)代分布式應(yīng)用，無論采用何種編程語言和技術(shù)。通過統(tǒng)一推送服務(wù)解決分散推送的痛點，避免了開發(fā)重復(fù)造輪子，消息更精準、渠道更符合偏好、關(guān)鍵消息不丟失、系統(tǒng)不宕機。讓消息真正成為業(yè)務(wù)運轉(zhuǎn)的助力而非負擔。

不過在實際落地時，需結(jié)合企業(yè)規(guī)模靈活調(diào)整：若企業(yè)僅部署少數(shù)幾個業(yè)務(wù)系統(tǒng)，單獨搭建完整的推送系統(tǒng)反而可能造成資源浪費，此時選擇輕量化的集成方案會更具性價比。