如何從0-1重構建消息系統:服務端

3 評論 8436 瀏覽 103 收藏 15 分鐘

編輯導語:當你需要對消息系統進行重構時,如何做好服務端的搭建設計?首先,你需要明確有哪些模塊,區別于客戶端,服務端的面向對象、功能設計等層面也有所不同。本篇文章里,作者梳理了從0到1重構消息系統服務端的流程,一起來看一下。

在龐大的后臺系統中,怎么搭建消息系統的服務端,本文將結合上一篇《如何從0-1重構建消息系統:客戶端》簡單整理此次重建的流程及功能設計,希望對大家有所幫助。

在設計和搭建服務端產品時,與客戶端產品來說是具有一定的差異性,首先產品在目標用戶上有明確的區分,客戶端主要是面對普通用戶,而服務端主要是公司內部人員使用;產品的功能設計上,客戶端的交互設計和視覺體驗相對于要求比較高,必須滿足品牌傳播等很多要求,而客戶端要求功能流程清晰,交互簡單明確,保障前端業務正常開展,數據流程閉環等要求。

一、重構背景

此次主要消息后臺的重構,主要需要對APP的應用級的消息渠道:push推送、站內信的重構進行業務支撐,明確優化方向后,我們通業務側的調研得出我們要重構的目標:

  1. 消息管理-相關權限人可在消息系統后臺創建系統自動觸發消息和手動推送消息,并且這些消息可以推送給APP客戶端、公眾號的渠道用戶;
  2. 整合現有公司業務的推送消息類型、系統消息推送機制、消息模版(系統消息模版和手推消息模版)、消息推送,并且消息管理相關權限人可以進行管理操作;
  3. 可以滿足各種場景下的消息推送需求。

二、消息系統規劃

消息系統的重構后,服務端主要由四大模塊構成:

  1. 消息類型管理;
  2. 消息模版管理;
  3. 系統觸發管理;
  4. 手動推送管理。

設計具體方案前,我們先來分析一下消息系統服務端的各模塊的功能。

1. 消息類型管理

客戶端進行重構的重要原因之一,由于業務的增加,造成消息類型不明確,消息等級錯亂,所以我們首先對于消息中心進行了消息類型的劃分,并采用了消息分類合并方式;所以在設計后臺功能的時候,我們設計了消息類型管理模塊了,主要作用:

  • 為客戶端的消息類型字段提供數據支撐;
  • 隨著業務的擴展和合并,運營可以在后臺擴充消息類型,并且可以實現前后端類型的分離,方便管理;
  • 可以很好地解決業務的擴展和合并的情況,導致前端技術需要重新對前端消息類型代碼再次編寫。

如策略部同事需要新增一個新業務,給用戶提供市場上宏觀經濟信息,則需要添加二級消息「市場解讀」,如果后臺沒有可配置的后臺,則需要前端或者客戶端技術在前端編寫代碼,進行發版解決。

2. 消息模版管理

大家可以理解為一個預編的消息池,里面保存了系統觸發消息模版和手動推送消息模版,主要作用:

  • 完整地記錄了系統觸發的消息的類型、內容等,業務同學可以在此模塊中找到在系統中運行的任何一條系統觸發消息,不需要技術同學再去扒代碼找一條系統消息;
  • 方便運營的同學在編寫手推或者自動觸發消息時,省去尋找相似類似業務的消息模版,大大節省了業務方同學在編寫消息時的效率。

需要注意系統觸發消息模版如果已經在使用,則不可以隨意編輯,以免造成消息發送事故。

3. 系統觸發管理

先解釋一下此系統中什么叫做系統觸發消息功能,將消息發送的邏輯寫在業務流程邏輯代碼中,當滿足條件時,觸發消息發送功能。

此模塊主要進行系統觸發的關鍵機制的查看,及時地記錄每個部門或業務消息觸發機制,可以避免隨著部門和人員的業務更迭,造成觸發機制的信息無法自知的想象,方便每個部門對系統觸發消息及消息渠道的查看、記錄。

如運營部門新增了直播業務,我們需要對整個業務流程進行分析,需要系統自動觸發的消息機制有哪些,并且推動哪種渠道,及推動的消息類型有哪些。

1)當用戶點擊已預約以后,則系統會自動發送給用戶一條預約成功的「站內信」,則后臺記錄觸發機制為「用戶點擊預約直播按鈕后」,發送的消息類型「站內信」,消息名稱為「預約成功」提醒。

2)當開播前15分鐘,系統會自動給成功預約本場直播的用戶發送直播開始的「站內信」、「Push消息」,則后臺記錄的觸發機制為「直播開始前15分鐘,給所有預約成功用戶發送觀看開播提醒」,消息名稱為「開播提醒」。

這就是一個完整的觸發消息機制的記錄。

需要注意的是,因為系統觸發機制都是由技術編寫在后臺代碼中,所以我們新的業務需要增加系統自動觸發機制的時候,需要同步后臺技術,需要技術進行代碼實現,才可以運行觸發條件。

4. 手動推送管理

此模塊為手動推送消息的主要功能模塊,運營和各業務部門的同學可以在此模塊完成消息內容的編寫或選取,消息類型的選擇、發送渠道的配置、發送時間的選擇、消息接受人的選擇等主要推送機制的設置。

三、原型規劃

通過結合對客戶端、服務端功能的分析,我們開始對消息系統服務端主要模塊的功能進行產品方案設計,以下筆者會一一講解主要的功能構成。

功能結構圖

1. 消息類型管理設計

消息類型列表

字段及功能說明

消息類型:主要對系統中所有消息進行分類整理,如果業務類型層級比較復雜,則可以在某一個業務類型一級消息下,再設計二級分類;并且可以對消息類型進行編輯,如更改消息類型名稱、增加或刪除消息類型。

需要注意的是我們在更改消息類型名稱后,需要對以往原消息類型的歷史消息進行繼承,對已經有歷史消息的消息類型不能進行刪除。

2. 消息模版管理設計

手動推送消息模版列表

字段及功能說明

此模塊分為系統觸發消息模版管理和手動推送消息模版管理,系統觸發模版中含有代碼中包含的參數,這個是系統觸發模版和手動推送模版需要做成兩個管理版塊的原因。

以手動推送消息模版列表為主要列舉對象:

  • 消息標題:顯示消息的主標題。
  • 消息摘要:對于消息內容的概括,根據客戶端和渠道內容的要求,后臺做字符、樣式、位置等限制。
  • 消息內容:根據客戶端的要求,后臺做字符、樣式、位置等限制,如果渠道內容類型比較多,則可以不顯示。
  • 消息類型:消息在客戶端顯示歸屬的消息類型。
  • 渠道內容推送:顯示此條消息包含的消息渠道內容。
  • 編輯時間:顯示最后編輯消息時間。
  • 消息編輯人:顯示最后編輯人姓名。

需要注意在操作系統觸發消息模版的時候,如果此條系統觸發模版消息已經和系統觸發機制關聯,則無法進行刪除和編輯。

3. 系統觸發管理設計

系統觸發機制列表

字段及功能說明

  • 系統觸發機制:將消息發送的邏輯寫在業務流程邏輯代碼中,當滿足條件時,觸發消息發送,此時的消息發送邏輯我們稱其為系統觸發機制,此處把代碼中的觸發機制反顯出來;
  • 系統觸發消息模版:系統消息觸發機制對應的消息模版,消息機制可以更換消息模版。

在禁用消息機制的時候,需要提醒業務方是否取消關聯的系統消息模版。

4. 手動推送管理

手動推送消息列表

字段及功能說明

  • 消息標題、消息摘要、消息內容、消息類型、渠道內容類型和消息模版管理一致,此處省略;
  • 推送用戶群體:此消息推送的用戶類型;
  • 用戶數:推送用戶的數量;
  • 推送渠道:消息推送的具體端口及渠道;
  • 推送人:記錄最后發送此消息的人員;
  • 推送時間:消息發送的時間記錄;
  • 推送狀態:分為未發送、已測試發送、已發送三種狀態;當消息未發送時,需要對消息進行測試發送后,發送按鈕才可以被激活進行正式發送;當消息測試發送后,則可以進行正式發送;當消息發送后,可以對消息進行引用,再次使用此條消息進行發送。

推送機制

在消息模版管理的時候,我們已經簡述了消息的主體部分編輯關鍵信息,在手動推送消息時,我們還需要對主體消息配置推送機制:

  • 推送渠道:設計時需要考慮業務所覆蓋的所有渠道,在此系統中則是需要針對此條消息的所屬渠道內容進行配置;
  • 推送方式:實時推送,點擊推送按鈕則可以發送;定時推送,可以選擇具體的日期和時間發送消息;
  • 推送用戶:全體用戶;自定義,主要針對業務方做定制化開發或手動上傳用戶信息;
  • 消息發送參數:針對系統發送能力進行合理優化分配發送的機制;
  • 測試用戶:業務方對于新消息的線上測試檢查是不可缺少的環節,需要配置的測試用戶可以在此設置。

四、寫在最后的話

本文作為「如何從0-1重構建消息系統:客戶端」的姊妹篇,簡單記錄筆者在規劃消息系統服務端時的一個思路。

服務端除了需要支持現在運行的客戶端功能數據展示和數據流轉,還需要對未來客戶端業務功能擴容做研判,這樣才能更好地支持客戶端的用戶體驗和數據流轉,提高開發效率。

以上就是筆者0-1重構消息系統的全部記錄,希望對觀看此文的諸位有所幫助和借鑒,如有不同意見,歡迎下方留言交流!

 

本文由@大大大大大浪 原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 你好,想請問下系統觸發消息機制如何設置,就是系統觸發機制的詳情

    來自湖南 回復
  2. 學校

    回復
    1. 同學你好!多多交流

      來自北京 回復