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