近年來，通知功能已經成為許多應用程式中突出的特性。構建一個能每天發送數百萬通知的可擴展系統絕非易事。這正是為什麼我覺得有必要記錄我在這方面踩坑之路。也叫用戶觸達系統。 完成這項任務要求對通知生態系統有深刻的理解，否則需求很容易變得模糊和不明確。 1 瞭解通知系統並確定設計範圍 通知是用於向用戶提供重 ...
近年來，通知功能已經成為許多應用程式中突出的特性。構建一個能每天發送數百萬通知的可擴展系統絕非易事。這正是為什麼我覺得有必要記錄我在這方面踩坑之路。也叫用戶觸達系統。
完成這項任務要求對通知生態系統有深刻的理解，否則需求很容易變得模糊和不明確。
1 瞭解通知系統並確定設計範圍
通知是用於向用戶提供重要信息的一種方式，如產品更新、提醒事件、優惠等。已成為應用功能清單中的重要組成部分。
通知不僅是移動推送通知。通常，根據接收者的特征
1 通知格式分類
- 移動推送通知
- 簡訊
- 電子郵件
- 網頁推送通知
- 第三方應用通知（類似 Slack、釘釘的應用）
2 功能需求
- 系統支持推送通知、簡訊、電子郵件和第三方應用通知。
- 準實時系統。希望用戶儘快收到通知。然而，若系統負載過高，輕微延遲也可接受
- 支持的設備：移動設備（iOS 和 Android）以及筆記本電腦/台式機
- 通知可以由客戶端應用程式事件觸發，也可以在伺服器端進行計劃
- 用戶可以選擇不再接收將來的通知
- 大致上，我希望每天發送1000萬條推送通知、500萬封電子郵件和100萬條簡訊
3 頂層設計
首先，我們需要找出一個支持各種通知類型的高級設計：簡訊、電子郵件、iOS推送通知、Android推送通知和Slack應用通知。
然後，系統應該以以下組件結構化：
- 不同通知類型的配置
- 收集聯繫信息流
- 通知發送和接收流
4 不同通知類型的高級設計與AWS
每種通知類型在高級層面上的工作原理。
4.1 簡訊
核心組件
- Producer — 生產者構建並向【SMS Service】發送通知請求。為構建簡訊的通知請求，生產者應提供數據：帶有國家代碼的用戶電話號碼，JSON字典負載下的簡訊主題/內容。也就是公司內各業務部門
- SMS Service，簡訊服務，用於處理自定義業務邏輯並觸發簡訊發送
- AWS SNS或第三方簡訊服務 — 這是AWS用於發送簡訊的服務，但為增加高可用性和韌性，我添加了第三方簡訊服務選項。預設，簡訊服務將調用AWS SNS，但若異常，可切換到其他簡訊服務
- SMS device，簡訊設備 — 接收簡訊的終端客戶端
