構建企業級統一基礎推送服務，支持通過多渠道推送，能夠統一集成的電子郵件、短信、聊天、釘釘、企業微信和其他公共社交應用：

聊天 - 微信Wechat/QQ

站內推送通知（移動設備和Web瀏覽器）

站外推送通知（移動設備，APP沒有開啟）

短信（如登錄密碼、營銷活動）

電子郵件

釘釘

企業微信

企業級統一基礎推送服務，是一個通用特性，適用于所有現代分布式應用，無論采用何種編程語言和技術。

推送能力的演進

第一階段（模塊化）：各自為政、各自封裝

企業內部，早期業務量比較少，各系統基本都是有自己的推送模塊，類型也是五花八門：

聊天模塊

短信模塊

電子郵件模塊

websocket 模塊

各自封裝模塊比較簡單，但是實現分散、各系統模塊的質量也很難統一保證。

第二階段（框架化）：集成框架

為了減少重復性設計、開發成本， 設計了統一的推送框架

同一套微服務框架，共用一個統一的推送框架

為了解決上述分散實現的問題，企業內部統一實現了一個綜合各類推送功能的基礎庫，供業務方統一調用。

聊天基礎starter

短信基礎starter

電子郵件基礎starter

websocket 基礎starter

于是，我們把 springboot-starter的邏輯封裝到了服務治理框架內，微服務服務啟動時，每一個服務對各種的starter進行運維管理、配置管理。

第三階段（服務化）：推送服務

集成到框架，每一套服務，都需要重復性的解決3高問題。

推送服務，數據量大，需要解決跨庫查詢問題

推送服務，性能要求高，需要解決高并發問題

大數據量、并發量高，意味著：

硬件資源投入大

運維成本高

這樣的基礎服務，需要進行沉淀，剝離，集中成統一的、基礎服務，由專門團隊負責維護、迭代、運維。降低重復投入、重復建設成本， 真正的降本增效。

于是， 推送框架 演進為 推送服務

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

推送服務在業務系統中的位置

一個業務應用， 基本上有很多原子服務編排、整合而來，最終構建出一個完整的架構圖。

接入層，這是外部請求進入內部系統的門戶，所有的請求都必須通過 API 網關。

應用層，也被稱為聚合層，它為相關業務提供聚合接口，并調用中臺服務進行組合。

原子服務，包括就是原子技術服務，原子業務服務，根據業務需求提供相關的接口。原子服務為整個架構提供可復用的能力。

例如，在B站視頻網站平臺上，評論服務作為一項原子服務，在B站的視頻、文章、社區都需要，那么為了提高復用性，評論服務就可以獨立為原子服務，不能與特定需求緊密耦合。

在這種情況下, 評論服務，需要供一種可以適應不同場景的復用能力。

注意：請點擊圖像以查看清晰的架構圖！

類似的，文件存儲、數據存儲、推送服務、身份驗證服務等功能，都會沉淀為原子服務，業務開發人員，在原子服務基礎上，進行編排、配置、組合，可以快速構建業務應用。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

推送服務功能要求

發送通知

對通知進行優先級排序

根據客戶的保存偏好發送通知

支持單個/簡單的通知消息和批量通知消息

各種通知的分析用例

通知消息的報告

推送非功能性需求（NFR）

高性能：qps > 1W

高可用性（HA）：99.99%

低延遲：TP99 在10ms以下

高擴展：可擴展/可插拔的設計，以便添加更多適配器和提供商，與所有通知模塊的API集成以及與客戶端和服務提供商/供應商的外部集成

跨平臺：支持Android/iOS移動設備和桌面/筆記本電腦的Web瀏覽器

自伸縮：可在本地（VMware Tanzu）和 AWS、GCP 或 Azure 等公共云服務上擴展負載

推送系統設計架構

注意：請點擊圖像以查看清晰的架構圖！

這些解決方案設計的考慮因素和組件包括：

1. 通知客戶端

這些客戶端通過 API 調用請求單個和批量消息。它們將向簡單和批量通知服務發送通知消息。

簡單通知客戶端：專門用于發送單個通知的客戶端，負責向用戶發送單一通知。這些客戶端通常用于向特定用戶發送重要通知，例如密碼找回或賬戶異常提醒。

批量通知客戶端：專門用于發送批量通知的客戶端，負責向用戶批量推送通知。這些客戶端通常用于需要通知大量用戶的場景，例如企業內部通知或營銷活動。

2. 通知服務

作為入口點的這些服務，通過暴露 REST API 與客戶端互動。

它們負責構建通知消息，通過調用"模板服務"。這些消息將使用"驗證服務"進行驗證。

簡單通知服務：該服務將提供 API，主要負責處理簡單通知請求，提供與后端服務集成的 API，以便將通知發送給用戶。這種服務通常用于處理較少的通知請求，例如針對特定用戶或事件的簡單通知。

批量通知服務：該服務將提供 API，主要負責處理批量通知請求，提供與后端服務集成的 API，以便批量發送通知。這種服務通常用于處理大量的通知請求，例如企業內部的批量通知或營銷活動的批量推送。

此服務還將管理通知消息。它將發送的消息持久化到數據庫并維護活動日志。

可以使用這些服務的 API 重新發送同一條消息。

它將提供添加/更新/刪除和查看舊消息和新消息的 API。

它還將提供 Web 儀表板，該儀表板應具有篩選選項，以根據不同的條件（如日期范圍、優先級、模塊用戶、用戶組等）篩選消息。

3. 模板服務

此服務主要負責所有可用的一次性密碼（OTP）、短信、電子郵件、聊天以及其他推送通知消息的模板管理。

它還提供了 REST API，以便創建、更新、刪除和管理模板。

除此之外，它還將提供一個用戶界面（UI）的儀表板頁面，使用戶能從網絡控制臺檢查和管理各種消息模板。

4. 消息分發服務

定時分發服務：

該服務將提供API來安排立即或指定時間的通知?？梢允且韵氯魏我环N：

秒

分鐘

每小時

每天

每周

每月

每年

自定義頻率等。

還可能有其他自動觸發的服務，基于預定時間進行消息觸發。

消息驗證服務：

此服務全權負責根據業務規定和預期格式對通知信息進行核實。批量通知需由授權的系統管理員同意。

消息優先級服務：

該服務負責對通知進行優先級排序，分為高、中、低三個等級。

通知信息具有較高的優先級和有時間限制的到期時間，它們將始終以較高優先級發送。

"通用出口處理器"會接收消息并根據相同的優先級從高、中和低三個不同的隊列中發送和處理。

在非工作時間，可以以低優先級發送批量通知。

在交易過程中的應用程序通知可以發送到中優先級，如電子郵件等。企業可以根據通知的重要性確定優先級。

5. 事件優先級隊列（消息隊列）

此服務提供事件中心功能，負責接收通知服務的高、中、低三個優先級的信息。

它會根據業務的優先級來發送和接收通知。企業可以根據通知的重要性來設定優先級。

服務內部包含三個主題，用于根據業務優先級接收和發送通知：

低優先級：主要用于在非工作時間發送批量通知。

中優先級：適用于在交易過程中發送的應用程序通知，如電子郵件等。

高優先級：通知信息具有較高的優先級和有時間限制的到期時間，它們將始終以較高優先級發送。關注公工眾號：碼猿技術專欄，回復關鍵詞：1111 獲取阿里內部Java性能調優手冊！

6. 通用出站處理程序

該服務通過輪詢事件優先級隊列來接收事件中心中的通知信息，并根據其優先級進行處理。

高優先級的通知會優先處理"高"隊列，依次類推。

最后，它通過事件中心將通知信息發送到特定的適配器。

此外，該服務還從用戶選擇服務中獲取目標用戶/應用程序，以便進行通知的分發。

在處理過程中，通用出口處理器會根據事件的優先級進行相應的操作，確保重要事件得到優先處理。

這樣，企業可以根據通知的優先級來確定處理順序，從而提高通知的處理效率。

除此之外， 通用出站處理程序，還能進行消息的進一步按照通道類型進行分發：

該服務將消息發送到各種支持的適配器。

這些適配器會根據不同的設備（如桌面/移動設備）和通知類型（如短信/OTP/電子郵件/聊天/推送通知）進行轉換。

7. 通知適配器

這些轉換器將從消息隊列（rocketmq）接收傳入信息并根據其所支持的格式傳遞給外部合作伙伴。

以下是一些轉換器，根據需求可以增加更多：

QQ 通知適配器服務

微信Wechat 聊天通知適配器服務

應用內通知適配器服務

電子郵件適配器服務

短信適配器服務

OTP 適配器服務

8. 通道供應商

這些是外部的 SAAS（云上/本地）服務提供商，利用它們的基礎設施和技術實現實際的通知傳遞。

它們可能是像 AWS SNS、MailChimp 等的付費推送通道服務。

QQ 供應商集成服務

微信Wechat 供應商集成服務

應用推送通知供應商集成服務

電子郵件供應商集成服務

短信供應商集成服務

9. 用戶選擇服務

該服務提供選擇目標用戶和各種應用程序模塊的功能。

這可能包括將批量消息發送到特定的用戶組或不同的應用程序模塊。

可能是 AD/IAM/eDirectory/用戶數據庫/用戶組，具體取決于客戶的偏好。

在服務內部，它將使用"用戶配置文件服務"API 來消費和檢查客戶的通知偏好。

10. 用戶配置文件服務

此服務提供各種功能，包括管理用戶配置文件及其偏好設置。

還管理內部用戶標識，和外部通道標識之間的關聯關系

釘釘用戶標識 和 用戶標識 關聯關系

企業微信 用戶標識 和 用戶標識 關聯關系

用戶和郵箱的關聯關系

等等

它還將提供取消訂閱通知以及通知接收頻率等功能。

"通知服務"將依賴于此服務，以便根據用戶的通知偏好來發送通知。

此外，該服務還可以用于統計和分析用戶對通知的偏好，以幫助企業優化通知策略。

11. 分析服務

該處理器將負責執行所有的分析工作，識別通知使用情況、趨勢并生成報告。

它將從分析數據庫（Cassandra）和通知數據庫中提取所有最終的通知信息，用于分析和報告目的。

以下是一些用例：

每天/每秒的總通知數

哪個通知系統使用最頻繁

消息的平均大小和頻率

基于優先級過濾消息等等...

12. 通知跟蹤器

此服務將持續監視事件中心隊列并跟蹤所有發送的通知。

它捕獲通知的元數據，如傳輸時間、傳送狀態、通信渠道、消息類型等。

13. 通知數據庫：Mysql數據庫集群

通知數據庫，用于存儲庫用于存儲所有通知信息，包括發送時間、狀態等。

它包括一個數據庫集群，其中領導者用于執行所有寫操作，讀取操作則在讀取副本/跟隨者上進行。

這個數據庫群集將持久化所有通知，供分析和報告使用。

它基于“寫入更多，讀取更少”的理念。

它能提供良好的性能和低延遲，適應大量的通知，因為它內部處理大量的寫操作，并與其他數據庫節點同步，保持高可用性和可靠性的冗余數據/消息。

在任何節點崩潰的情況下，消息將始終可用。