聊聊 消息推送的架構設計

架構目標

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

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

推送能力的演進

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

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

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

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

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

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

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

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

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

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

大數據量、併發量高，意味着：

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

於是， 推送框架 演進爲 推送服務

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

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

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

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

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

推送服務功能要求

推送非功能性需求（NFR）

推送系統設計架構

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

1. 通知客戶端

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

2. 通知服務

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

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

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

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

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

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

3. 模板服務

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

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

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

4. 消息分發服務

該服務將提供 API 來安排立即或指定時間的通知。可以是以下任何一種：

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

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

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

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

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

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

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

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

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

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

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

6. 通用出站處理程序

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

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

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

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

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

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

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

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

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

7. 通知適配器

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

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

8. 通道供應商

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

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

9. 用戶選擇服務

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

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

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

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

10. 用戶配置文件服務

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

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

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

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

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

11. 分析服務

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

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

以下是一些用例：

12. 通知跟蹤器

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

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

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

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

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

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

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

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

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

作者：Mark、尼恩

來源：技術自由圈

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/zIu4MC36I9JuF_tmFHdjIg

猜你喜歡