阿里IM技術分享(三):閒魚億級IM訊息系統的架構演進之路

語言: CN / TW / HK

本文由阿里閒魚技術團隊今朝、有攸分享,本次有修訂。

1、引言

閒魚即時訊息系統歷經數代迭代,目前已能穩定的支撐億級訊息體量。

在此訊息系統的建設過程中,我們經歷了從簡單到複雜、從困擾到破局,每一次的技術改變都是為了更好的解決當下業務所面臨的問題。

本文分享的是閒魚即時訊息系統架構從零開始的技術變遷之路,以期更多的同行們在此基礎上汲取經驗,得到有價值的啟發。

學習交流:

- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM

- 開源IM框架原始碼:https://github.com/JackJiang2011/MobileIMSDK

本文同步釋出於:http://www.52im.net/thread-3699-1-1.html )

2、系列文章

本文是系列文章的第3篇,總目錄如下:

  1. 阿里IM技術分享(一):企業級IM王者——釘釘在後端架構上的過人之處
  2. 阿里IM技術分享(二):閒魚IM基於Flutter的移動端跨端改造實踐
  3. 阿里IM技術分享(三):閒魚億級IM訊息系統的架構演進之路》(* 本文
  4. 阿里IM技術分享(四):閒魚億級IM訊息系統的可靠性投遞技術實踐》(* 稍後釋出

3、1.0版:業務初創期、最小化可用

3.1 技術背景

2014年啟動閒置交易獨立APP “閒魚”,一期構建完成APP主鏈路,包含商品:釋出→搜尋→商品詳情→IM會話→交易

作為初創app,業務需儘快上線驗證效果,技術建設上需要完成閒魚訊息從無到有的系統搭建。

3.2 技術方案

作為即時通訊系統,最小化能力包含:

  • 1)訊息儲存:會話、摘要、訊息;
  • 2)訊息同步:推、拉;
  • 3)訊息通道:長連線、廠商推送。

與一般IM會話模型不同的是,閒魚會話以商品為主體,“人+人+商品”為要素構建會話。

因會話模型的差異,淘系已有的訊息系統,短期內無法滿足業務需求,而閒魚完全自建訊息系統耗時巨大。

為了保障業務高效上線,技術選型上最大化複用已有系統能力,避免重複造輪子。

所以,我們的技術方案是:

  • 1)資料模型與底層儲存依賴淘系私信體系進行建設;
  • 2)訊息資料獲取上,客戶端全量從服務端拉取訊息資料;
  • 3)通訊協議使用來往SDK及mtop。

總體架構如下圖,以此模式完成快速交付保障了業務最小化可用:

4、2.0版:使用者量增速快、需要重建訊息系統

4.1 技術背景

閒魚使用者量正快速突破100萬,即時訊息服務的呼叫量暴漲。在這樣的背景下,使用者反饋訊息資料獲取的卡頓、白屏成為常態,大量的訊息Push傳送下,系統告警頻發。

造成這些問題的原因:1.0版的架構模式下,獲取訊息資料全量拉模式,客戶端純UI不做資料儲存。

具體就是:

  • 1)當用戶需要檢視訊息資料時,資料拉取成功與否取決於網路、資料訪問速度,偶發性的造成卡頓、白屏;
  • 2)中心化的資料儲存,讀遠大於寫,高併發下,服務端負載過大。

針對第2)點:比如1W個使用者同時線上聊天,按照當前架構併發拉取全量訊息,估算5萬QPS。不妨假設,同時線上聊天使用者數10萬時,對服務端壓力可想而知。

4.2 技術方案

基於上述問題,我們決定重建訊息系統架構,以應對未來更大的使用者增量。

迴歸到IM系統的核心功能:

4.2.1)訊息儲存模型:

  • 1)會話模型:由owner、itemid、user、sessionType 來標識唯一會話,增加擴充套件屬性支援個性化;
  • 2)摘要模型:作為使用者會話檢視,同一會話的不同使用者可個性化呈現,由userid、sid標識唯一摘要;
  • 3)訊息模型:由sender、訊息內容、訊息版本、sid組成。sid+訊息版本唯一確定一條訊息;
  • 4)指令模型:是一種雙端約定,由服務端下發,客戶端執行的指令集。如免打擾指令、刪除指令等。

4.2.2)訊息通道:

1)線上通道:使用淘寶無線ACCS長連線提供的全雙工、低延時、高安全的通道服務;

2)離線通道:使用淘寶訊息推送平臺AGOO. 其遮蔽了各主流廠商對接的複雜度,直接對業務系統提供服務。

4.2.3)訊息同步模型:

1)客戶端建立資料庫,儲存訊息資料:當訊息資料儲存在本地裝置上,訊息同步從全量拉取優化為全量+增量同步結合的模式。

增量和全量同步具體指的是:

  • a. 增量同步:客戶端儲存訊息位點資訊,通過與服務端最新位點比較,僅同步增量訊息;
  • b. 全量同步:當用戶解除安裝重灌或位點gap過大時,客戶端全量拉取歷史訊息資料,進行端上資料重建。

2)服務端建設個人訊息域環(收件箱模型):以和客戶端進行增量資料同步。同時,1.0版本架構中存在的讀多寫少的問題,通過個人域環的寫擴散來平衡讀寫壓力。

下圖為一條訊息從傳送到接收的過程以及服務端和客戶端的執行流程:

如上圖所示:假設Ua給Ub傳送一條訊息,訊息寫擴散至Ua和Ub的各自的域環中:

  • 1)當客戶端online時,接收到推送的訊息位點=當前端上域版本+1,本地訊息資料庫merge即可;
  • 2)當客戶端offline時,僅進行離線推送通知,當用戶重新上線時,進行資料同步,由服務端判斷觸發增量同步還是全量同步。

針對第2)點,具體邏輯是:

  • 1)如果域環版本差值小於閥值,增量同步後,進行本地訊息資料庫merge;
  • 2)當域環版本差值大於閥值,進行全量訊息拉取,做端上資料重建。

整個同步邏輯基於閒魚的即時訊息域環,域環可以看作是有著固定容量的使用者訊息收件箱,給一個使用者傳送的所有訊息都會同步到他的域環中。

具體就是:

  • 1)域環儲存:域環需要支援高併發資料讀寫,使用阿里分散式KV儲存系統tair來實現;
  • 2)域環容量:為減少全量訊息同步,以使用者下次進入閒魚需要同步的平均訊息量來規劃個人域環容量。同時利用FIFO迴圈覆蓋歷史資料;
  • 3)域環版本:使用者當前訊息位點,在訊息進入個人域環時通過tair的counter實現域環版本嚴格連續遞增,用於全量、增量同步判斷。

上述建設完成後,閒魚具備了自己獨立的即時訊息系統,當下遇到的問題得到了緩解,使用者體驗度有大幅提升。

5、3.0版:隨著業務快速發展,系統穩定性需得到保障

5.1 技術背景

隨著閒魚業務生態的豐富,IM會話與訊息內容型別不斷擴充套件,同時在使用者量的快速增長下,使用者反饋訊息收不到、訊息延遲等輿情問題日漸突出。

5.2 問題分析

問題1:閒魚app程序無有效保活機制,app退到後臺後進程很快就會被系統掛起,導致長連線中斷。此時訊息推送走廠商通道,而廠商通道的實時性較差,且對訊息推送的優先順序設定有差異,從而造成使用者感知訊息延遲。

問題2:accs線上訊息推送時,平均延時較短,但存在假連情況。而且目前的訊息推送鏈路無ack機制,造成服務端以為訊息發出去了但實際上客戶端並沒有收到,使用者下次開啟app後才能看到訊息,使用者感知訊息延遲。

PS:造成假連線的原因主要是使用者退到後臺,accs長連中斷,但是裝置狀態更新有延時。

問題3:目前訊息同步的推模式(accs push)、拉模式(mtop),客戶端未做隔離,非同步進行處理,導致在某些極端情況下訊息資料庫處理異常,引發訊息丟失。

如:某使用者上線後連續收到多條訊息,其中一條觸發域黑洞,在進行訊息同步端上資料重建時,小概率處理出錯。

問題4:大部分線上訊息問題發現靠輿情反饋,如訊息錯亂,出問題後系統無感知、無補救措施且排查困難,僅能跟隨版本做修復。

問題5:業務不斷豐富,孵化出基於訊息系統的服務號及小程式內容營銷、訊息群組等,各類訊息傳送鏈路共用域環與資料儲存,造成穩定性問題。

如:個人域環的訊息包括IM聊天和營銷訊息,IM聊天由使用者觸發,需要保證強到達;而營銷訊息一般是由系統通過班車等方式批量傳送,訊息量級大,tps高,影響IM服務穩定性。

5.3 解案決方案

基於上述分析,我們逐個問題進行專項解決。

1)訊息重發與推拉隔離:

如上圖所示:

  • a. ACK:保障訊息及時到達。服務端下行accs訊息時,將訊息加入重試佇列並延遲重試,客戶端在收到accs訊息並處理成功後,給服務端回一個ack,服務端收到ack後更新訊息到達狀態,並終止重試,以此避免裝置假連或網路不穩定的情況;
  • b. 重發:根據延遲重發策略決定何時重發訊息,保障訊息確定性到達。自適應延遲重發策略是指新訊息先通過4次固定N秒的短延遲來探測裝置的網路狀況,然後根據網路狀況來遞增固定步長M的延遲策略,這種策略可以保障在最短的時間內,使用最少的重發次數將訊息投遞成功;
  • c. 訊息佇列:端上引入訊息佇列,按順序處理訊息,保證訊息處理的準確性。同時進行推拉隔離,保障佇列有序消費,解決了複雜狀況下併發處理訊息資料合併出錯的問題。

2)資料儲存拆分:

閒魚每天傳送的即時訊息中有一半以上是營銷訊息,營銷訊息的傳送具有明顯的波峰波谷流量,高峰期會導致訊息資料庫抖動,影響IM訊息。我來對訊息、摘要、域環儲存做業務隔離,以適應不同業務場景對穩定性不同的要求。

具體做法是:

  • 1)IM訊息需要極高的穩定性保證,其訊息及摘要繼續使用mysql儲存;
  • 2)營銷訊息儲存週期短,穩定性要求低於IM,採用Lindorm儲存;
  • 3)域環做例項級別隔離,保證IM域環的容量不會被其他訊息佔用,從而影響到訊息同步。

PS:Lindorm是一種多模型的雲原生資料庫服務,具有成本低、自定義TTL、容量橫向擴充套件等優勢。

3)線上問題發現與恢復:

保障穩定性的關鍵要素是做好各種核心指標的監控,而監控首先要有資料來源,對服務端+客戶端的關鍵鏈路節點埋點,基於集團UT、SLS,通過blink進行實時清洗、計算,最終形成統一規範的日誌資料落至SLS,以供實時監控及鏈路排查。

訊息系統的核心目標是保障使用者訊息發的出、收得到且及時收到,所以我們通過計算髮送成功率、到達率、訊息延遲來監控系統的穩定性。

此外,為了解決使用者輿情排查困難的問題:

  • 1)我們設計了一套指令集,通過約定指令協議,服務端向指定使用者下發指令,客戶端執行對應指令進行異常資料上報,提高排查效率;
  • 2)擴充套件了強制全量同步、資料校正等指令,定向修復使用者訊息資料問題,相較以往出現嚴重bug只能讓使用者解除安裝重灌解決,這種方式顯然對使用者是更友好的。

經過一系列專項治理,技術類輿情下降50%,從0到1建設了訊息穩定性體系,使用者體驗進一步提升。

6、展望未來

閒魚作為電商交易APP, 其中IM是交易的前置鏈路,IM的產品體驗極大影響使用者交易效率。

前段時間進行使用者調研,從閒魚IM的NPS低於預期(NPS是使用者忠誠度衡量指標 = 推薦者%-貶損者%)。

從使用者反饋來看:

  • 1)部分使用者對產品功能有較強烈的訴求,諸如訊息搜尋、分組等;
  • 2)大部分使用者對傳送訊息過程中的違規問題難以理解;
  • 3)仍有較多輿情反饋訊息收不到或延遲。

對映到目前閒魚的即時訊息系統上,我們的系統架構依然有很多需要持續改進的地方。

典型的如:同步協議冗餘,在需求迭代過程中容易引發問題、有效保活機制的缺失對訊息即時送達的影響、小眾機型離線訊息收不到、多年的資料積累線上庫臃腫等問題,影響著閒魚業務迭代速度與NPS。

作為技術團隊,下一步將提升NPS作為核心技術目標,閒魚的即時訊息系統4.0版架構正在路上 ......

附錄:更多相關文章

[1] 更多阿里巴巴的技術資源:

阿里釘釘技術分享:企業級IM王者——釘釘在後端架構上的過人之處

現代IM系統中聊天訊息的同步和儲存方案探討

阿里技術分享:深度揭祕阿里資料庫技術方案的10年變遷史

阿里技術分享:阿里自研金融級資料庫OceanBase的艱辛成長之路

來自阿里OpenIM:打造安全可靠即時通訊服務的技術實踐分享

釘釘——基於IM技術的新一代企業OA平臺的技術挑戰(視訊+PPT) [附件下載]

阿里技術結晶:《阿里巴巴Java開發手冊(規約)-華山版》[附件下載]

重磅釋出:《阿里巴巴Android開發手冊(規約)》[附件下載]

作者談《阿里巴巴Java開發手冊(規約)》背後的故事

《阿里巴巴Android開發手冊(規約)》背後的故事

乾了這碗雞湯:從理髮店小弟到阿里P10技術大牛

揭祕阿里、騰訊、華為、百度的職級和薪酬體系

淘寶技術分享:手淘億級移動端接入層閘道器的技術演進之路

難得乾貨,揭祕支付寶的2維碼掃碼技術優化實踐之路

淘寶直播技術乾貨:高清、低延時的實時視訊直播技術解密

阿里技術分享:電商IM訊息平臺,在群聊、直播場景下的技術實踐

阿里技術分享:閒魚IM基於Flutter的移動端跨端改造實踐

阿里IM技術分享(三):閒魚億級IM訊息系統的架構演進之路

 

[2] 有關IM架構設計的文章:

淺談IM系統的架構設計

簡述移動端IM開發的那些坑:架構設計、通訊協議和客戶端

一套海量線上使用者的移動端IM架構設計實踐分享(含詳細圖文)

一套原創分散式即時通訊(IM)系統理論架構方案

從零到卓越:京東客服即時通訊系統的技術架構演進歷程

蘑菇街即時通訊/IM伺服器開發之架構選擇

騰訊QQ1.4億線上使用者的技術挑戰和架構演進之路PPT

微信後臺基於時間序的海量資料冷熱分級架構設計實踐

微信技術總監談架構:微信之道——大道至簡(演講全文)

如何解讀《微信技術總監談架構:微信之道——大道至簡》

快速裂變:見證微信強大後臺架構從0到1的演進歷程(一)

移動端IM中大規模群訊息的推送如何保證效率、實時性?

現代IM系統中聊天訊息的同步和儲存方案探討

微信朋友圈千億訪問量背後的技術挑戰和實踐總結

子彈簡訊光鮮的背後:網易雲信首席架構師分享億級IM平臺的技術實踐

微信技術分享:微信的海量IM聊天訊息序列號生成實踐(演算法原理篇)

一套高可用、易伸縮、高併發的IM群聊、單聊架構方案設計實踐

社交軟體紅包技術解密(一):全面解密QQ紅包技術方案——架構、技術實現等

從游擊隊到正規軍(一):馬蜂窩旅遊網的IM系統架構演進之路

從游擊隊到正規軍(二):馬蜂窩旅遊網的IM客戶端架構演進和實踐總結

從游擊隊到正規軍(三):基於Go的馬蜂窩旅遊網分散式IM系統技術實踐

瓜子IM智慧客服系統的資料架構設計(整理自現場演講,有配套PPT)

IM開發基礎知識補課(九):想開發IM叢集?先搞懂什麼是RPC!

阿里技術分享:電商IM訊息平臺,在群聊、直播場景下的技術實踐

一套億級使用者的IM架構技術乾貨(上篇):整體架構、服務拆分等

一套億級使用者的IM架構技術乾貨(下篇):可靠性、有序性、弱網優化等

從新手到專家:如何設計一套億級訊息量的分散式IM系統

企業微信的IM架構設計揭祕:訊息模型、萬人群、已讀回執、訊息撤回等

融雲技術分享:全面揭祕億級IM訊息的可靠投遞機制

IM開發技術學習:揭祕微信朋友圈這種資訊推流背後的系統設計

阿里IM技術分享(三):閒魚億級IM訊息系統的架構演進之路

>> 更多同類文章 ……

本文已同步釋出於“即時通訊技術圈”公眾號。

同步釋出連結是:http://www.52im.net/thread-3699-1-1.html 

「其他文章」