電商後臺系統中，訊息系統是一個必不可少的功能模組，其核心是幫助後臺人員及時瞭解業務訊息，保障業務正常執行。本文作者以此為出發點，詳細的概述了電商後臺中的系統訊息的設計思路，與大家分享。
後臺系統是一個龐大的功能體系，及時的瞭解每個功能的使用狀況，保障業務正常進行是每個系統的重點。通常系統內會開發大量的監控功能(視覺化的報表和非視覺化的報表)來對這些業務進行監控，同時通知相應的負責人以及時瞭解業務和伺服器狀況。
常見的一些監控功能，如賬號異常(賬號異地登入、賬號多次密碼輸入錯誤)、運營通知(活動上架、活動下架)、訂單異常（訂單堆積、派單堆積）、伺服器異常（伺服器宕機、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協議。