超越架構師！消息通知系統優化設計

5 收集聯繫信息流程為發送通知，需收集各種信息如移動設備令牌、email、phone和第三方通道信息。用於存儲聯繫信息的簡化的資料庫表模式。它是個帶有電子郵件、電話、設備令牌和外部通道的單個NoSQL DynamoDB表。Contacts table schema： device_tokens ...

5 收集聯繫信息流程

為發送通知，需收集各種信息如移動設備令牌、email、phone和第三方通道信息。

用於存儲聯繫信息的簡化的資料庫表模式。它是個帶有電子郵件、電話、設備令牌和外部通道的單個NoSQL DynamoDB表。Contacts table schema：

device_tokens 應以 JSON 格式存儲。示例：

[
 {
   "deviceToken": "[設備令牌UUID]",
   "platform": "apns"
 },
 {
   "deviceToken": "[設備令牌UUID]",
   "platform": "fcm"
 }
]

external_channels 欄位

[
  {
      "platform": "slack",
      "url": "[通道的唯一URL]",
      "status": true
  },
  {
      "platform": "another-service",
      "url": "...",
      "status": false
  }
]

用戶可擁有多個設備、第三方通道，表示可將推送通知發送到用戶的所有設備。

6 通知發送和接收流程

初始設計的通知系統：

圖從左到右：

外部生產者 1~N — 代表希望通過通知系統提供的API發送通知的不同服務。如結算服務發送簡訊提醒客戶付款到期，或者購物網站的交付消息到他們的客戶。

API網關 將為生產者提供API介面，並將請求正確地路由到通知服務（Lambda）。

通知服務 類似後端服務，功能如下：

執行基本驗證，以驗證電子郵件、電話號碼、設備令牌等。
查詢資料庫以獲取生成通知事件所需的數據。
將通知數據推送到事件匯流排以進行並行處理。

聯繫人資料庫 — 存儲有關用戶、聯繫信息、設置等數據的DynamoDB表。

EventBridge，AWS服務，將其用作事件匯流排。還需定義事件規則以正確將事件路由到隊列。

這是通知事件的示例。每個 detail-type 將針對一個通知類型。因此，SQS隊列根據屬性模式過濾事件。

{
  "id": "<required::uuid>",
  "source": "payment_request_event",
  "detail-type": ["payment_notification_sms"],
  "resources": ["payments"],
  "detail": {...}
  "time": "<required>",
  "region": "<required>",
  "account": "<required>"
}

消息隊列 — 它們用於消除組件之間的依賴關係。SQS隊列在需要發送大量通知時充當緩衝區。每種通知事件類型都分配到一個獨立的消息隊列，以便一個發送服務的中斷不會影響其他通知類型。

Worker — 從SQS隊列輪詢通知事件並將其發送到相應的服務的Lambda服務列表。

SNS或第三方服務 — 這些服務負責將通知傳遞給消費者。在與第三方服務集成時，我們需要關註可擴展性和高可用性。可擴展性的一個很好的例子是一個靈活的系統，可以輕鬆切換第三方服務的開/關。另一個重要考慮因素是第三方服務可能在某種程度上不可用，然後我們應該能夠切換到另一個服務，並儘量減小對業務的影響。

7 優化

在高級設計中，我們討論了通知系統的三個主要部分：不同類型的通知、收集聯繫信息流程和通知發送/接收流程。關鍵是：

事件和推送通知中的安全性
通知模板和設置
可靠性和彈性
重試機制
速率限制
監視隊列中的通知和事件跟蹤

事件和推送通知的安全性

在存儲敏感數據的情況下，我們應該啟用DynamoDB的數據保護，如靜態加密，並集成AWS Key Management Service（AWS KMS）以管理用於加密表的加密密鑰。並使用IAM角色對DynamoDB的訪問進行身份驗證。
在訪問資源方面實施最小許可權原則
通過使用SSL/TLS與AWS資源通信，啟用EventBridge的數據保護，以在傳輸中進行加密。建議使用TLS 1.3。
對於iOS和Android應用，appKey和appSecret用於保護推送通知API。只有經過身份驗證或經過驗證的客戶端才允許使用API發送推送通知。這些憑據應通過Secret Manager或Parameter Store存儲和加密。

通知模板和設置

我們應該為相同通知類型創建一個通知模板，其遵循相似的格式。它可以被重用，並避免從頭開始構建每個通知內容。
通知模板是預格式化的通知內容，通過自定義參數、跟蹤鏈接

等創建唯一的通知。我們可以將這些通知模板存儲在帶有定義首碼的S3桶中。

為了為用戶提供對通知設置的細粒度控制，我們可以將其存儲在單獨的通知設置表中。在向用戶發送任何通知之前，我們首先檢查用戶是否願意接收這種類型的通知。

可靠性和彈性

防止數據丟失 — 通知系統中最重要的非功能性要求之一是不能丟失數據。通知可能會延遲或重新排序，但不應該丟失。為了滿足此要求，通知系統將通知數據持久保存在另一個日誌表中，並實施重試機制。
接收一條通知確切地一次嗎？ — 不，不可以。根據第三方服務提供商的SLA，儘管通知大多數時候確切地傳遞一次，但分散式性質可能導致重覆的通知。我們可以減少重覆的發生，然後引入去重機制並小心處理故障。
這是一個簡化的邏輯：當通知事件首次到來時，我們通過檢查 eventId 來查看它是否以前傳遞過。如果之前成功傳遞，則將其丟棄。否則，我們將發送通知。
彈性基礎設施 — 我們應該考慮在多個可用區部署，您可以設計和操作可以在可用區之間自動故障轉移而不中斷的應用程式和資料庫。可用區比傳統的單一或多數據中心基礎設施更具高可用性、容錯性和可擴展性。

重試機制

當SNS/第三方服務無法發送通知時，通知將被添加到死信隊列進行重試。如果問題仍然存在，將向負責的開發人員發送警報。

速率限制

我們應該考慮禮貌地發送通知。為了避免向用戶發送過多通知，通過使用SQS並限制用戶在一段時間內可以接收的通知數量，我們可以提高通知系統的禮貌度。

監視隊列中的通知和事件跟蹤

我們應該使用AWS CloudWatch指標監視通知系統。要監視的關鍵指標是EventBirdge中的事件總數和排隊通知的總數。如果這兩個指標很大，那麼通知事件沒有被工作人員快速處理。這意味著我們應該擴展，需要更多的工作人員。
事件跟蹤 — 一些重要的自定義指標，如開放率、點擊率和參與度，對於理解客戶行為很重要。我們應該為事件分配狀態：已創建 → 待處理 → 已發送 → 已打開 → 已點擊或錯誤、已退訂。將事件狀態集成到通知系統中，我們可以追蹤通知事件。

更新的高級架構

帶有AWS的優化通知系統

8 結論

文章強調了通知在讓我們瞭解關鍵信息方面的不可或缺性。旨在闡明可擴展、高可用和可靠的通知系統的藍圖，該系統可適應各種通知類型，包括移動推送通知、簡訊、電子郵件和第三方應用通知。

為實現目標，我選擇基於事件的架構，利用EventBridge和SQS隊列解耦系統組件。

設計廣泛使用AWS服務，採用無伺服器框架，這種選擇不僅確保了效率，而且還將定價和運營成本降到了最低。

該設計遵循了十二要素應用的原則，將支持服務視為附加資源，將配置存儲在環境中，並將日誌視為事件流，其中還考慮了其他一些因素。

本文由博客一文多發平臺 OpenWrite 發佈！