- 前言
- 一、需求分析
- 1.1傳送通知
- 1.2撤回通知
- 1.3通知訊息數
- 1.4通知訊息列表
- 二、資料模型設計
- 2.1概念模型
- 2.2邏輯模型
- 三、關鍵流程設計
- 本篇小結
前言
訊息通知系統（notification-system）作為一個獨立的微服務，完整地負責了 App 端內所有訊息通知相關的後端功能實現。該系統既需要與文章系統、訂單系統、會員系統等相關聯，也需要和其它業務系統相關聯，是一個偏底層的通用服務系統。
App 端內的訊息通知型別常見有這幾項：評論通知、點贊通知、收藏通知、訂單通知、活動通知、個人中心相關通知等。該系統在可擴充性、高效能、較高可用性、資料一致性等方面有較高要求，最終目的是提升使用者粘性、加強 App 與使用者的互動、支撐核心業務的發展。
文章的（上）篇將從需求分析、資料模型設計、關鍵流程設計這 3 部分來說明，（下）篇將從技術選型、後端介面設計、關鍵邏輯實現這 3 部分來進行說明。
一、需求分析
主要從傳送通知、撤回通知、通知訊息數、通知訊息列表這 4 個子需求來展開。
1.1傳送通知
-
該操作一般由業務系統發出通知，業務系統包括了 App 端和管理後臺這兩種；
-
App 內的發起的通知一般由 App 使用者即會員（member）自己來操作，如：在評論區回覆評論，則其父評論的釋出者需要收到評論回覆通知；
-
管理後臺發出的通知一般是管理員將某種型別（文字or圖片等）的訊息傳送至 App 使用者，如：某個活動的運營者在後臺給 App 使用者傳送獲獎通知。
1.2撤回通知
-
這是一個可選操作，一般也是由業務系統來操作，具體會由管理後臺來完成，在 App 端一般較少有此類操作；
-
管理後臺可以針對已經傳送成功的通知進行單條撤回或者批次撤回，App 使用者的通知列表和未讀訊息數將會隨之變化。
1.3通知訊息數
-
在App ”我的“模組，新增訊息通知 icon，建議命名為”通知“；
-
當有新通知時顯示 x 條新訊息（紅色數字），顯示數字為該使用者所有未讀新訊息數之和；
-
有新增一條未讀訊息時數量+1，撤回一條未讀訊息數量-1；
-
未讀訊息數需要與訊息通知列表的未讀訊息數一致。
1.4通知訊息列表
-
點選 “通知” icon後進入訊息通知列表，根據通知型別分為不同的 tab 頁；
-
列表展示該使用者收到的所有訊息通知，並按通知時間倒序展示；
-
新訊息用紅點標識，檢視後退出的狀態標記為已讀，即紅點會消失；
-
點選具體的訊息，如果是連結，則支援跳轉到對應地址；如果是圖文，則支援檢視；如果是文章，則支援跳轉檢視。
二、資料模型設計
該系統的資料模型分為兩部分：資料庫與快取。其中對資料庫的概念模型（E-R圖）和邏輯模型（表設計）進行展開，對快取的資料結構在關鍵邏輯實現章節會進一步說明。
2.1概念模型
該系統目前設計為3張表，命名為：notification（通知記錄表）、notification_config（通知配置表）、external_sys（外部系統表）。
概念模型使用 E-R 圖來表示，其中 notification 與 notification_config 為1對多的關係，且下面為了便於描述，只給出關鍵欄位，其它欄位可以作為冗餘。
external_sys 為單獨記錄外部業務系統的資訊，用於業務系統呼叫通知系統介面時的身份校驗：
2.2邏輯模型
下面只給出關鍵欄位的表設計，其它欄位可以作為冗餘：
三、關鍵流程設計
下面是業務簡單拆分後的泳道圖，基於此圖再做關鍵流程的設計。
下面透過一個簡單的時序圖（不含撤回）來進行關鍵流程的拆解：
本篇小結
到這裡Java 網際網路專案中訊息通知系統的設計與實現（上）篇就暫告一段落了，剩下的部分包括技術選型、介面設計、關鍵邏輯設計會在下篇來進行說明。
系統設計的文章都是透過大量的實踐與驗證，最後才能下筆成文分享給大家的。如果文章有不足和錯誤，還請大家指正。或者你有其它想說的，也歡迎大家在評論區裡交流！