一、業(yè)務(wù)背景

微服務(wù)的架構(gòu)體系中，會(huì)存在很多基礎(chǔ)服務(wù)，提供一些大部分服務(wù)都可能需要的能力，比如文件管理、MQ隊(duì)列、緩存機(jī)制、消息中心等等，這些服務(wù)需要提供各種可以復(fù)用的方法或者接口，以便其他業(yè)務(wù)服務(wù)可以快速調(diào)用；下面來看看消息通知的原理：

這里的消息不同于MQ隊(duì)列，是指業(yè)務(wù)側(cè)的通知機(jī)制，例如短信、郵件、系統(tǒng)消息等，在業(yè)務(wù)層面的需求很多，通常會(huì)封裝單獨(dú)的消息中心提供通知機(jī)制；

從流程上面看，消息通知是典型的生產(chǎn)-消費(fèi)模式，業(yè)務(wù)側(cè)不斷的生產(chǎn)消息，消息中心在接收之后進(jìn)行消費(fèi)，把通知推送到相應(yīng)的渠道中，很顯然這種邏輯具備很高的復(fù)用性。

二、消息通知

1、流程管理

消息通知的流程設(shè)計(jì)，在各個(gè)業(yè)務(wù)線中通過消息中心提供的接口方法，將不同場景下的消息內(nèi)容提交到消息中心，消息中心進(jìn)行統(tǒng)一維護(hù)管理，并根據(jù)消息的來源和去向，適配相應(yīng)的推送邏輯：

消息生產(chǎn)：涉及到的場景很多，比如活動(dòng)、營銷機(jī)制、系統(tǒng)通知、業(yè)務(wù)流轉(zhuǎn)、過期提醒等；

消息管理：對預(yù)發(fā)送消息的結(jié)構(gòu)和參數(shù)進(jìn)行校驗(yàn)，并創(chuàng)建消息推送的任務(wù)，維護(hù)任務(wù)級別的推送管理，跟蹤消息的狀態(tài)周期；

消息消費(fèi)：基于消息任務(wù)的結(jié)構(gòu)，構(gòu)建消息推送的主體內(nèi)容，并對接多個(gè)發(fā)送渠道，實(shí)現(xiàn)通知的高效觸達(dá)；

定時(shí)任務(wù)：消息可以直接即時(shí)推送，但如果是夜間定時(shí)任務(wù)觸發(fā)，則要考慮推送延遲問題，將消息放在指定時(shí)段投遞；

渠道對接：通常不同的渠道意味著不同的場景，例如監(jiān)控推送釘釘，活動(dòng)一般推送微信，賬戶變動(dòng)發(fā)郵件，營銷走短信，業(yè)務(wù)則應(yīng)用內(nèi)通知；

在整個(gè)流程中涉及到的模塊比較多，狀態(tài)的流轉(zhuǎn)也很復(fù)雜，但是通過消息中心進(jìn)行統(tǒng)一標(biāo)準(zhǔn)管理和流入流出的跟蹤，也可以提供清晰的生命周期監(jiān)控和維護(hù)；

2、流程時(shí)序

在整個(gè)消息通知鏈路中，在不同的流轉(zhuǎn)節(jié)點(diǎn)中，無不涉及狀態(tài)的變化（即from.to狀態(tài)），這樣可以構(gòu)成整個(gè)生命周期的視圖：

初始化：業(yè)務(wù)方構(gòu)建簡單的消息結(jié)構(gòu)，請求發(fā)送到消息中心后，初始化一個(gè)消息任務(wù)；

任務(wù)化：對消息發(fā)送請求進(jìn)行校驗(yàn)，并將消息轉(zhuǎn)換成一個(gè)標(biāo)準(zhǔn)的推送任務(wù)結(jié)構(gòu)；

推送中：根據(jù)任務(wù)推送的時(shí)間周期類型，將任務(wù)構(gòu)建成不同渠道的通知主體，從而進(jìn)行渠道消息推送；

已完成：根據(jù)消息在渠道推送的狀態(tài)回調(diào)，更新消息中心的任務(wù)完成狀態(tài)，或者失敗重試；

大部分的消息通知機(jī)制都可以容忍一定的延遲性，所以消息中心完全可以解耦各個(gè)流程，引入MQ隊(duì)列或者異步機(jī)制，業(yè)務(wù)方只需要將請求發(fā)送到消息中心，之后由消息中心統(tǒng)一調(diào)度和管理即可；

3、結(jié)構(gòu)設(shè)計(jì)

這里根據(jù)系統(tǒng)的實(shí)現(xiàn)過程和經(jīng)驗(yàn)，給出一個(gè)數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)參考，用來對業(yè)務(wù)場景做簡單的維度描述：

消息模板：定義通知的主體結(jié)構(gòu)，基于消息的參數(shù)模型，構(gòu)建推送的消息內(nèi)容；

消息任務(wù)：消息中心管理和維護(hù)的主體結(jié)構(gòu)，以任務(wù)的模式維護(hù)消息從生產(chǎn)到推送完成的整個(gè)狀態(tài)周期；

場景記錄：消息最終推送出去的內(nèi)容和場景分類，也可以簡單的理解為不同渠道的投遞記錄；

交互消息：強(qiáng)調(diào)消息在接收方是否觸達(dá)并且對消息產(chǎn)生了交互行為，例如會(huì)話，郵件回復(fù)，狀態(tài)關(guān)聯(lián)等；

三、實(shí)踐總結(jié)

最后還是站在技術(shù)實(shí)現(xiàn)的角度，總結(jié)一下消息通知機(jī)制中的一些關(guān)鍵問題：

生產(chǎn)消費(fèi)：消息生產(chǎn)之后寫入消息中心的存儲(chǔ)容器，之后進(jìn)行消費(fèi)流程的管理，是業(yè)務(wù)解耦的常用手段；

任務(wù)管理：以任務(wù)的模式進(jìn)行消息推送的調(diào)度，通過任務(wù)狀態(tài)的變化和控制，實(shí)現(xiàn)生命周期的管理；

狀態(tài)機(jī)：描述消息的流轉(zhuǎn)節(jié)點(diǎn)和狀態(tài)，在不同的事件中觸發(fā)不同的狀態(tài)切換和轉(zhuǎn)移，并在狀態(tài)變化后銜接各種業(yè)務(wù)動(dòng)作；

渠道對接：通常消息推送的渠道多是第三方平臺(tái)，所以在消息中心會(huì)接入諸多的渠道，例如微信、釘釘、短信等；

基礎(chǔ)封裝：作為分布式系統(tǒng)中的基礎(chǔ)功能，在封裝消息管理功能時(shí)，要考慮一定的復(fù)用性和流程的可視化呈現(xiàn)；

消息的本質(zhì)是信息的觸達(dá)和傳遞，但是過多的消息通知也容易讓用戶產(chǎn)生厭倦心態(tài)，所以消息內(nèi)容的簡潔明確，推送的間隔時(shí)段以及閱讀提醒，在產(chǎn)品具體的實(shí)現(xiàn)上需要極為用心，從而讓消息在業(yè)務(wù)體系中發(fā)揮更大的價(jià)值。

審核編輯：劉清