消息通知系統的架構設計
目標：
設計企業級系統架構，支持使用 API 集成的電子郵件、短信、聊天和其他公共社交應用程序：
• 電子郵件 • 短信 / 一次性密碼 • 推送通知（移動設備和 Web 瀏覽器）• 聊天 - Whatsapp/Telegram
這是一種通用的功能，適用於所有現代分佈式應用程序，無論使用任何編程語言和技術。
我試圖簡化這個設計概念，以滿足高可用性、高性能和分析服務的常見用例需求。這是通過微服務架構實現並在 Kubernetes 容器上部署，使其成爲完全雲原生的現代系統。讓我們開始吧！
功能要求：
• 發送通知 • 對通知進行優先級排序 • 根據客戶的保存偏好發送通知 • 支持單個 / 簡單的通知消息和批量通知消息 • 各種通知的分析用例 • 通知消息的報告
非功能性需求（NFR）：
• 高性能 • 高可用性（HA）• 低延遲 • 可擴展 / 可插拔的設計，以添加更多的客戶端、適配器和供應商 • 支持 Android/iOS 移動設備和桌面 / 筆記本電腦的 Web 瀏覽器 • 與所有通知模塊的 API 集成和與客戶端和服務提供商 / 供應商的外部集成 • 可在本地（VMware Tanzu）和 AWS、GCP 或 Azure 等公共雲服務上擴展負載
系統設計架構：
這些是解決方案設計的考慮因素和組件：
1. 通知客戶端：
這些客戶端將使用 API 調用請求單個和批量消息。這些客戶端將向簡單和批量通知服務發送通知消息。
• 批量通知客戶端：這些客戶端發送批量通知。• 簡單通知客戶端：這些客戶端發送單個通知。
2. 通知服務：
這些服務是入口服務，將通過暴露 REST API 與客戶端交互。它們負責通過消耗 "模板服務" 來構建通知消息。這些消息將使用 "驗證服務" 進行驗證。
• 簡單通知服務：該服務將暴露 API，以將客戶端與後端服務集成。它是主要的服務，用於處理簡單通知請求。• 批量通知服務：該服務將暴露 API，以將客戶端與後端服務集成。它是主要的服務，用於處理批量通知請求。
此服務還將管理通知消息。它將將發送的消息持久化到數據庫並維護活動日誌。可以使用這些服務的 API 重新發送同一條消息。它將提供添加 / 更新 / 刪除和查看舊消息和新消息的 API。它還將提供 Web 儀表板，該儀表板應具有篩選選項，以根據不同的條件（如日期範圍、優先級、模塊用戶、用戶組等）篩選消息。
3. 模板服務：
該服務管理所有可用的 OTP、短信、電子郵件、聊天和其他推送通知消息的模板。它還提供 REST API 來創建、更新、刪除和管理模板。它還將提供一個 UI 儀表板頁面，以便從 Web 控制檯檢查和管理消息模板。
4. 用戶選擇服務：
該服務將提供選擇目標用戶和各種應用程序模塊的服務。可能存在將批量消息發送到特定用戶組或不同應用程序模塊的用例。可能是 AD/IAM/eDirectory / 用戶數據庫 / 用戶組，根據客戶的偏好。在內部，它將使用 "用戶配置文件服務"API 來消耗和檢查客戶的通知偏好。
5. 用戶配置文件服務：
該服務將提供各種功能，包括管理用戶配置文件和其偏好設置。它還將提供取消訂閱通知以及通知接收頻率等功能。"通知服務" 將依賴於此服務。
6. 通用通知服務
• 定時服務：
該服務將提供 API 來安排立即或指定時間的通知。可以是以下任何一種：
• 秒 • 分鐘 • 每小時 • 每天 • 每週 • 每月 • 每年 • 自定義頻率等。
還可能有其他自動觸發的服務，基於預定時間進行消息觸發。
• 驗證服務：
該服務完全負責根據業務規則和期望的格式對通知消息進行驗證。批量消息應由授權的系統管理員批准。
• 優先級服務：
它還將根據高、中和低優先級對通知進行優先級排序。OTP 通知消息具有較高的優先級和有時間限制的過期時間，它們將始終以較高優先級發送。"通用出站處理程序" 將消耗消息並根據同樣的優先級從高、中和低三個不同的隊列中發送和處理。批量消息的另一個用例是在非工作時間使用低優先級發送。在交易過程中的應用程序通知可以發送到中優先級，如電子郵件
等。業務將根據通知的重要性決定優先級。
7. 事件優先級隊列（事件中心）：
它將提供事件中心服務，從通知服務中消耗高、中和低優先級的消息。它將根據業務優先級發送和接收消息。
它將具有以下三個主題，用於根據業務優先級消耗 / 發送消息：
• 高優先級 • 中優先級 • 低優先級
8. 通用出站處理程序：
該服務將通過輪詢事件優先級隊列來消耗事件中心中的通知消息，根據其優先級進行處理。高優先級將優先給予 "高" 隊列，依此類推。最後，它將通過事件中心將通知消息發送到特定的適配器。
該服務還將從用戶選擇服務中獲取目標用戶 / 應用程序。
9. 通知數據庫：
該數據庫將持久化所有通知消息，包括其發送時間、狀態等。它將具有一個數據庫集羣，其中一個領導者將用於執行所有寫操作，讀取將在讀取副本 / 跟隨者上進行。它應該是一個非關係型數據庫。
10. 出站事件中心：
它最終將消息傳輸到各種支持的適配器。這些適配器將基於不同的設備（桌面 / 移動）和通知類型（短信 / OTP / 電子郵件 / 聊天 / 推送通知）進行轉換。
11. 通知適配器：
這些適配器將從事件中心（Kafka）接收傳入消息並根據其所支持的格式發送給外部供應商。以下是一些適配器，根據需求可以添加更多：
•OTP 適配器服務 • 短信適配器服務 • 電子郵件適配器服務 • 應用內通知適配器服務 •WhatsApp 聊天通知適配器服務 •Telegram 通知適配器服務
12. 通知供應商：
這些是外部的 SAAS（雲上 / 本地）供應商，使用它們的基礎設施和技術提供實際的通知傳輸。它們可能是像 AWS SNS、MailChimp 等的付費企業服務。
• 短信供應商集成服務 • 電子郵件供應商集成服務 • 應用推送通知供應商集成服務 •WhatsApp 供應商集成服務 •Telegram 供應商集成服務
13. 通知分析服務
該服務將執行所有的分析工作，並識別通知使用情況、趨勢以及進行報告。它將從分析數據庫（Cassandra）和通知數據庫中提取所有最終的通知消息，用於分析和報告目的。
以下是一些用例：
• 每天 / 每秒的總通知數。• 哪個通知系統使用最頻繁。• 消息的平均大小和頻率。• 基於優先級過濾消息等等...
14. 通知跟蹤器
該服務將持續讀取事件中心隊列並跟蹤所有發送的通知。它捕獲通知的元數據，如傳輸時間、傳送狀態、通信渠道、消息類型等。
15. Cassandra 數據庫集羣
該數據庫集羣將持久化所有通知，用於分析和報告。它基於 “寫入更多，讀取更少” 的概念。
它將提供良好的性能和低延遲，適應大量的通知，因爲它內部管理大量的寫操作，並與其他數據庫節點同步，並保留高可用性和可靠性的冗餘數據 / 消息。在任何節點崩潰的情況下，消息將始終可用。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/5Vq_BQ2Ml2snUm9PgKc64w