電商后臺(tái)系統(tǒng)中，消息系統(tǒng)是一個(gè)必不可少的功能模塊，其核心是幫助后臺(tái)人員及時(shí)了解業(yè)務(wù)消息，保障業(yè)務(wù)正常運(yùn)行。本文作者以此為出發(fā)點(diǎn)，詳細(xì)的概述了電商后臺(tái)中的系統(tǒng)消息的設(shè)計(jì)思路，與大家分享。

后臺(tái)系統(tǒng)是一個(gè)龐大的功能體系，及時(shí)的了解每個(gè)功能的使用狀況，保障業(yè)務(wù)正常進(jìn)行是每個(gè)系統(tǒng)的重點(diǎn)。通常系統(tǒng)內(nèi)會(huì)開(kāi)發(fā)大量的監(jiān)控功能(可視化的報(bào)表和非可視化的報(bào)表)來(lái)對(duì)這些業(yè)務(wù)進(jìn)行監(jiān)控，同時(shí)通知相應(yīng)的負(fù)責(zé)人以及時(shí)了解業(yè)務(wù)和服務(wù)器狀況。

常見(jiàn)的一些監(jiān)控功能，如賬號(hào)異常(賬號(hào)異地登錄、賬號(hào)多次密碼輸入錯(cuò)誤)、運(yùn)營(yíng)通知(活動(dòng)上架、活動(dòng)下架)、訂單異常（訂單堆積、派單堆積）、服務(wù)器異常（服務(wù)器宕機(jī)、CPU過(guò)載）、腳本異常（腳本卡死、進(jìn)程過(guò)多）等等。

今天帶大家來(lái)設(shè)計(jì)一個(gè)系統(tǒng)消息通知模塊，通過(guò)簡(jiǎn)單的設(shè)置，完成個(gè)性化的消息發(fā)送，并且減輕后期代碼的維護(hù)工作。首先我們來(lái)看看常見(jiàn)消息發(fā)送功能是如何實(shí)現(xiàn)的以及它們的優(yōu)缺點(diǎn)。

01 實(shí)現(xiàn)方式

1.1 直接觸發(fā)

直接觸發(fā)是將消息發(fā)送的邏輯和具體的業(yè)務(wù)代碼邏輯寫(xiě)在一起，當(dāng)滿足條件時(shí)，觸發(fā)消息發(fā)送功能。

• 優(yōu)點(diǎn)：開(kāi)發(fā)簡(jiǎn)單，如果功能封裝好后，代碼粘過(guò)來(lái)，十分鐘功能基本就能完成；消息發(fā)送比較及時(shí)，消息發(fā)送邏輯和業(yè)務(wù)邏輯在一起，滿足條件就會(huì)立即觸發(fā)。
• 缺點(diǎn)：后期如果需要添加、編輯或刪除接收人信息，就需要修改代碼，維護(hù)起來(lái)比較麻煩。熟悉代碼的人可能幾分鐘就搞定了，新人估計(jì)就得看半天代碼了。

我參與過(guò)多個(gè)系統(tǒng)的開(kāi)發(fā)，發(fā)現(xiàn)這么干的人還是挺多的?？偨Y(jié)一下應(yīng)該有以下幾個(gè)原因：

1. 寫(xiě)起來(lái)簡(jiǎn)單，因?yàn)榘l(fā)送邏輯一般都是封裝好的，只需要粘代碼，修改一下發(fā)送參數(shù)就完事
2. 一般后臺(tái)業(yè)務(wù)系統(tǒng)比較多，使用的編程語(yǔ)言比較多，各語(yǔ)言之間相互調(diào)用需要配置基礎(chǔ)服務(wù)，成本太大
3. 消息通知通常屬于系統(tǒng)基礎(chǔ)功能，產(chǎn)品經(jīng)理基本上不會(huì)去關(guān)注，也就不會(huì)去統(tǒng)一規(guī)劃這個(gè)功能，技術(shù)就自己隨意發(fā)揮了^_^

1.2 消息池

通過(guò)將所有消息先收集到一個(gè)消息池(如Mysql、Redis、Kafka等)中，然后再統(tǒng)一通過(guò)系統(tǒng)調(diào)度將消息發(fā)送給接收人。

• 優(yōu)點(diǎn)：功能模塊化，可以做到統(tǒng)一管理，代碼的調(diào)用可以更簡(jiǎn)潔，后期維護(hù)成本可以降到最低。
• 缺點(diǎn)：消息會(huì)有延遲，消息池它是一個(gè)異步發(fā)送方式，消息的生產(chǎn)和發(fā)送是兩個(gè)相互獨(dú)立的過(guò)程；需要開(kāi)發(fā)配置內(nèi)容頁(yè)面，開(kāi)發(fā)量稍微大一點(diǎn)，但是后期能減輕更多的維護(hù)成本，我認(rèn)為是非常值得的。

02 消息池模型

系統(tǒng)規(guī)劃的目的就是讓功能結(jié)構(gòu)清晰，后期維護(hù)更輕松，所以上面第一種的實(shí)現(xiàn)方式就不講了，主要討論一下消息池功能是如何實(shí)現(xiàn)的。先來(lái)看一下消息池功能的模型圖：

上面的模型主要分四層：

• 消息來(lái)源: 消息來(lái)源從開(kāi)發(fā)角度來(lái)說(shuō)，也稱為消息生產(chǎn)者，它主要是指消息的生成方式和位置。在龐大的后臺(tái)系統(tǒng)中，技術(shù)架構(gòu)會(huì)劃分出多個(gè)業(yè)務(wù)模塊，各自的的業(yè)務(wù)模塊都由不同的開(kāi)發(fā)人員維護(hù)，不同的業(yè)務(wù)組使用的語(yǔ)言也各不相同，所以在完成相同功能時(shí)，書(shū)寫(xiě)方式也是各不相同，這個(gè)是沒(méi)有辦法統(tǒng)一的。
• 消息池: 主要作用是存儲(chǔ)要發(fā)送內(nèi)容信息，如消息內(nèi)容，發(fā)送時(shí)間等。市面上常見(jiàn)的軟件有Mysql、Redis、Kafka、RabbitMQ等。所以對(duì)消息數(shù)據(jù)的存儲(chǔ)我們是可以做到統(tǒng)一的。
• 消息分發(fā)：主要作用是獲取待發(fā)送的消息列表，并根據(jù)已設(shè)置的接收人信息，找到具體的接收人并發(fā)送消息。技術(shù)上通常會(huì)啟動(dòng)相應(yīng)的任務(wù)程序持續(xù)的監(jiān)控消息池，當(dāng)消息池中有需要發(fā)送的數(shù)據(jù)，就執(zhí)行相應(yīng)業(yè)務(wù)邏輯。
• 接收人: 具體的消息接收人，接收人的接收方式有手機(jī)、郵箱或站內(nèi)信。

03 功能分析

設(shè)計(jì)具體功能前先來(lái)分析一下消息通知都涉及哪些功能。

3.1 消息類型

在系統(tǒng)運(yùn)行過(guò)程中，會(huì)涉及到許多業(yè)務(wù)功能的監(jiān)控，如訂單業(yè)務(wù)中，訂單支付是否有未成功、訂單分配是否有堆積的情況、派單功能是有堆積情況；再如運(yùn)營(yíng)業(yè)務(wù)中，商品運(yùn)營(yíng)活動(dòng)已經(jīng)設(shè)置上線時(shí)間，到點(diǎn)上線后需要及時(shí)通知運(yùn)營(yíng)人員上線是否成功，避免影響活動(dòng)效果。

為了能夠及時(shí)讓維護(hù)人員了解問(wèn)題，通常都對(duì)消息進(jìn)行歸類，如賬號(hào)異常、服務(wù)器警告、數(shù)據(jù)庫(kù)異常、運(yùn)營(yíng)通知、訂單異常、腳本異常等。

3.2 緊急程度

系統(tǒng)中對(duì)于不同類型的消息，根據(jù)重要程度會(huì)劃分出不同的級(jí)別。如系統(tǒng)每日?qǐng)?bào)表任務(wù)，由于數(shù)據(jù)量比較大，要求并不是很高，延遲一天通常都可以接受， 所以都是晚上3 ~ 5點(diǎn)之間由腳本自動(dòng)運(yùn)行導(dǎo)出后放在服務(wù)器上，第二天早上8點(diǎn)發(fā)系統(tǒng)通知，再由需求人自行導(dǎo)出就可以了，這類消息屬于一般程度；

但是對(duì)于服務(wù)器宕機(jī)這種情況，就必須立即通知負(fù)責(zé)人進(jìn)行處理，以免給企業(yè)帶來(lái)更多的損失，這類消息屬于緊急程度。

3.3 接收方式

消息接收方式通常就三種：站內(nèi)信、手機(jī)短信、郵箱。不同的接收方式作用有所不同：

• 站內(nèi)信：站內(nèi)信是系統(tǒng)內(nèi)部功能，研發(fā)人員可以隨意設(shè)置，消息內(nèi)容可以寫(xiě)的比較詳細(xì)；但是時(shí)效性比較差，取決于接收人什么時(shí)候登陸系統(tǒng)。
• 郵箱：消息內(nèi)容可以寫(xiě)的比較詳細(xì)，時(shí)效性也比較差，但是郵件確實(shí)必發(fā)的功能，因?yàn)榭梢宰鳛楸M職調(diào)查的憑證。
• 手機(jī)短信：短信功能一般都由第三放平臺(tái)提供，所以發(fā)送內(nèi)容長(zhǎng)度有所限制，內(nèi)容需要簡(jiǎn)潔，最大特點(diǎn)就是及時(shí)。

3.4 發(fā)送時(shí)間

對(duì)于系統(tǒng)中的消息，比較緊急的如訂單支付異常、數(shù)據(jù)庫(kù)宕機(jī)異常它們需要及時(shí)發(fā)送，還有一些不重要的，比如上面說(shuō)的各種任務(wù)報(bào)表，晚上3、4點(diǎn)生成好后，系統(tǒng)也不會(huì)發(fā)送消息，一般會(huì)設(shè)置好時(shí)間，等到早上8、9點(diǎn)才會(huì)開(kāi)始發(fā)送通知，還有一些任務(wù)需要每個(gè)幾小時(shí)就得發(fā)送一次。

3.5 唯一標(biāo)示

唯一標(biāo)示主要用于代碼開(kāi)發(fā)。在測(cè)試環(huán)境和正式生產(chǎn)環(huán)境由于測(cè)試導(dǎo)致數(shù)據(jù)庫(kù)ID不一致，所以開(kāi)發(fā)時(shí)沒(méi)有辦法通過(guò)對(duì)應(yīng)的ID調(diào)用消息，就需要設(shè)計(jì)一個(gè)唯一標(biāo)識(shí)符供開(kāi)發(fā)人員使用，一般標(biāo)示符命名根據(jù)具體的業(yè)務(wù)點(diǎn)來(lái)命名。

3.6 消息接收人

由于員工崗位的變動(dòng)，后臺(tái)需要設(shè)置相應(yīng)的接收人維護(hù)界面，可以自由的添加、刪除多個(gè)消息接收人。

04 原型設(shè)計(jì)

系統(tǒng)消息基本就上面這些功能，有需要的可以自己再擴(kuò)展。下面給出部分原型設(shè)計(jì)圖：

功能整理：

消息設(shè)置列表：

消息表單設(shè)置頁(yè)：

接收人列表：

05 使用方法

功能我們?cè)O(shè)計(jì)好了，如何在業(yè)務(wù)中使用，我簡(jiǎn)單說(shuō)一下：

1. 需要各業(yè)務(wù)平臺(tái)封裝消息池調(diào)用功能,并開(kāi)放一個(gè)接口，用來(lái)創(chuàng)建具體消息內(nèi)容
2. 在需要發(fā)送消息的業(yè)務(wù)里，調(diào)用上面的消息創(chuàng)建接口
3. 消息模塊啟動(dòng)任務(wù)(如crontab、監(jiān)聽(tīng))監(jiān)控消息池，如果有待發(fā)送消息，獲取并組織消息內(nèi)容，完成消息發(fā)送。

其中1、2兩步需要在各自業(yè)務(wù)平臺(tái)完成，第1步封裝成公共功能，只用開(kāi)發(fā)一次，第2步根據(jù)業(yè)務(wù)需要自行調(diào)用，就一行代碼，是不是很簡(jiǎn)潔。剩余所有的功能都集中在消息模塊，維護(hù)起來(lái)就比較方便了。

以上就是系統(tǒng)消息模塊的設(shè)計(jì)，歡迎下方留言交流！

作者：JackLiu；個(gè)人微信公眾號(hào): 揚(yáng)帆去遠(yuǎn)航（ID:Jackai_liu)

本文由 @Jack 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來(lái)自Unsplash，基于CC0協(xié)議。