聊聊訊息中心的設計與實現邏輯

語言: CN / TW / HK

厭煩被訊息打擾,又怕突然間的安靜;

一、業務背景

微服務的架構體系中,會存在很多基礎服務,提供一些大部分服務都可能需要的能力,比如檔案管理、MQ佇列、快取機制、訊息中心等等,這些服務需要提供各種可以複用的方法或者介面,以便其他業務服務可以快速呼叫;下面來看看訊息通知的原理:

這裡的訊息不同於MQ佇列,是指業務側的通知機制,例如簡訊、郵件、系統訊息等,在業務層面的需求很多,通常會封裝單獨的訊息中心提供通知機制;

從流程上面看,訊息通知是典型的生產-消費模式,業務側不斷的生產訊息,訊息中心在接收之後進行消費,把通知推送到相應的渠道中,很顯然這種邏輯具備很高的複用性。

二、訊息通知

1、流程管理

訊息通知的流程設計,在各個業務線中通過訊息中心提供的介面方法,將不同場景下的訊息內容提交到訊息中心,訊息中心進行統一維護管理,並根據訊息的來源和去向,適配相應的推送邏輯:

  • 訊息生產:涉及到的場景很多,比如活動、營銷機制、系統通知、業務流轉、過期提醒等;
  • 訊息管理:對預傳送訊息的結構和引數進行校驗,並建立訊息推送的任務,維護任務級別的推送管理,跟蹤訊息的狀態週期;
  • 訊息消費:基於訊息任務的結構,構建訊息推送的主體內容,並對接多個傳送渠道,實現通知的高效觸達;
  • 定時任務:訊息可以直接即時推送,但如果是夜間定時任務觸發,則要考慮推送延遲問題,將訊息放在指定時段投遞;
  • 渠道對接:通常不同的渠道意味著不同的場景,例如監控推送釘釘,活動一般推送微信,賬戶變動發郵件,營銷走簡訊,業務則應用內通知;

在整個流程中涉及到的模組比較多,狀態的流轉也很複雜,但是通過訊息中心進行統一標準管理和流入流出的跟蹤,也可以提供清晰的生命週期監控和維護;

2、流程時序

在整個訊息通知鏈路中,在不同的流轉節點中,無不涉及狀態的變化(即from.to狀態),這樣可以構成整個生命週期的檢視:

  • 初始化:業務方構建簡單的訊息結構,請求傳送到訊息中心後,初始化一個訊息任務;
  • 任務化:對訊息傳送請求進行校驗,並將訊息轉換成一個標準的推送任務結構;
  • 推送中:根據任務推送的時間週期型別,將任務構建成不同渠道的通知主體,從而進行渠道訊息推送;
  • 已完成:根據訊息在渠道推送的狀態回撥,更新訊息中心的任務完成狀態,或者失敗重試;

大部分的訊息通知機制都可以容忍一定的延遲性,所以訊息中心完全可以解耦各個流程,引入MQ佇列或者非同步機制,業務方只需要將請求傳送到訊息中心,之後由訊息中心統一排程和管理即可;

3、結構設計

這裡根據系統的實現過程和經驗,給出一個數據結構的設計參考,用來對業務場景做簡單的維度描述:

  • 訊息模板:定義通知的主體結構,基於訊息的引數模型,構建推送的訊息內容;
  • 訊息任務:訊息中心管理和維護的主體結構,以任務的模式維護訊息從生產到推送完成的整個狀態週期;
  • 場景記錄:訊息最終推送出去的內容和場景分類,也可以簡單的理解為不同渠道的投遞記錄;
  • 互動訊息:強調訊息在接收方是否觸達並且對訊息產生了互動行為,例如會話,郵件回覆,狀態關聯等;

三、實踐總結

最後還是站在技術實現的角度,總結一下訊息通知機制中的一些關鍵問題:

  • 生產消費:訊息生產之後寫入訊息中心的儲存容器,之後進行消費流程的管理,是業務解耦的常用手段;
  • 任務管理:以任務的模式進行訊息推送的排程,通過任務狀態的變化和控制,實現生命週期的管理;
  • 狀態機:描述訊息的流轉節點和狀態,在不同的事件中觸發不同的狀態切換和轉移,並在狀態變化後銜接各種業務動作;
  • 渠道對接:通常訊息推送的渠道多是第三方平臺,所以在訊息中心會接入諸多的渠道,例如微信、釘釘、簡訊等;
  • 基礎封裝:作為分散式系統中的基礎功能,在封裝訊息管理功能時,要考慮一定的複用性和流程的視覺化呈現;

訊息的本質是資訊的觸達和傳遞,但是過多的訊息通知也容易讓使用者產生厭倦心態,所以訊息內容的簡潔明確,推送的間隔時段以及閱讀提醒,在產品具體的實現上需要極為用心,從而讓訊息在業務體系中發揮更大的價值。

四、參考原始碼

``` 程式設計文件: https://gitee.com/cicadasmile/butte-java-note

應用倉庫: https://gitee.com/cicadasmile/butte-flyer-parent ```