1
什麼是消息中心
消息中心是一個集中管理、分發通知和提醒的平台，可以讓使用者或系統消息更友善、快捷的觸達給指定使用者或者系統。并且可以幫助使用者或系統更好地管理消息的生命周期，屏蔽不同消息管道差異與技術差異，進而提升效率與體驗，降低維護成本。
2
為什麼要搭建消息中心
- 公司目前處于快速發展階段，業務線正在快速拓展，不同的産品線也正在逐漸增加，與此同時，不同的産品線均需要通過消息子產品來觸達内部或外部使用者，基本上每一個系統都需要有自己的消息通知體系。但在由于不同業務開發團隊互相獨立，為了避免協調溝通這種不可預估的成本，各業務開發團隊都采取了“自主”開發的方式解決此類問題。這樣造成的結果就是：各業務團隊不斷地重複發明輪子，而且這輪子不可複用，造成了資源和時間成本的大量浪費。更為關鍵的是：功能無法複用，持續疊代也無法沉澱。當面對一個新業務時，即便公司已有成熟的功能，但仍然無法有效地縮短業務創新和推進的時間。
- 各業務系統均以功能的概念在設計，業務資源和開發資源會存在大量的重複消耗，在維護方面也存在諸多問題，并且不利于統一管理，并且也沒有相關消息觸達統計與資料分析能力。
- 為了适應公司的業務發展以及未來不同場景下的消息應用，我們将引入消息中心概念，抽取通用和穩定的部分劃歸到消息中心來實作，拆解子產品之間的職能，解決重複造輪子，反複改問題的現象。同時将不同的消息管道整合，為不同的業務線提供不同場景的應用支撐。基于此背景，我們搭建了一個基于内部系統的消息中心。
3
設計與思考
3.1 業務系統架構
應用架構這裡就不展示了，因為是基于技術部中間件團隊java應用（nvwa）工廠生成标準COLA的多子產品項目模闆應用。
3.2 消息流程管理
消息通知的流程設計，在各個業務線中通過消息中心提供的接口方法，将不同場景下的消息内容送出到消息中心，消息中心進行統一維護管理，并根據消息的來源和去向，适配相應的推送邏輯：
- 消息生産：涉及到的場景很多，比如活動、系統通知、業務流轉、過期提醒等；
- 消息管理：對預發送消息的結構和參數進行校驗，并建立消息推送的任務，維護任務級别的推送管理，跟蹤消息的狀态周期；
- 消息處理：基于消息任務的結構，建構消息推送的主體内容，并對接多個發送管道，實作通知的高效觸達；
- 定時任務：消息可以直接即時推送，但如果是夜間定時任務觸發，則要考慮推送延遲問題，将消息放在指定時段投遞；
- 管道對接：通常不同的管道意味着不同的場景，例如監控推送飛書，郵件走email，業務則應用内通知；
在整個流程中涉及到的子產品比較多，狀态的流轉也很複雜，但是通過消息中心進行統一标準管理和流入流出的跟蹤，也可以提供清晰的生命周期監控和維護。大部分的消息通知機制都可以容忍一定的延遲性，是以消息中心完全可以解耦各個流程，引入MQ隊列或者異步機制，業務方隻需要将請求發送到消息中心，之後由消息中心統一排程和管理即可。
3.3 資料模型
3.4 飛書通道與業務系統對接過程中遇到的問題
3.4.1 老應用有增量消息需接入效率消息中心，效率消息中心該如何解決曆史消息轉發及複雜互動類型消息的事件回調。
飛書側機器人回調位址隻能填寫一個，曆史的應用已經對接過飛書平台進行發消息，對于系統增量消息想接入消息中心應該怎麼解決，在不影響老系統增量消息接入消息中心的又不影響曆史消息回調的情況下，消息中心采用了轉發的方式去相容曆史的消息回調。下面是飛書回調流程：
3.4.2 如何支援飛書通道動态内容消息，消息中心如何去做更友好的相容适配？
和 指的是消息（如郵件、短信、通知等）中的内容。
靜态消息内容是指在發送消息時事先準備好的、不會發生變化的消息内容，比如營銷郵件、歡迎短信、通知公告等。這些内容在每次發送時都是一樣的，不會根據接收者的情況、時間等因素而發生變化。
而動态消息内容則會根據接收者的情況、時間等因素而實時生成，以提供更好的個性化服務。動态消息内容的例子包括訂單确認郵件、賬戶餘額提醒短信、預約成功通知等。這些消息内容需要根據接收者的訂單資訊、賬戶資訊、預約資訊等動态生成。
總之，靜态消息内容是在發送消息前準備好的、不會發生變化的消息内容，而動态消息内容是根據接收者的情況、時間等因素而實時生成的消息内容，以提供更好的個性化服務。
目前跟業務系統對接的消息内容，99%都屬于靜态消息内容，相對于那種較複雜的動态消息内容（圖一折線圖，圖二動态表單等動态資料）去做動态資料渲染。消息中心對于動态内容消息渲染，解決方案是在模闆功能裡面抽象了一層消息内容解析引擎，模闆引擎采用的是Apache 軟體基金會下的一個開源 Java 模闆引擎架構（VelocityEngine）該引擎用于生成 HTML、XML、JSON、CSV 等檔案格式的文本内容。功能非常強大，感興趣的同學可以去了解一下。下面拿個簡單動态消息模闆舉例：
a. API接口組裝消息體
{
"reachType": 2,
"templateCode": "*******",
"sendTime": 1687163457335,
"reachList": [
{
"contentParamList": [
{
"key": "addCourseCount", // 動态參數[新增課程總數 (30)]
"value": "30"
},
{
"key": "lastWeekNewCourseCount", // 動态參數[上周上新課程數量 (20)]
"value": "20"
},
{
"key": "dataList", // 動态參數，資料格式使用者可自定義
"value": "[{\"courseName\":\"測試課程内容1\",\"courseUrl\":\"https://t1-iwork-rdc.shizhuang-inc.net/rdc/desk\"},{\"courseName\":\"測試課程内容2\",\"courseUrl\":\"https://t1-iwork-rdc.shizhuang-inc.net/rdc/desk\"}] "
}
],
"receiverId": "*******"
}
]
} b. 使用VelocityEngine文法解析
<code>
#set($myList=$dataList) // api接口傳過來的參數
#set($result = '')
#foreach($item in $myList) // 拼接消息内容
#set($result = $result+'['+$item.courseName+']'+'('+$item.courseUrl+')'+'\n')
#end
#set($growthContent="**新人成長(10)**\n$result") // 輸出最終消息内容
</code> c. 動态渲染輸出
3.4.3 在消息中心平台推送大規模消息，如何去跟業務系統的機器人去做平衡而不觸發飛書平台限流
- 如上圖所示，每次消息推送都要做擷取token這個動作，顯然擷取token這個動作是可以優化的。基于飛書傳回的失效時間做近端緩存。
- 消息推送接口雖啟用了異步推送，但是在一個消息體裡面有很多觸達使用者時，沒有進行分組，底層推送給飛書時還是串行在推消息（這裡沒有采用飛書的批量發消息接口，是因為在産品側有個功能要去統計單個使用者已讀未讀的資料，用批量推送的話，具體到使用者粒度的已讀未讀資料飛書是不支援的。另外一個原因就是飛書的機器人不是集中在消息中心進行消息推送，需要考慮飛書側對某個機器人消息推送做限流的問題，一旦使用了某個業務系統的機器人進行批量或并發推送，可能會導緻業務系統業務消息推送（限流）異常）。
針對上面2個問題的具體分析，主要是對問題2做了對應的優化，優化思路主要是分治思想，針對大批量推送消息場景對使用者進行分組，充分利用作業系統的多核優勢。把分組的任務送出到異步消息隊列，通過自産自消的方式來提升消息觸達效率。
基于上面的思路去優化并測試，效果是異常的明顯，之前推送消息需花費1個多小時，現在10分鐘（這裡的觸達時效瓶頸主要是飛書側，飛書對消息推送接口做了限流（1s并發隻能50且1min上限1000））就可以全部觸達了。
4
總結
4.1 學會聆聽
當完成整個消息中心的設計後，要聽取他人意見，學會聆聽，因為完成這件事其實并不難。另外在網上也可以找到很多開源産品可借鑒，但是完全拿來主義不一定适合我們自己業務。是以需要跟PM、同僚讨論，聽取意見。再者消息中心未來是需要長期與其它部門及産品協調溝通的，如果一開始在做的時候就沒有與其他人去交流或技術方案讨論，那麼後期由于業務拓展，很有可能整體架構很容易被推翻重構。
4.2 結語
對于消息中心來說，根據實際業務線的豐富度，相應應用場景也會更加複雜，是以我們在設計消息的落地場景時，對于不同場景的适用性挑戰也會增大。但殊途同歸，基于降本增效去做更多思考，總歸會讓價值落地。
作者:Leezr
來源:微信公衆号:得物技術
出處:https://mp.weixin.qq.com/s/SWenfaa7obt6XrSA5gZA1A