微服務間通信方式主要有2種:RPC和消息傳遞。

通常來說在請求/響應的場景下使用RPC更加合適,具體實現(xiàn)通常是REST API或者基于長鏈接的協(xié)議(例如gRPC/Thrift/Zero ICE等)。兩個服務有比較強的依賴關系, 調(diào)用者依賴被調(diào)用者的處理結果,調(diào)用者處理該請求被堵塞以等待響應結果,同時還要進行負載均衡、限流、熔斷、錯誤處理等。通常是同步的、一對一的交互,異步RPC本質(zhì)也是要等待響應結果才能繼續(xù)處理該請求。

消息傳遞以異步消息作為載體,通過事件代理(消息中間件)連接消息處理的上游和下游,上游和下游松散耦合,通常上游的處理邏輯不依賴下游的處理結果,具體實現(xiàn)通常有發(fā)布者/訂閱者和事件流等。而事件驅(qū)動架構(EDA)就是基于消息傳遞,通過解耦生成、傳輸和處理事件,協(xié)調(diào)事件生產(chǎn)者、消息中間件、消費者工作的一種架構模式,具有松散耦合、流量削峰、非阻塞、易于擴展、更高的彈性和錯誤處理能力等優(yōu)點。不過也帶來性能損耗、復雜性等方面的問題。


推送系統(tǒng)的業(yè)務形態(tài)

在推送系統(tǒng)中,一個推送請求的處理流程大致如下:



1. 接收請求,進行用戶身份認證、參數(shù)校驗、請求權限校驗

2. 請求解析,構建推送任務

3. 根據(jù)推送任務,篩選推送目標用戶,以及獲取推送目標用戶的基本信息

4. 根據(jù)推送策略以及各推送目標用戶的信息選擇推送通道執(zhí)行推送任務

5. 各推送通道負責具體的推送操作。

從業(yè)務場景看,極光推送平均每秒接收2萬~3萬的推送請求,包括regid、tag、alias、廣播等推送方式。各推送目標的推送目標用戶數(shù)量也不同,少則幾個,多則幾千萬甚至上億的目標數(shù)量。極光支持多推送通道,客戶可以根據(jù)需要選擇使用哪個通道進行推送,各個通道由于服務質(zhì)量、地域距離等方面的因素,請求耗時、穩(wěn)定性各有不同,此外還有各自的限速邏輯。業(yè)務面臨著很大的挑戰(zhàn):





推送系統(tǒng)如何使用事件驅(qū)動提升系統(tǒng)的整體性能

從客戶的需求和產(chǎn)品需求出發(fā),希望每個請求能夠快速、正確地響應并處理,能夠及時地把消息推送給每個目標用戶。因此我們需要解決大量消息以最快的速度推送的問題。

從業(yè)務的角度看,可以從租戶分級、租戶隔離、推送方式、推送目標規(guī)模等維度進行部署隔離,減小各租戶、各請求間的相互影響,更加快速更加穩(wěn)定地處理整個推送請求,提供更好的服務質(zhì)量。

從純技術角度看,采用了多種技術手段和策略,包括緩存優(yōu)化、異步處理、并行處理等,提升整體性能,實現(xiàn)更高效的推送操作和更好的系統(tǒng)穩(wěn)定性。

其中采用事件驅(qū)動架構來組織整個處理流程,并行、異步處理,實現(xiàn)系統(tǒng)整體性能的提升,并且在突增流量、異常處理方面都能夠很方便地應對。


推送流程的EDA實現(xiàn)

首先,將上述流程簡化為多個核心處理環(huán)節(jié),并構建為服務,通過消息中間件進行交互。



各服務基于事件傳遞狀態(tài)轉(zhuǎn)移 (Event Carried State Transfer)或者事件通知(Event Notification)模式生成事件消息,然后投遞到消息中間件中。同時各服務通過消息隊列或者訂閱的方式從消息中間件消費消息,根據(jù)實際需要由消息中間件推送事件消息給消費者或者由消費者主動拉取事件消息。對于重復消息的處理,通常有Exactly once和At least once +業(yè)務冪等性處理,建議以第二種方式處理。

注:消息中間件的選型、消息投遞服務質(zhì)量的原理不在本文的描述范圍,未展開說明。


pushAPI接收推送請求,生成推送任務事件消息,然后投遞到消息中間件。消息中間件根據(jù)相關信息發(fā)送到指定隊列中。

segmentGateway消費指定隊列,消費其中的事件消息。經(jīng)過處理后(查詢目標用戶和相關基本信息),批量填充各推送通道的目標用戶到推送任務,并生成新的推送任務事件消息投遞到消息中間件中。消息中間件根據(jù)相關信息發(fā)送到各推送通道相關的隊列中。

pushChannel的各推送通道服務消費各自的隊列,執(zhí)行推送操作。

以上流程中,事件消息的生產(chǎn)者不需要消費者的處理結果,消費者也不依賴生產(chǎn)者,完全解耦。


EDA解決推送系統(tǒng)的痛點

并行處理:各服務多節(jié)點部署,并行處理請求/消息,當服務出現(xiàn)性能不足以處理業(yè)務時,K8S環(huán)境下增加節(jié)點副本數(shù)橫向擴容即可;此外同一個推送請求通過不同推送通道推送時,多個推送通道并行推送消息。

異步處理:各服務專注自己的業(yè)務邏輯,不依賴業(yè)務下游,通常也不受下游的影響,無需等待處理結果,整個流程異步處理,減少空閑等待時間,可以最大化利用資源。

異常處理:當有突增流量時,請求流量壓力過大,超過了某個處理環(huán)節(jié)的所有服務節(jié)點的處理能力;或者某個推送通道因為網(wǎng)絡抖動、網(wǎng)絡中斷等處理慢。這些服務節(jié)點作為消息中間件的消費者,因為處理能力不足或者處理變慢,未來得及處理的請求堆積在消息中間件,等待擴容或者采取其他處理措施。緩存請求到消息中間件中,從某種程度上也是背壓(Back Pressure)模式的一種處理方式,當然還可以進一步的向上游反饋負載壓力信息,由上游采取處理措施。例如大量消息需要推送到蘋果的推送服務,由于網(wǎng)絡波動或者蘋果服務器限流,可能出現(xiàn)推送變慢,這個時候推送iOS消息可能會堆積在消息中間件中;其他推送通道并不受此影響,依然能夠正常地快速推送消息給其他通道。

其他:松散耦合使各服務更加獨立,在進行業(yè)務變更時(包括代碼邏輯變更和發(fā)布變更)通常影響面很小,某些情況下甚至能夠不影響上下游邏輯,例如某些推送通道沒有進行推送速率的限制,當增加限速邏輯時只影響該通道的服務,對于其他通道和上游服務都不影響。

借助EDA,極光推送能夠輕松處理高并發(fā)推送請求,實現(xiàn)數(shù)千萬級別的消息的快速推送,有更大的彈性應對不可預測的、更大流量的消息推送,以及有更好的異常處理能力。


未來的展望:ServiceMesh/EvenMesh混合架構,統(tǒng)一平臺化

實際上,在極光推送系統(tǒng)中,同時存在2種通信方式,例如在上面的推送流程中,需要根據(jù)推送方式獲取推送目標用戶以及相關基本信息,需要從其他子系統(tǒng)服務通過RPC進行查詢獲取結果。整個推送系統(tǒng)的其他功能也是如此,根據(jù)業(yè)務場景、數(shù)據(jù)/業(yè)務量級做權衡取舍,選擇合適的架構模式來構建系統(tǒng),保證系統(tǒng)整體性能以及系統(tǒng)的可用性、可維護性。

為了讓開發(fā)者更專注地處理核心的業(yè)務代碼邏輯,減少各種通信交互的處理細節(jié)(例如超時處理、限流等),目前請求/響應的模式比較主流的做法是Service Mesh,并且經(jīng)歷了Sidecar/Proxyless/Sidecarless幾種模式的發(fā)展,也做了各種權衡取舍。

EDA也有相對應的模式,Event Mesh就是其中之一,通過創(chuàng)建能夠高效可靠地處理任務的網(wǎng)狀代理網(wǎng)絡,解決大規(guī)模事件驅(qū)動架構的挑戰(zhàn),包括事件路由、發(fā)現(xiàn)和交付,實現(xiàn)跨復雜分布式系統(tǒng)的事件驅(qū)動通信。

我們的推送系統(tǒng)實際上是混合2個通信方式的架構,更理想、更適合我們的架構應該是二者并存。

我們也持續(xù)關注相關技術,在充分驗證的情況下引入相關技術,保持架構持續(xù)更新優(yōu)化,避免架構腐化,保證推送系統(tǒng)的高性能、高可用性、高可維護性。





關于極光

極光(Aurora Mobile,納斯達克股票代碼:JG)成立于2011年,是中國領先的客戶互動和營銷科技服務商。成立之初,極光專注于為企業(yè)提供穩(wěn)定高效的消息推送服務,憑借先發(fā)優(yōu)勢,已經(jīng)成長為市場份額遙遙領先的移動消息推送服務商。隨著企業(yè)對客戶觸達和營銷增長需求的不斷加強,極光前瞻性地推出了消息云和營銷云等解決方案,幫助企業(yè)實現(xiàn)多渠道的客戶觸達和互動需求,以及人工智能和大數(shù)據(jù)驅(qū)動的營銷科技應用,助力企業(yè)數(shù)字化轉(zhuǎn)型。



分享文章
微信
微博
復制鏈接

上一篇:

極光筆記 | 大語言模型插件

下一篇:

AIGC | LLM 提示工程 -- 如何向ChatGPT提問
登錄后可進行留言,請 登錄注冊
0條留言
快速聯(lián)系

熱門文章

相關文章

內(nèi)容標簽
#極光推送 #極光筆記

極光官方微信公眾號

關注我們,即時獲取最新極光資訊

0/140
發(fā)送

現(xiàn)在注冊,領取新人大禮包

免費注冊

您的瀏覽器版本過低

為了您在極光官網(wǎng)獲得最佳的訪問體驗,建議您升級最新的瀏覽器。