1 背景

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

圖片

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

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

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

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

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

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

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

在我們實(shí)際業(yè)務(wù)中，多個(gè)服務(wù)常常需要向用戶發(fā)送不同形式的消息，包括但不限于企業(yè)微信、飛書(shū)、短信、郵件、微信通知和手機(jī)應(yīng)用通知等。如果每個(gè)服務(wù)都獨(dú)立開(kāi)發(fā)一套消息發(fā)送代碼，這將導(dǎo)致維護(hù)難度大、錯(cuò)誤率高，效率極低。為解決這一問(wèn)題，我們開(kāi)發(fā)了“信鴿平臺(tái)”，這是一個(gè)集中式的消息服務(wù)平臺(tái)，為其他服務(wù)提供統(tǒng)一的消息發(fā)送解決方案。與公司內(nèi)的其他中臺(tá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)部需要完成多個(gè)步驟

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

圖片

3.1 消息解耦的三元素

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

圖片

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

通過(guò)以上三元素的簡(jiǎn)單配置，來(lái)達(dá)到我們信鴿消息對(duì)象的完整配置

圖片

3.2 生命周期

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

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

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

圖片

3.3 限流

3.31 對(duì)外部平臺(tái)頻控策略的適配

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

飛書(shū)限流規(guī)則：

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

企微限流規(guī)則：

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

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

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

圖片

限流后帶來(lái)的堆積排隊(duì)問(wèn)題

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

圖片

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

圖片

3.32 信鴿接口的限流

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

圖片

3.4 消息模版

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

圖片

4 總結(jié)

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

關(guān)于作者

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