消息通知的流程設計，在各個業務線中通過消息中心提供的接口方法，将不同場景下的消息内容送出到消息中心，消息中心進行統一維護管理，并根據消息的來源和去向，适配相應的推送邏輯。
厭煩被消息打擾，又怕突然間的安靜；
一、業務背景
微服務的架構體系中，會存在很多基礎服務，提供一些大部分服務都可能需要的能力，比如檔案管理、MQ隊列、緩存機制、消息中心等等，這些服務需要提供各種可以複用的方法或者接口，以便其他業務服務可以快速調用；下面來看看消息通知的原理：
這裡的消息不同于MQ隊列，是指業務側的通知機制，例如短信、郵件、系統消息等，在業務層面的需求很多，通常會封裝單獨的消息中心提供通知機制；
從流程上面看，消息通知是典型的生産-消費模式，業務側不斷的生産消息，消息中心在接收之後進行消費，把通知推送到相應的管道中，很顯然這種邏輯具備很高的複用性。
二、消息通知
1、流程管理
消息通知的流程設計，在各個業務線中通過消息中心提供的接口方法，将不同場景下的消息内容送出到消息中心，消息中心進行統一維護管理，并根據消息的來源和去向，适配相應的推送邏輯：
- 消息生産：涉及到的場景很多，比如活動、營銷機制、系統通知、業務流轉、過期提醒等；
- 消息管理：對預發送消息的結構和參數進行校驗，并建立消息推送的任務，維護任務級别的推送管理，跟蹤消息的狀态周期；
- 消息消費：基于消息任務的結構，建構消息推送的主體内容，并對接多個發送管道，實作通知的高效觸達；
- 定時任務：消息可以直接即時推送，但如果是夜間定時任務觸發，則要考慮推送延遲問題，将消息放在指定時段投遞；
- 管道對接：通常不同的管道意味着不同的場景，例如監控推送釘釘，活動一般推送微信，賬戶變動發郵件，營銷走短信，業務則應用内通知；
在整個流程中涉及到的子產品比較多，狀态的流轉也很複雜，但是通過消息中心進行統一标準管理和流入流出的跟蹤，也可以提供清晰的生命周期監控和維護；
2、流程時序
在整個消息通知鍊路中，在不同的流轉節點中，無不涉及狀态的變化（即from.to狀态），這樣可以構成整個生命周期的視圖：
- 初始化：業務方建構簡單的消息結構，請求發送到消息中心後，初始化一個消息任務；
- 任務化：對消息發送請求進行校驗，并将消息轉換成一個标準的推送任務結構；
- 推送中：根據任務推送的時間周期類型，将任務建構成不同管道的通知主體，進而進行管道消息推送；
- 已完成：根據消息在管道推送的狀态回調，更新消息中心的任務完成狀态，或者失敗重試；
大部分的消息通知機制都可以容忍一定的延遲性，是以消息中心完全可以解耦各個流程，引入MQ隊列或者異步機制，業務方隻需要将請求發送到消息中心，之後由消息中心統一排程和管理即可；
3、結構設計
這裡根據系統的實作過程和經驗，給出一個資料結構的設計參考，用來對業務場景做簡單的次元描述：
- 消息模闆：定義通知的主體結構，基于消息的參數模型，建構推送的消息内容；
- 消息任務：消息中心管理和維護的主體結構，以任務的模式維護消息從生産到推送完成的整個狀态周期；
- 場景記錄：消息最終推送出去的内容和場景分類，也可以簡單的了解為不同管道的投遞記錄；
- 互動消息：強調消息在接收方是否觸達并且對消息産生了互動行為，例如會話，郵件回複，狀态關聯等；
三、實踐總結
最後還是站在技術實作的角度，總結一下消息通知機制中的一些關鍵問題：
- 生産消費：消息生産之後寫入消息中心的存儲容器，之後進行消費流程的管理，是業務解耦的常用手段；
- 任務管理：以任務的模式進行消息推送的排程，通過任務狀态的變化和控制，實作生命周期的管理；
- 狀态機：描述消息的流轉節點和狀态，在不同的事件中觸發不同的狀态切換和轉移，并在狀态變化後銜接各種業務動作；
- 管道對接：通常消息推送的管道多是第三方平台，是以在消息中心會接入諸多的管道，例如微信、釘釘、短信等；
- 基礎封裝：作為分布式系統中的基礎功能，在封裝消息管理功能時，要考慮一定的複用性和流程的可視化呈現；
消息的本質是資訊的觸達和傳遞，但是過多的消息通知也容易讓使用者産生厭倦心态，是以消息内容的簡潔明确，推送的間隔時段以及閱讀提醒，在産品具體的實作上需要極為用心，進而讓消息在業務體系中發揮更大的價值。
四、參考源碼
程式設計文檔：
https://gitee.com/cicadasmile/butte-java-note
應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent
https://gitee.com/cicadasmile/butte-java-note