電商後台系統中，消息系統是一個必不可少的功能模塊，其核心是幫助後台人員及時瞭解業務消息，保障業務正常運行。本文作者以此為出發點，詳細的概述了電商後台中的系統消息的設計思路，與大家分享。
後台系統是一個龐大的功能體系，及時的瞭解每個功能的使用狀況，保障業務正常進行是每個系統的重點。通常系統內會開發大量的監控功能(可視化的報表和非可視化的報表)來對這些業務進行監控，同時通知相應的負責人以及時瞭解業務和服務器狀況。
常見的一些監控功能，如賬號異常(賬號異地登錄、賬號多次密碼輸入錯誤)、運營通知(活動上架、活動下架)、訂單異常（訂單堆積、派單堆積）、服務器異常（服務器宕機、CPU過載）、腳本異常（腳本卡死、進程過多）等等。
今天帶大家來設計一個系統消息通知模塊，通過簡單的設置，完成個性化的消息發送，並且減輕後期代碼的維護工作。首先我們來看看常見消息發送功能是如何實現的以及它們的優缺點。
01 實現方式1.1 直接觸發直接觸發是將消息發送的邏輯和具體的業務代碼邏輯寫在一起，當滿足條件時，觸發消息發送功能。
- 優點：開發簡單，如果功能封裝好後，代碼粘過來，十分鐘功能基本就能完成；消息發送比較及時，消息發送邏輯和業務邏輯在一起，滿足條件就會立即觸發。
- 缺點：後期如果需要添加、編輯或刪除接收人信息，就需要修改代碼，維護起來比較麻煩。熟悉代碼的人可能幾分鐘就搞定了，新人估計就得看半天代碼了。
我參與過多個系統的開發，發現這麼幹的人還是挺多的。總結一下應該有以下幾個原因：
- 寫起來簡單，因為發送邏輯一般都是封裝好的，只需要粘代碼，修改一下發送參數就完事
- 一般後台業務系統比較多，使用的編程語言比較多，各語言之間相互調用需要配置基礎服務，成本太大
- 消息通知通常屬於系統基礎功能，產品經理基本上不會去關注，也就不會去統一規劃這個功能，技術就自己隨意發揮了^_^
通過將所有消息先收集到一個消息池(如Mysql、Redis、Kafka等)中，然後再統一通過系統調度將消息發送給接收人。
- 優點：功能模塊化，可以做到統一管理，代碼的調用可以更簡潔，後期維護成本可以降到最低。
- 缺點：消息會有延遲，消息池它是一個異步發送方式，消息的生產和發送是兩個相互獨立的過程；需要開發配置內容頁面，開發量稍微大一點，但是後期能減輕更多的維護成本，我認為是非常值得的。
系統規劃的目的就是讓功能結構清晰，後期維護更輕鬆，所以上面第一種的實現方式就不講了，主要討論一下消息池功能是如何實現的。先來看一下消息池功能的模型圖：
上面的模型主要分四層：
- 消息來源: 消息來源從開發角度來説，也稱為消息生產者，它主要是指消息的生成方式和位置。在龐大的後台系統中，技術架構會劃分出多個業務模塊，各自的的業務模塊都由不同的開發人員維護，不同的業務組使用的語言也各不相同，所以在完成相同功能時，書寫方式也是各不相同，這個是沒有辦法統一的。
- 消息池: 主要作用是存儲要發送內容信息，如消息內容，發送時間等。市面上常見的軟件有Mysql、Redis、Kafka、RabbitMQ等。所以對消息數據的存儲我們是可以做到統一的。
- 消息分發：主要作用是獲取待發送的消息列表，並根據已設置的接收人信息，找到具體的接收人併發送消息。技術上通常會啓動相應的任務程序持續的監控消息池，當消息池中有需要發送的數據，就執行相應業務邏輯。
- 接收人: 具體的消息接收人，接收人的接收方式有手機、郵箱或站內信。
設計具體功能前先來分析一下消息通知都涉及哪些功能。
3.1 消息類型在系統運行過程中，會涉及到許多業務功能的監控，如訂單業務中，訂單支付是否有未成功、訂單分配是否有堆積的情況、派單功能是有堆積情況；再如運營業務中，商品運營活動已經設置上線時間，到點上線後需要及時通知運營人員上線是否成功，避免影響活動效果。
為了能夠及時讓維護人員瞭解問題，通常都對消息進行歸類，如賬號異常、服務器警告、數據庫異常、運營通知、訂單異常、腳本異常等。
3.2 緊急程度系統中對於不同類型的消息，根據重要程度會劃分出不同的級別。如系統每日報表任務，由於數據量比較大，要求並不是很高，延遲一天通常都可以接受， 所以都是晚上3 ~ 5點之間由腳本自動運行導出後放在服務器上，第二天早上8點發系統通知，再由需求人自行導出就可以了，這類消息屬於一般程度；
但是對於服務器宕機這種情況，就必須立即通知負責人進行處理，以免給企業帶來更多的損失，這類消息屬於緊急程度。
3.3 接收方式消息接收方式通常就三種：站內信、手機短信、郵箱。不同的接收方式作用有所不同：
- 站內信：站內信是系統內部功能，研發人員可以隨意設置，消息內容可以寫的比較詳細；但是時效性比較差，取決於接收人什麼時候登陸系統。
- 郵箱：消息內容可以寫的比較詳細，時效性也比較差，但是郵件確實必發的功能，因為可以作為盡職調查的憑證。
- 手機短信：短信功能一般都由第三放平台提供，所以發送內容長度有所限制，內容需要簡潔，最大特點就是及時。
對於系統中的消息，比較緊急的如訂單支付異常、數據庫宕機異常它們需要及時發送，還有一些不重要的，比如上面説的各種任務報表，晚上3、4點生成好後，系統也不會發送消息，一般會設置好時間，等到早上8、9點才會開始發送通知，還有一些任務需要每個幾小時就得發送一次。
3.5 唯一標示唯一標示主要用於代碼開發。在測試環境和正式生產環境由於測試導致數據庫ID不一致，所以開發時沒有辦法通過對應的ID調用消息，就需要設計一個唯一標識符供開發人員使用，一般標示符命名根據具體的業務點來命名。
3.6 消息接收人由於員工崗位的變動，後台需要設置相應的接收人維護界面，可以自由的添加、刪除多個消息接收人。
04 原型設計系統消息基本就上面這些功能，有需要的可以自己再擴展。下面給出部分原型設計圖：
功能整理：
消息設置列表：
消息表單設置頁：
接收人列表：
功能我們設計好了，如何在業務中使用，我簡單説一下：
- 需要各業務平台封裝消息池調用功能,並開放一個接口，用來創建具體消息內容
- 在需要發送消息的業務裏，調用上面的消息創建接口
- 消息模塊啓動任務(如crontab、監聽)監控消息池，如果有待發送消息，獲取並組織消息內容，完成消息發送。
其中1、2兩步需要在各自業務平台完成，第1步封裝成公共功能，只用開發一次，第2步根據業務需要自行調用，就一行代碼，是不是很簡潔。剩餘所有的功能都集中在消息模塊，維護起來就比較方便了。
以上就是系統消息模塊的設計，歡迎下方留言交流！
作者：JackLiu；個人微信公眾號: 揚帆去遠航（ID:Jackai_liu)
本文由 @Jack 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。