1 背景

隨著各項(xiàng)業(yè)務(wù)線上化，觸達(dá)用戶的方式日益重要，而即時通訊服務(wù)成為了至關(guān)重要的溝通媒介。諸如企業(yè)微信和飛書等消息通知工具已經(jīng)成為我們與用戶互動的首選方式。隨著通知需求的不斷增加，我們的消息通知代碼也在各個服務(wù)中逐漸累積，然而，這也伴隨著一系列問題的出現(xiàn)。

圖片

1.1 強(qiáng)耦合的消息和業(yè)務(wù)代碼

消息發(fā)送和業(yè)務(wù)流程代碼緊密相連，導(dǎo)致消息發(fā)送問題直接影響業(yè)務(wù)流程。例如，我們的部分流程依賴于用戶對發(fā)送的消息進(jìn)行審批，只有審批完成后，才能進(jìn)入下一流程節(jié)點(diǎn)。這種設(shè)計(jì)使得消息系統(tǒng)的任何故障都可能直接影響整個業(yè)務(wù)流程的運(yùn)行。

1.2 服務(wù)間代碼重復(fù)，維護(hù)困難

不同服務(wù)均需消息發(fā)送功能，導(dǎo)致多個服務(wù)中存在重復(fù)的消息發(fā)送工具類。這不僅增加了代碼的重復(fù)性，也使得對消息發(fā)送功能的更新和迭代變得復(fù)雜。當(dāng)需要更新消息發(fā)送功能時，必須在各個服務(wù)中分別進(jìn)行修改，增加了維護(hù)的難度和出錯的可能性。

1.3 消息發(fā)送的偶發(fā)丟失問題

目前的架構(gòu)中，大量消息通過多個服務(wù)的工具類直接調(diào)用各消息平臺的HTTPS接口發(fā)送。這種設(shè)計(jì)在生產(chǎn)環(huán)境中導(dǎo)致了消息偶發(fā)性的丟失——消息雖然發(fā)送，但用戶未收到。由于代碼分散，排查此類問題非常困難，我們只能依賴于發(fā)送時的日志進(jìn)行追蹤，這大大增加了問題診斷的復(fù)雜性。

2 現(xiàn)狀和痛點(diǎn)

在我們實(shí)際業(yè)務(wù)中，多個服務(wù)常常需要向用戶發(fā)送不同形式的消息，包括但不限于企業(yè)微信、飛書、短信、郵件、微信通知和手機(jī)應(yīng)用通知等。如果每個服務(wù)都獨(dú)立開發(fā)一套消息發(fā)送代碼，這將導(dǎo)致維護(hù)難度大、錯誤率高，效率極低。為解決這一問題，我們開發(fā)了“信鴿平臺”，這是一個集中式的消息服務(wù)平臺，為其他服務(wù)提供統(tǒng)一的消息發(fā)送解決方案。與公司內(nèi)的其他中臺服務(wù)類似，信鴿服務(wù)的主要目標(biāo)是實(shí)現(xiàn)業(yè)務(wù)消息的優(yōu)雅傳遞。該服務(wù)專注于消息的全周期管理，確保消息發(fā)送的穩(wěn)定性，并提供業(yè)務(wù)分析功能，以更高效、可靠的方式處理各種業(yè)務(wù)通知需求。

圖片

3 設(shè)計(jì)和實(shí)現(xiàn)

為了讓信鴿服務(wù)的接口能被使用的更方便，信鴿服務(wù)內(nèi)部需要完成多個步驟

• 消息服務(wù)接口鑒權(quán)
• 模版加載處理
• 消息前置校驗(yàn)
• 多消息通道頻控兼容
• 消息重試處理
• 消息生命周期監(jiān)控

圖片

3.1 消息解耦的三元素

結(jié)合實(shí)際的業(yè)務(wù)場景，我們把消息拆分出了三個元素：場景、機(jī)器人、模版

圖片

• 場景：當(dāng)前發(fā)送的消息的業(yè)務(wù)場景
• 機(jī)器人：發(fā)送當(dāng)前的機(jī)器人/應(yīng)用
• 模版：當(dāng)前消息模版

通過以上三元素的簡單配置，來達(dá)到我們信鴿消息對象的完整配置

圖片

3.2 生命周期

不同平臺的消息，在信鴿中都擁有著統(tǒng)一生命周期：

• 初始化
• 發(fā)送中
• 消息發(fā)送成功
• 消息重試中
• 消息發(fā)送失敗

在實(shí)際生產(chǎn)環(huán)境中，若由于某種因素需要查看消息的狀態(tài)，可根據(jù)消息唯一號，判斷消息的狀態(tài)。

圖片

3.3 限流

3.31 對外部平臺頻控策略的適配

當(dāng)我們的消息發(fā)送頻率超出各平臺的限制時，會導(dǎo)致消息發(fā)送失敗并被丟棄。這對于那些依賴于消息傳達(dá)的關(guān)鍵場景來說，可能造成嚴(yán)重的影響。此外，先前提及的消息偶發(fā)丟失問題，大多也是由于這些外部平臺的頻率控制導(dǎo)致的。

飛書限流規(guī)則：

• 所有接口每個應(yīng)用最高請求頻率 50次/秒
• 發(fā)送消息接口每個應(yīng)用最高頻率是1000次/分鐘
• 群聊機(jī)器人Webhook最高頻率是100次/分鐘
• 機(jī)器人給同一用戶或同一群發(fā)的最高頻率是5次/秒

企微限流規(guī)則：

• 每個機(jī)器人發(fā)送的消息不能超過20條/分鐘

對每個機(jī)器人/應(yīng)用作對外適配的頻率限制：

因此，信鴿平臺采用了簡易的分布式限流算法，并結(jié)合模板方法和策略模式，實(shí)現(xiàn)了兩種限流機(jī)制：計(jì)數(shù)器算法和令牌桶算法。通過自定義注解，我們可以在項(xiàng)目中靈活地切換限流配置，從而有效適應(yīng)不同平臺的頻率控制策略。這樣的設(shè)計(jì)不僅提高了系統(tǒng)的適應(yīng)性，也確保了消息傳遞的穩(wěn)定性和效率。

圖片

限流后帶來的堆積排隊(duì)問題

在企業(yè)微信應(yīng)用中設(shè)定了每分鐘最多向每個用戶發(fā)送30條消息的限制。假設(shè)在某一時刻，場景A產(chǎn)生了210條消息，那么按照這個發(fā)送頻率，至少需要7分鐘才能完成所有消息的發(fā)送。此外，如果在這個過程中，場景B產(chǎn)生了一條消息，這條消息將不得不等待場景A的所有消息發(fā)送完畢后才能被發(fā)送。這樣的處理機(jī)制可能導(dǎo)致消息傳遞的延遲，特別是在高峰時段或多場景并發(fā)時。

圖片

所以我們進(jìn)行了改造：基于場景分區(qū)，消費(fèi)者會根據(jù)分區(qū)輪詢消費(fèi)。而不是等待A隊(duì)列消費(fèi)完成后再消費(fèi)B隊(duì)列。這樣有效降低了同一機(jī)器人下的限流堆積問題。當(dāng)然，如果有更大體量的消息，還是建議使用多個機(jī)器人來提高消費(fèi)的速率。

圖片

3.32 信鴿接口的限流

考慮到服務(wù)是通過SCF層進(jìn)行接入的，我們可以利用SCF提供的配置來實(shí)現(xiàn)接口限流。這意味著，通過簡單地配置SCF接口，我們就能輕松實(shí)現(xiàn)上線接口的限流功能。這種方法簡化了限流的實(shí)現(xiàn)過程，確保服務(wù)在高并發(fā)情況下的穩(wěn)定運(yùn)行，同時降低了系統(tǒng)復(fù)雜性和維護(hù)成本

圖片

3.4 消息模版

為了方便各服務(wù)快速發(fā)送基本消息，信鴿平臺提供了一套消息模板。這些模板旨在簡化消息發(fā)送流程，用戶只需填充必要的參數(shù)并進(jìn)行接口調(diào)用，即可輕松發(fā)送一條消息。這種設(shè)計(jì)極大地提高了消息發(fā)送的效率，同時降低了服務(wù)集成的復(fù)雜性。下面提供的是一個用于飛書消息發(fā)送的模板示例，展示了如何便捷地使用這些模板發(fā)送消息。

圖片

4 總結(jié)

本文概述了信鴿服務(wù)，它已經(jīng)成為新媒體業(yè)務(wù)體系中的核心組件，承擔(dān)著消息發(fā)送的統(tǒng)一服務(wù)職責(zé)。信鴿服務(wù)的核心目標(biāo)是實(shí)現(xiàn)消息的集中管理和高效傳遞。展望未來，我們計(jì)劃進(jìn)一步增強(qiáng)信鴿服務(wù)的功能，包括事務(wù)消息處理、消息的優(yōu)先級排序，以及夜間消息發(fā)送的屏蔽控制。這些改進(jìn)將使信鴿服務(wù)更加全面和強(qiáng)大，更好地服務(wù)于業(yè)務(wù)需求。

關(guān)于作者

吳冰寒，現(xiàn)任轉(zhuǎn)轉(zhuǎn)乾數(shù)據(jù)技術(shù)部后端研發(fā)工程師。