當前位置: 妍妍網 > 碼農

多平台訊息推播服務的實踐

2024-03-02碼農

架構師(JiaGouX)

我們都是架構師!
架構未來,你來不來?

  • 1 背景

  • 1.1 強耦合的訊息和業務程式碼

  • 1.2 服務間程式碼重復,維護困難

  • 1.3 訊息發送的偶發遺失問題

  • 2 現狀和痛點

  • 3 設計和實作

  • 3.1 訊息解耦的三元素

  • 3.2 生命周期

  • 3.3 限流

  • 3.4 訊息模版

  • 4 總結


  • 1 背景

    隨著各項業務線上化,觸達使用者的方式日益重要,而即時通訊服務成為了至關重要的溝通媒介。諸如企業微信和飛書等訊息通知工具已經成為我們與使用者互動的首選方式。隨著通知需求的不斷增加,我們的訊息通知程式碼也在各個服務中逐漸累積,然而,這也伴隨著一系列問題的出現。

    1.1 強耦合的訊息和業務程式碼

    訊息發送和業務流程程式碼緊密相連,導致訊息發送問題直接影響業務流程。例如,我們的部份流程依賴於使用者對發送的訊息進行審批,只有審批完成後,才能進入下一流程節點。這種設計使得訊息系統的任何故障都可能直接影響整個業務流程的執行。

    1.2 服務間程式碼重復,維護困難

    不同服務均需訊息發送功能,導致多個服務中存在重復的訊息發送工具類。這不僅增加了程式碼的重復性,也使得對訊息發送功能的更新和叠代變得復雜。當需要更新訊息發送功能時,必須在各個服務中分別進行修改,增加了維護的難度和出錯的可能性。

    1.3 訊息發送的偶發遺失問題

    目前的架構中,大量訊息透過多個服務的工具類直接呼叫各訊息平台的HTTPS介面發送。這種設計在生產環境中導致了訊息偶發性的遺失——訊息雖然發送,但使用者未收到。由於代分碼散,排查此類問題非常困難,我們只能依賴於發送時的日誌進行追蹤,這大大增加了問題診斷的復雜性。


    2 現狀和痛點

    在我們實際業務中,多個服務常常需要向使用者發送不同形式的訊息,包括但不限於企業微信、飛書、簡訊、信件、微信通知和手機套用通知等。如果每個服務都獨立開發一套訊息發送程式碼,這將導致維護難度大、錯誤率高,效率極低。為解決這一問題,我們開發了「信鴿平台」,這是一個集中式的訊息服務平台,為其他服務提供統一的訊息發送解決方案。與公司內的其他中台服務類似,信鴿服務的主要目標是實作業務訊息的優雅傳遞。該服務專註於訊息的全周期管理,確保訊息發送的穩定性,並提供業務分析功能,以更高效、可靠的方式處理各種業務通知需求。

    3 設計和實作

    為了讓信鴿服務的介面能被使用的更方便,信鴿服務內部需要完成多個步驟

  • 訊息服務介面鑒權

  • 模版載入處理

  • 訊息前置校驗

  • 多訊息通道頻控相容

  • 訊息重試處理

  • 訊息生命周期監控

  • 3.1 訊息解耦的三元素

    結合實際的業務場景,我們把訊息拆分出了三個元素:場景、機器人、模版

  • 場景:當前發送的訊息的業務場景

  • 機器人:發送當前的機器人/套用

  • 模版:當前訊息模版

  • 透過以上三元素的簡單配置,來達到我們信鴿訊息物件的完整配置

    3.2 生命周期

    不同平台的訊息,在信鴿中都擁有著統一生命周期:

  • 初始化

  • 發送中

  • 訊息發送成功

  • 訊息重試中

  • 訊息發送失敗

  • 在實際生產環境中,若由於某種因素需要檢視訊息的狀態,可根據訊息唯一號,判斷訊息的狀態。

    3.3 限流

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

    當我們的訊息發送頻率超出各平台的限制時,會導致訊息發送失敗並被丟棄。這對於那些依賴於訊息傳達的關鍵場景來說,可能造成嚴重的影響。此外,先前提及的訊息偶發遺失問題,大多也是由於這些外部平台的頻率控制導致的。

    飛書限流規則:

  • 所有介面每個套用最高請求頻率 50次/秒

  • 發送訊息介面每個套用最高頻率是1000次/分鐘

  • 群聊機器人Webhook最高頻率是100次/分鐘

  • 機器人給同一使用者或同一群發的最高頻率是5次/秒

  • 企微限流規則:

  • 每個機器人發送的訊息不能超過20條/分鐘

  • 對每個機器人/套用作對外適配的頻率限制:

    因此,信鴿平台采用了簡易的分布式限流演算法,並結合樣版方法和策略模式,實作了兩種限流機制:計數器演算法和令牌桶演算法。透過自訂註解,我們可以在計畫中靈活地切換限流配置,從而有效適應不同平台的頻率控制策略。這樣的設計不僅提高了系統的適應力,也確保了訊息傳遞的穩定性和效率。

    限流後帶來的堆積排隊問題

    在企業微信套用中設定了每分鐘最多向每個使用者發送30條訊息的限制。假設在某一時刻,場景A產生了210條訊息,那麽按照這個發送頻率,至少需要7分鐘才能完成所有訊息的發送。此外,如果在這個過程中,場景B產生了一條訊息,這條訊息將不得不等待場景A的所有訊息發送完畢後才能被發送。這樣的處理機制可能導致訊息傳遞的延遲,特別是在高峰時段或多場景並行時。

    所以我們進行了改造:基於場景分區,消費者會根據分區輪詢消費。而不是等待A佇列消費完成後再消費B佇列。這樣有效降低了同一機器人下的限流堆積問題。當然,如果有更大體量的訊息,還是建議使用多個機器人來提高消費的速率。

    3.32 信鴿介面的限流

    考慮到服務是透過SCF層進行接入的,我們可以利用SCF提供的配置來實作介面限流。這意味著,透過簡單地配置SCF介面,我們就能輕松實作上線介面的限流功能。這種方法簡化了限流的實作過程,確保服務在高並行情況下的穩定執行,同時降低了系統復雜性和維護成本

    3.4 訊息模版

    為了方便各服務快速發送基本訊息,信鴿平台提供了一套訊息樣版。這些樣版旨在簡化訊息發送流程,使用者只需填充必要的參數並進行介面呼叫,即可輕松發送一條訊息。這種設計極大地提高了訊息發送的效率,同時降低了服務整合的復雜性。下面提供的是一個用於飛書訊息發送的樣版範例,展示了如何便捷地使用這些樣版發送訊息。


    4 總結

    本文概述了信鴿服務,它已經成為新媒體業務體系中的核心元件,承擔著訊息發送的統一服務職責。信鴿服務的核心目標是實作訊息的集中管理和高效傳遞。展望未來,我們計劃進一步增強信鴿服務的功能,包括事務訊息處理、訊息的優先級排序,以及夜間訊息發送的遮蔽控制。這些改進將使信鴿服務更加全面和強大,更好地服務於業務需求。

    如喜歡本文,請點選右上角,把文章分享到朋友圈
    如有想了解學習的技術點,請留言給若飛安排分享

    因公眾號更改推播規則,請點「在看」並加「星標」 第一時間獲取精彩技術分享

    ·END·

    相關閱讀:

    作者:吳冰寒

    來源:轉轉技術

    版權申明:內容來源網路,僅供學習研究,版權歸原創者所有。如有侵權煩請告知,我們會立即刪除並表示歉意。謝謝!

    架構師

    我們都是架構師!

    關註 架構師(JiaGouX),添加「星標」

    獲取每天技術幹貨,一起成為牛逼架構師

    技術群請 加若飛: 1321113940 進架構師群

    投稿、合作、版權等信箱: [email protected]