網站消息通知設計

通知系統是一個成熟的 web 網站或者 app 最基本的功能，好比微博、知乎、掘金等。固然今天本文要討論的不是這種大網站、大流量的通知系統，而是通常用戶量的網站或者應用。

通知系統的組成

一個通知系統主要由：通知來源、通知控制、通知方式、通知模板和通知的目標五個部分組成。 後面詳細介紹各個組成的做用。組成結構以下圖所示：

通知來源

通知來源是指觸發本次通知事件的源頭，通常包括如下三種狀況：

1. 用戶事件觸發：當其餘用戶對某個對象執行了評論、@、點贊、留言等動做，都須要對對象擁有者進行通知。這是最多見的須要通知的場景。
2. 知足系統的規則後自動觸發：好比被系統封號、等級提高、得到勳章時，理論上都應該對用戶進行通知。
3. 管理員觸發：管理員主動向全網或者某個用戶發送通知，好比發送公告等。

通知控制

通知控制用來進行權限控制、黑白名單過濾、用戶接收消息頻率控制、內容審查等。總之控制和過濾相關的都放在這裏。

通知模板

通知模板用來與數據模型結合並最終展現給用戶，相似 MVC 模式中的 V，能夠是純文本也能夠是 Velocity 之類的模板。引入通知模板主要是爲了知足如下三點：

1. 不一樣通知方式通知的展現方式能夠不一樣；
2. 通知的展現與通知的模型數據分離；
3. 通知模板可配。

通知方式

常見的有站內信、郵件、短信、工做通知(釘釘、企業微信)等。其中像郵件、短信和工做通知都是基於第三方應用的，用的時候頂多在他們提供的接口上作一層封裝就能夠了，因此沒什麼能夠講的。而站內信每每則須要網站或者應用本身設計和開發，因此不少網上介紹通知系統都只是介紹站內信的設計。

通知系統的分層

本文設計的通知系統流程圖以下，主要分爲業務層、數據模型層、控制層、分發層、視圖層和發送層。分層能夠下降各個模塊之間的耦合，每一層只作本身該作的事。

業務層

該層與業務相關，屬於通知系統中的通知來源部分。是調用通知系統服務的調用方，放在這裏爲了後面講解業務與通知系統的解耦。

數據模型層

相信不少寫 web 後臺的程序員對 MVC 模式很熟悉，這一層至關於 MVC 模式中的 M 層，主要負責收集模型數據的。該層理論上劃分爲通知系統的通知來源。該層的數據模型與上層業務緊密關聯，不一樣的業務場景須要不一樣的通知數據。

控制/過濾層

即通知控制，用來進行權限控制、黑白名單過濾、用戶接收消息頻率控制、內容審查等。

分發層

不一樣的業務每每須要不一樣的方式發送通知消息，好比事件通知要進行站內信通知、而被封號每每會選擇郵件或者短信通知。消息到達分發層後，根據業務的不一樣選擇不一樣的發送策略。若是須要將發送的消息記錄進行存儲也能夠放在這層。

視圖層

本層與數據模型層關係很大，數據到這一層後會與模板結合組成要發送的內容。

發送層

主要是調用短信、郵件、工做通知和站內信等接口將消息發送出去。咱們將在第三部分講解該層中的站內信設計。

以上分層建議採用框架的方式將全部流程編排好，每層都採用接口或者抽象類的方式調用。每層都有一些基類和固定接口，一旦有新的業務來只須要繼承這些基類並實現相應接口就能夠了。

結尾

本文通知系統設計就講到這裏，雖然簡單但也是經驗之談吧。筆者在設計這塊的時候也是慢慢演化過來的。一開始業務少、功能簡單，直接將全部代碼壘在一塊兒。後期增長功能改動很是之大，幾乎等於重構。採用這種設計後，若是須要新增業務，只須要新增一些類，流程就能夠自動 run 起來。