1、什么是消息中心

消息中心是一個集中管理、分發(fā)通知和提醒的平臺，可以讓用戶或系統(tǒng)消息更方便、快捷的觸達(dá)給指定用戶或者系統(tǒng)。并且可以幫助用戶或系統(tǒng)更好地管理消息的生命周期，屏蔽不同消息渠道差異與技術(shù)差異，從而提升效率與體驗，降低維護(hù)成本。

2、為什么要搭建消息中心

• 公司目前處于快速發(fā)展階段，業(yè)務(wù)線正在快速拓展，不同的產(chǎn)品線也正在逐步增加，與此同時，不同的產(chǎn)品線均需要通過消息模塊來觸達(dá)內(nèi)部或外部用戶，基本上每一個系統(tǒng)都需要有自己的消息通知體系。但在由于不同業(yè)務(wù)開發(fā)團(tuán)隊相互獨立，為了避免協(xié)調(diào)溝通這種不可預(yù)估的成本，各業(yè)務(wù)開發(fā)團(tuán)隊都采取了“自主”開發(fā)的方式解決此類問題。這樣造成的結(jié)果就是：各業(yè)務(wù)團(tuán)隊不斷地重復(fù)發(fā)明輪子，而且這輪子不可復(fù)用，造成了資源和時間成本的大量浪費。更為關(guān)鍵的是：功能無法復(fù)用，持續(xù)迭代也無法沉淀。當(dāng)面對一個新業(yè)務(wù)時，即便公司已有成熟的功能，但仍然無法有效地縮短業(yè)務(wù)創(chuàng)新和推進(jìn)的時間。
• 各業(yè)務(wù)系統(tǒng)均以功能的概念在設(shè)計，業(yè)務(wù)資源和開發(fā)資源會存在大量的重復(fù)消耗，在維護(hù)方面也存在諸多問題，并且不利于統(tǒng)一管理，并且也沒有相關(guān)消息觸達(dá)統(tǒng)計與數(shù)據(jù)分析能力。  為了適應(yīng)公司的業(yè)務(wù)發(fā)展以及未來不同場景下的消息應(yīng)用，我們將引入消息中心概念，抽取通用和穩(wěn)定的部分劃歸到消息中心來實現(xiàn)，拆解模塊之間的職能，解決重復(fù)造輪子，反復(fù)改問題的現(xiàn)象。同時將不同的消息渠道整合，為不同的業(yè)務(wù)線提供不同場景的應(yīng)用支撐。基于此背景，我們搭建了一個基于內(nèi)部系統(tǒng)的消息中心。

3、設(shè)計與思考

3.1 業(yè)務(wù)系統(tǒng)架構(gòu)

應(yīng)用架構(gòu)這里就不展示了，因為是基于技術(shù)部中間件團(tuán)隊java應(yīng)用（nvwa）工廠生成標(biāo)準(zhǔn)COLA的多模塊項目模板應(yīng)用。

3.2 消息流程管理

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

• 消息生產(chǎn)：涉及到的場景很多，比如活動、系統(tǒng)通知、業(yè)務(wù)流轉(zhuǎn)、過期提醒等；
• 消息管理：對預(yù)發(fā)送消息的結(jié)構(gòu)和參數(shù)進(jìn)行校驗，并創(chuàng)建消息推送的任務(wù)，維護(hù)任務(wù)級別的推送管理，跟蹤消息的狀態(tài)周期；
• 消息處理：基于消息任務(wù)的結(jié)構(gòu)，構(gòu)建消息推送的主體內(nèi)容，并對接多個發(fā)送渠道，實現(xiàn)通知的高效觸達(dá)；
• 定時任務(wù)：消息可以直接即時推送，但如果是夜間定時任務(wù)觸發(fā)，則要考慮推送延遲問題，將消息放在指定時段投遞；
• 渠道對接：通常不同的渠道意味著不同的場景，例如監(jiān)控推送飛書，郵件走email，業(yè)務(wù)則應(yīng)用內(nèi)通知；

在整個流程中涉及到的模塊比較多，狀態(tài)的流轉(zhuǎn)也很復(fù)雜，但是通過消息中心進(jìn)行統(tǒng)一標(biāo)準(zhǔn)管理和流入流出的跟蹤，也可以提供清晰的生命周期監(jiān)控和維護(hù)。大部分的消息通知機(jī)制都可以容忍一定的延遲性，所以消息中心完全可以解耦各個流程，引入MQ隊列或者異步機(jī)制，業(yè)務(wù)方只需要將請求發(fā)送到消息中心，之后由消息中心統(tǒng)一調(diào)度和管理即可。

3.3 數(shù)據(jù)模型

3.4 飛書通道與業(yè)務(wù)系統(tǒng)對接過程中遇到的問題

3.4.1 老應(yīng)用有增量消息需接入效率消息中心，效率消息中心該如何解決歷史消息轉(zhuǎn)發(fā)及復(fù)雜交互類型消息的事件回調(diào)。

飛書側(cè)機(jī)器人回調(diào)地址只能填寫一個，歷史的應(yīng)用已經(jīng)對接過飛書平臺進(jìn)行發(fā)消息，對于系統(tǒng)增量消息想接入消息中心應(yīng)該怎么解決，在不影響老系統(tǒng)增量消息接入消息中心的又不影響歷史消息回調(diào)的情況下，消息中心采用了轉(zhuǎn)發(fā)的方式去兼容歷史的消息回調(diào)。下面是飛書回調(diào)流程：

3.4.2 如何支持飛書通道動態(tài)內(nèi)容消息，消息中心如何去做更友好的兼容適配？

動態(tài)消息內(nèi)容 和 靜態(tài)消息內(nèi)容 指的是消息（如郵件、短信、通知等）中的內(nèi)容。

靜態(tài)消息內(nèi)容是指在發(fā)送消息時事先準(zhǔn)備好的、不會發(fā)生變化的消息內(nèi)容，比如營銷郵件、歡迎短信、通知公告等。這些內(nèi)容在每次發(fā)送時都是一樣的，不會根據(jù)接收者的情況、時間等因素而發(fā)生變化。

而動態(tài)消息內(nèi)容則會根據(jù)接收者的情況、時間等因素而實時生成，以提供更好的個性化服務(wù)。動態(tài)消息內(nèi)容的例子包括訂單確認(rèn)郵件、賬戶余額提醒短信、預(yù)約成功通知等。這些消息內(nèi)容需要根據(jù)接收者的訂單信息、賬戶信息、預(yù)約信息等動態(tài)生成。

總之，靜態(tài)消息內(nèi)容是在發(fā)送消息前準(zhǔn)備好的、不會發(fā)生變化的消息內(nèi)容，而動態(tài)消息內(nèi)容是根據(jù)接收者的情況、時間等因素而實時生成的消息內(nèi)容，以提供更好的個性化服務(wù)。

目前跟業(yè)務(wù)系統(tǒng)對接的消息內(nèi)容，99%都屬于靜態(tài)消息內(nèi)容，相對于那種較復(fù)雜的動態(tài)消息內(nèi)容（圖一折線圖，圖二動態(tài)表單等動態(tài)數(shù)據(jù)）去做動態(tài)數(shù)據(jù)渲染。消息中心對于動態(tài)內(nèi)容消息渲染，解決方案是在模板功能里面抽象了一層消息內(nèi)容解析引擎，模板引擎采用的是Apache 軟件基金會下的一個開源 Java 模板引擎框架（VelocityEngine）該引擎用于生成 HTML、XML、JSON、CSV 等文件格式的文本內(nèi)容。功能非常強(qiáng)大，感興趣的同學(xué)可以去了解一下。下面拿個簡單動態(tài)消息模板舉例：

a. API接口組裝消息體

{
  "reachType": 2,
  "templateCode": "*******",
  "sendTime": 1687163457335,
  "reachList": [
    {
      "contentParamList": [
        {
          "key": "addCourseCount", // 動態(tài)參數(shù)[新增課程總數(shù) (30)]
          "value": "30"
        },
        {
          "key": "lastWeekNewCourseCount", // 動態(tài)參數(shù)[上周上新課程數(shù)量 (20)]
          "value": "20"
        },
        {
          "key": "dataList", // 動態(tài)參數(shù)，數(shù)據(jù)格式用戶可自定義
          "value": "[{\"courseName\":\"測試課程內(nèi)容1\",\"courseUrl\":\"https://t1-iwork-rdc.shizhuang-inc.net/rdc/desk\"},{\"courseName\":\"測試課程內(nèi)容2\",\"courseUrl\":\"https://t1-iwork-rdc.shizhuang-inc.net/rdc/desk\"}] "
        }
      ],
      "receiverId": "*******"
    }
  ]
}

b. 使用VelocityEngine語法解析

<code>
#set($myList=$dataList) // api接口傳過來的參數(shù)
#set($result = '')
#foreach($item in $myList) // 拼接消息內(nèi)容
#set($result = $result+'['+$item.courseName+']'+'('+$item.courseUrl+')'+'\n') 
#end
#set($growthCnotallow="**新人成長(10)**\n$result") // 輸出最終消息內(nèi)容
</code>

c. 動態(tài)渲染輸出

3.4.3 在消息中心平臺推送大規(guī)模消息，如何去跟業(yè)務(wù)系統(tǒng)的機(jī)器人去做平衡而不觸發(fā)飛書平臺限流

業(yè)務(wù)場景：在一個陽光明媚的早上，業(yè)務(wù)同學(xué)用潮人研習(xí)社的機(jī)器人給公司用戶推送了chatgpt的學(xué)習(xí)先關(guān)的內(nèi)容，消息推送觸達(dá)竟然花費了一個1多小時。

問題分析：沒辦法，做為技術(shù)boy，只能埋頭去尋找根因，主要有以下幾點

1. 如上圖所示，每次消息推送都要做獲取token這個動作，顯然獲取token這個動作是可以優(yōu)化的。基于飛書返回的失效時間做近端緩存。
2. 消息推送接口雖啟用了異步推送，但是在一個消息體里面有很多觸達(dá)用戶時，沒有進(jìn)行分組，底層推送給飛書時還是串行在推消息（這里沒有采用飛書的批量發(fā)消息接口，是因為在產(chǎn)品側(cè)有個功能要去統(tǒng)計單個用戶已讀未讀的數(shù)據(jù)，用批量推送的話，具體到用戶粒度的已讀未讀數(shù)據(jù)飛書是不支持的。另外一個原因就是飛書的機(jī)器人不是集中在消息中心進(jìn)行消息推送，需要考慮飛書側(cè)對某個機(jī)器人消息推送做限流的問題，一旦使用了某個業(yè)務(wù)系統(tǒng)的機(jī)器人進(jìn)行批量或并發(fā)推送，可能會導(dǎo)致業(yè)務(wù)系統(tǒng)業(yè)務(wù)消息推送（限流）異常）。

優(yōu)化思路：

針對上面2個問題的具體分析，主要是對問題2做了對應(yīng)的優(yōu)化，優(yōu)化思路主要是分治思想，針對大批量推送消息場景對用戶進(jìn)行分組，充分利用操作系統(tǒng)的多核優(yōu)勢。把分組的任務(wù)提交到異步消息隊列，通過自產(chǎn)自消的方式來提升消息觸達(dá)效率。

結(jié)果：

基于上面的思路去優(yōu)化并測試，效果是異常的明顯，之前推送消息需花費1個多小時，現(xiàn)在10分鐘（這里的觸達(dá)時效瓶頸主要是飛書側(cè)，飛書對消息推送接口做了限流（1s并發(fā)只能50且1min上限1000））就可以全部觸達(dá)了。

4、總結(jié)

4.1 學(xué)會聆聽

當(dāng)完成整個消息中心的設(shè)計后，要聽取他人意見，學(xué)會聆聽，因為完成這件事其實并不難。另外在網(wǎng)上也可以找到很多開源產(chǎn)品可借鑒，但是完全拿來主義不一定適合我們自己業(yè)務(wù)。所以需要跟PM、同事討論，聽取意見。再者消息中心未來是需要長期與其它部門及產(chǎn)品協(xié)調(diào)溝通的，如果一開始在做的時候就沒有與其他人去交流或技術(shù)方案討論，那么后期由于業(yè)務(wù)拓展，很有可能整體架構(gòu)很容易被推翻重構(gòu)。

4.2 結(jié)語

對于消息中心來說，根據(jù)實際業(yè)務(wù)線的豐富度，相應(yīng)應(yīng)用場景也會更加復(fù)雜，所以我們在設(shè)計消息的落地場景時，對于不同場景的適用性挑戰(zhàn)也會增大。但殊途同歸，基于降本增效去做更多思考，總歸會讓價值落地。