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

語言: CN / TW / HK

本文作者潘唐磊,騰訊WXG(微信事業群)開發工程師,畢業於中山大學。內容有修訂。

1、內容概述

本文總結了企業微信的IM訊息系統架構設計,闡述了企業業務給IM架構設計帶來的技術難點和挑戰,以及技術方案的對比與分析。同時總結了IM後臺開發的一些常用手段,適用於IM訊息系統。

* 推薦閱讀:企業微信團隊分享的另一篇《企業微信客戶端中組織架構資料的同步更新方案優化實戰》也值得一讀。

2、名詞解釋

以下是本文內容中涉及到的技術名詞縮寫,具體意義如下:

  • 1)seq:自增長的序列號,每條訊息對應一個(見:《微信的海量IM聊天訊息序列號生成實踐》);
  • 2)ImUnion:訊息互通系統,用於企業微信與微信的訊息打通;
  • 3)控制訊息:即控制指令,屬不可見訊息,是複用訊息通道的一種可靠通知機制;
  • 4)應用訊息:系統應用下發的訊息;
  • 5)api 訊息:第三方應用下發的訊息;
  • 6)appinfo:每條訊息對應的唯一strid,全域性唯一。同一條訊息的appinfo在所有的接收方中是相同的。

3、技術背景

企業微信作為一款辦公協同的產品,聊天訊息收發是最基礎的功能。訊息系統的穩定性、可靠性、安全性尤其重要。

訊息系統的構建與設計的過程中,面臨著較多的難點。而且針對toB場景的訊息系統,需要支援更為複雜的業務場景。

針對toB場景的特有業務有:

  • 1)訊息鑑權:關係型別有群關係、同企業同事關係、好友關係、集團企業關係、圈子企業關係。收發訊息雙方需存在至少一種關係才允許發訊息;
  • 2)回執訊息:每條訊息都需記錄已讀和未讀人員列表,涉及頻繁的狀態讀寫操作;
  • 3)撤回訊息:支援24小時的有效期撤回動作;
  • 4)訊息儲存:雲端儲存時間跨度長,最長可支援180天訊息儲存,數百TB使用者訊息需優化,減少機器成本;
  • 5)萬人群聊:群人數上限可支援10000人,一條群訊息就像一次小型的DDoS攻擊;
  • 6)微信互通:兩個異構的im系統直接打通,可靠性和一致性尤其重要。

4、整體架構設計1:架構分層

如上所示,整體架構分層如下。

1)接入層:統一入口,接收客戶端的請求,根據型別轉發到對應的CGI層。客戶端可以通過長連或者短連連線wwproxy。活躍的客戶端,優先用長連線發起請求,如果長連失敗,則選用短連重試。

2)CGI層:http服務,接收wwproxy的資料包,校驗使用者的session狀態,並用後臺派發的祕鑰去解包,如解密失敗則拒絕請求。解密成功,則把明文包體轉發到後端邏輯層對應的svr。

3)邏輯層:大量的微服務和非同步處理服務,使用自研的hikit rpc框架,svr之間使用tcp短連進行通訊。進行資料整合和邏輯處理。和外部系統的通訊,通過http協議,包括微信互通、手機廠商的推送平臺等。

4)儲存層:訊息儲存是採用的是基於levelDB模型開發msgkv。SeqSvr是序列號生成器,保證派發的seq單調遞增不回退,用於訊息的收發協議。

5、整體架構設計2:訊息收發模型

企業微信的訊息收發模型採用了推拉方式,這種方式可靠性高,設計簡單。

以下是訊息推拉的時序圖:

PS:如上圖所示,傳送方請求後臺,把訊息寫入到接收方的儲存,然後push通知接收方。接受方收到push,主動上來後臺收訊息。

不重、不丟、及時觸達,這三個是訊息系統的核心指標:

  • 1)實時觸達:客戶端通過與後臺建立長連線,保證訊息push的實時觸達;
  • 2)及時通知:如果客戶端長連線不在,程序被kill了,利用手機廠商的推送平臺,推送通知,或者直接拉起程序進行收訊息;
  • 3)訊息可達:假如遇到訊息洪峰,後臺的push滯後,客戶端有輪訓機制進行兜底,保證訊息可達;
  • 4)訊息防丟:為了防止訊息丟失,只要後臺邏輯層接收到請求,保證訊息寫到接收方的儲存,失敗則重試。如果請求在CGI層就失敗,則返回給客戶端出訊息紅點;
  • 5)訊息排重:客戶端在弱網路的場景下,有可能請求已經成功寫入儲存,回包超時,導致客戶端重試發起相同的訊息,那麼就造成訊息重複。為了避免這種情況發生,每條訊息都會生成唯一的appinfo,後臺通過建立索引進行排重,相同的訊息直接返回成功,保證儲存只有一條。

6、整體架構設計3:訊息擴散寫

IM中訊息分發的典型方式,一般有兩種:

  • 1)擴散讀;
  • 2)擴散寫。

6.1 擴散讀

即:每條訊息只存一份,群聊成員都讀取同一份資料。

優點:節省儲存容量。

缺點:

  • ① 每個使用者需儲存會話列表,通過會話id去拉取會話訊息;
  • ② 收訊息的協議複雜,每個會話都需要增量同步訊息,則每個會話都需要維護一個序列號。

6.2 擴散寫

即:每條訊息存多份,每個群聊成員在自己的儲存都有一份。

優點:

  • ① 只需要通過一個序列號就可以增量同步所有訊息,收訊息協議簡單;
  • ② 讀取速度快,前端體驗好;
  • ③ 滿足更多ToB的業務場景:回執訊息、雲端刪除。

同一條訊息,在每個人的視角會有不同的表現。例如:回執訊息,傳送方能看到已讀未讀列表,接受方只能看到是否已讀的狀態。雲端刪除某條群訊息,在自己的訊息列表消失,其他人還是可見。

缺點:儲存容量的增加。

企業微信採用了擴散寫的方式,訊息收發簡單穩定。儲存容量的增加,可以通過冷熱分離的方案解決,冷資料存到廉價的SATA盤,擴散讀體驗稍差,協議設計也相對複雜些。

下圖是擴散寫的協議設計:

如上圖所示:

  • 1)每個使用者只有一條獨立的訊息流。同一條訊息多副本存在於每個使用者的訊息流中;
  • 2)每條訊息有一個seq,在同個使用者的訊息流中,seq是單調遞增的;
  • 3)客戶端儲存訊息列表中最大seq,說明客戶端已經擁有比該seq小的所有訊息。若客戶端被push有新訊息到達,則用該seq向後臺請求增量資料,後臺把比此seq大的訊息資料返回。

7、系統穩定性設計1:柔性策略

7.1 背景

企業微信作為一款to B場景的聊天im工具,用於工作場景的溝通,有著較為明顯的高峰效應(如下圖所示)。

正如上圖所示:工作時間上午9:00~12:00、下午14:00~18:00,是聊天的高峰,訊息量劇增。工作日和節假日也會形成明顯的對比。

高峰期系統壓力大,偶發的網路波動或者機器過載,都有可能導致大量的系統失敗。im系統對及時性要求比較高,沒辦法進行削峰處理。那麼引入一些柔性的策略,保證系統的穩定性和可用性非常有必要。

具體的做法就是啟動過載保護策略:當svr已經達到最大處理能力的時候,說明處於一個過載的狀態,服務能力會隨著負載的增高而急劇下降。如果svr過載,則拒絕掉部分正常請求,防止機器被壓垮,依然能對外服務。通過統計svr的被調耗時情況、worker使用情況等,判定是否處於過載狀態。過載保護策略在請求高峰期間起到了保護系統的作用,防止雪崩效應。

下圖就是因過載被拒絕掉的請求:

7.2 問題

上一小結中過載保護策略所帶來的問題就是:系統過載返回失敗,前端發訊息顯示失敗,顯示紅點,會嚴重影響產品體驗。

發訊息是im系統的最基礎的功能,可用性要求達到幾乎100%,所以這個策略肯定需要優化。

7.3 解決方案

解決方案思路就是:儘管失敗,也返回前端成功,後臺保證最終成功。

為了保證訊息系統的可用性,規避高峰期系統出現過載失敗導致前端出紅點,做了很多優化。

具體策略如下:

  • 1)邏輯層hold住失敗請求,返回前端成功,不出紅點,後端非同步重試,直至成功;
  • 2)為了防止在系統出現大面積故障的時候,重試請求壓滿佇列,只hold住半小時的失敗請求,半小時後新來的請求則直接返回前端失敗;
  • 3)為了避免重試加劇系統過載,指數時間延遲重試;
  • 4)複雜的訊息鑑權(好友關係,企業關係,集團關係,圈子關係),耗時嚴重,後臺波動容易造成失敗。如果並非明確鑑權不通過,則冪等重試;
  • 5)為了防止作惡請求,限制單個使用者和單個企業的請求併發數。例如,單個使用者的消耗worker數超過20%,則直接丟棄該使用者的請求,不重試。

優化後,後臺的波動,前端基本沒有感知。

以下是優化前後的流程對比:

8、系統穩定性設計2:系統解耦

由於產品形態的原因,企業微信的訊息系統,會依賴很多外部模組,甚至外部系統。

例如:與微信訊息互通,傳送訊息的許可權需要放到ImUnion去做判定,ImUnion是一個外部系統,呼叫耗時較長。

再如:金融版的訊息審計功能,需要把訊息同步到審計模組,增加rpc呼叫。

再如:客戶服務的單聊群聊訊息,需要把訊息同步到crm模組,增加rpc呼叫。為了避免外部系統或者外部模組出現故障,拖累訊息系統,導致耗時增加,則需要系統解耦。

我們的方案:與外部系統的互動,全設計成非同步化。

思考點:需要同步返回結果的請求,如何設計成非同步化?

例如:群聊互通訊息需經過ImUnion鑑權返回結果,前端用於展示訊息是否成功傳送。先讓客戶端成功,非同步失敗,則回撥客戶端使得出紅點。

如果是非主流程,則非同步重試保證成功,主流程不受影響,如訊息審計同步功能。那麼,只需要保證內部系統的穩定,發訊息的主流程就可以不受影響。

解耦效果圖:

9、系統穩定性設計3:業務隔離

企業微信的訊息型別有多種:

  • 1)單聊群聊:基礎聊天,優先順序高;
  • 2)api 訊息:企業通過api介面下發的訊息,有頻率限制,優先順序中;
  • 3)應用訊息:系統應用下發的訊息,例如公告,有頻率限制,優先順序中;
  • 4)控制訊息:不可見的訊息。例如群資訊變更,會下發控制訊息通知群成員,優先順序低。

群聊按群人數,又分成3類:

  • 1)普通群:小於100人的群,優先順序高;
  • 2)大 群:小於2000人的群,優先順序中;
  • 3)萬人群:優先順序低。

業務繁多:如果不加以隔離,那麼其中一個業務的波動有可能引起整個訊息系統的癱瘓。

重中之重:需要保證核心鏈路的穩定,就是企業內部的單聊和100人以下群聊,因為這個業務是最基礎的,也是最敏感的,稍有問題,投訴量巨大。

其餘的業務:互相隔離,減少牽連。按照優先順序和重要程度進行隔離,對應的併發度也做了調整,儘量保證核心鏈路的穩定性。

解耦和隔離的效果圖:

10、to B業務功能的設計與優化1:萬人群

10.1 技術背景

企業微信的群人數上限是10000,只要群內每個人都發一條訊息,那麼擴散量就是10000 * 10000 = 1億次呼叫,非常巨大。

10000人投遞完成需要的耗時長,影響了訊息的及時性。

10.2 問題分析

既然超大群擴散寫量大、耗時長,那麼自然會想到:超大群是否可以單獨拎出來做成擴散讀呢。

下面分析一下超大群設計成單副本面臨的難點:

  • ① 一個超大群,一條訊息流,群成員都同步這條流的訊息;
  • ② 假如使用者擁有多個超大群,則需要同步多條流,客戶端需維護每條流的seq;
  • ③ 客戶端解除安裝重灌,並不知道擁有哪些訊息流,後臺需儲存並告知;
  • ④ 某個超大群來了新訊息,需通知所有群成員,假如push沒觸達,客戶端沒辦法感知有新訊息,不可能去輪訓所有的訊息流。

綜上所述:單副本的方案代價太大。

以下將介紹我們針對萬人群聊擴散寫的方案,做的一些優化實踐。

10.3 優化1:併發限制

萬人群的擴散量大,為了是訊息儘可能及時到達,使用了多協程去分發訊息。但是並不是無限制地加大併發度。

為了避免某個萬人群的高頻發訊息,造成對整個訊息系統的壓力,訊息分發以群id為維度,限制了單個群的分發併發度。訊息分發給一個人的耗時是8ms,那麼萬人的總體耗時是80s,併發上限是5,那麼訊息分發完成需要16s。16s的耗時,在產品角度來看還、是可以接受的,大群對及時性不敏感。同時,併發度控制在合理範圍內。

除了限制單個群id的併發度,還限制了萬人群的總體併發度。單臺機,小群的worker數為250個,萬人群的worker數為30。

萬人群的頻繁發訊息,worker數用滿,導致隊列出現積壓:

由於併發限制,呼叫數被壓平,沒有請求無限上漲,系統穩定:

10.4 優化2:合併插入

工作場景的聊天,多數是在小群完成,大群用於管理員發通知或者老闆發紅包。

大群訊息有一個常見的規律:平時訊息少,會突然活躍。例如:老闆在群裡發個大紅包,群成員起鬨,此時就會產生大量的訊息。

訊息量上漲、併發度被限制、任務處理不過來,那麼佇列自然就會積壓。積壓的任務中可能存在多條訊息需要分發給同一個群的群成員。

此時:可以將這些訊息,合併成一個請求,寫入到訊息儲存,訊息系統的吞吐量就可以成倍增加。

在日常的監控中,可以捕獲到這種場景,高峰可以同時插入20條訊息,對整個系統很友善。

10.5 優化3:業務降級

比如:群人員變更、群名稱變動、群設定變更,都會在群內擴散一條不可見的控制訊息。群成員收到此控制訊息,則向後臺請求同步新資料。

舉個例子:一個萬人群,由於訊息過於頻繁,對群成員造成騷擾,部分群成員選擇退群來拒絕訊息,假設有1000人選擇退群。那麼擴散的控制訊息量就是1000w,使用者收到控制訊息就向後臺請求資料,則額外帶來1000w次的資料請求,造成系統的巨大壓力。

控制訊息在小群是很有必要的,能讓群成員實時感知群資訊的變更。

但是在大群:群資訊的變更其實不那麼實時,使用者也感覺不到。所以結合業務場景,實施降級服務,控制訊息在大群可以直接丟棄、不分發,減少對系統的呼叫。

11、to B業務功能的設計與優化2:回執訊息

11.1 技術背景

回執訊息是辦公場景經常用到的一個功能,能看到訊息接受方的閱讀狀態。

一條回執訊息的閱讀狀態會被頻繁修改,群訊息被修改的次數和群成員人數成正比。每天上億條訊息,讀寫頻繁,請求量巨大,怎麼保證每條訊息在接受雙方的狀態是一致的是一個難點。

11.2 實現方案

訊息的閱讀狀態的儲存方式兩個方案。

方案一:

思路:利用訊息儲存,插入一條新訊息指向舊訊息,此新訊息有最新的閱讀狀態。客戶端收到新訊息,則用新訊息的內容替換舊訊息的內容展示,以達到展示閱讀狀態的效果。

優點:複用訊息通道,增量同步訊息就可以獲取到回執狀態,複用通知機制和收發協議,前後端改造小。

缺點:

  • ① 儲存冗餘,狀態變更多次,則需插入多條訊息;
  • ② 收發雙方都需要修改閱讀狀態(接收方需標誌訊息為已讀狀態),存在收發雙方資料一致性問題。

方案二:

思路:獨立儲存每條訊息的閱讀狀態,訊息傳送者通過訊息id去拉取資料。

優點:狀態一致。

缺點:

  • ① 構建可靠的通知機制,通知客戶端某條訊息屬性發生變更;
  • ② 同步協議複雜,客戶端需要準確知道哪條訊息的狀態已變更;
  • ③ 訊息過期刪除,閱讀狀態資料也要自動過期刪除。

企業微信採用了方案一去實現,簡單可靠、改動較小:儲存冗餘的問題可以通過LevelDB落盤的時候merge資料,只保留最終狀態那條訊息即可;一致性問題下面會介紹如何解決。

 

上圖是協議流程referid:被指向的訊息id,senderid:訊息傳送方的msgid):

  • 1)每條訊息都有一個唯一的msgid,只在單個使用者內唯一,kv儲存自動生成的;
  • 2)接收方b已讀訊息,客戶端帶上msgid=b1請求到後臺;
  • 3)在接受方b新增一條訊息,msgid=b2,referid=b1,指向msgid=b1的訊息。並把msgid=b2的訊息內容設定為訊息已讀。msgid=b1的訊息體,存有傳送方的msgid,即senderid=a1;
  • 4)傳送方a,讀出msgid=a1的訊息體,把b加入到已讀列表,把新的已讀列表儲存到訊息體中,生成新訊息msgid=a2,referid=a1,追加寫入到a的訊息流;
  • 5)接收方c已讀同一條訊息,在c的訊息流走同樣的邏輯;
  • 6)傳送方a,讀出msgid=a1的訊息體,把c加入到已讀列表,把新的已讀列表儲存到訊息體中,生成新訊息msgid=a3,referid=a1,追加寫入到a的訊息流。a3>a2,以msgid大的a3為最終狀態。

11.3 優化1:非同步化

接受方已讀訊息,讓客戶端同步感知成功,但是傳送方的狀態沒必要同步修改。因為傳送方的狀態修改情況,接受方沒有感知不到。那麼,可以採用非同步化的策略,降低同步呼叫耗時。

具體做法是:

  • 1)接受方的資料同步寫入,讓客戶端馬上感知訊息已讀成功;
  • 2)傳送方的資料非同步寫入,減少同步請求;
  • 3)非同步寫入通過重試來保證成功,達到狀態最終一致的目的。

11.4 優化2:合併處理

客戶端收到大量訊息,並不是一條一條訊息已讀確認,而是多條訊息一起已讀確認。為了提高回執訊息的處理效率,可以對多條訊息合併處理。

如上圖所示:

  • 1)X>>A:表示X發了一條訊息給A;
  • 2)A合併確認3條訊息,B合併確認3條訊息。那麼只需要處理2次,就能標誌6條訊息已讀;
  • 3)經過mq分發,相同的傳送方也可以合併處理。在傳送方,X合併處理2條訊息,Y合併處理2條訊息,Z合併處理2條訊息,則合併處理3次就能標誌6條訊息。

經過合併處理,處理效率大大提高。下圖是採集了線上高峰時期的呼叫資料。可以看得出來,優化後的效果一共節省了44%的寫入量。

11.5 讀寫覆蓋解決

傳送方的訊息處理方式是先把資料讀起來,修改後重新覆蓋寫入儲存。接收方有多個,那麼就會併發寫傳送方資料,避免不了出現覆蓋寫的問題。

流程如下:

  • 1)傳送方某條訊息的已讀狀態是X;
  • 2)接收方a確認已讀,已讀狀態修改為X+a;
  • 3)接收方b確認已讀,已讀狀態修改為X+b;
  • 4)接收方a的狀態先寫入,接受方b的狀態後寫入。這最終狀態為X+b;
  • 5)其實正確的狀態是X+a+b。

處理這類問題,無非就一下幾種辦法。

方案一:因為併發操作是分散式,那麼可以採用分散式鎖的方式保證一致。操作儲存之前,先申請分散式鎖。這種方案太重,不適合這種高頻多賬號的場景。

方案二:帶版本號讀寫。一個賬號的訊息流只有一個版本鎖,高頻寫入的場景,很容易產生版本衝突,導致寫入效率低下。

方案三:mq序列化處理。能避免覆蓋寫問題,關鍵是在合併場景起到很好的作用。同一個賬號的請求序列化,就算出現佇列積壓,合併的策略也能提高處理效率。

企業微信採用了方案三,相同id的使用者請求序列化處理,簡單易行,邏輯改動較少。

12、to B業務功能的設計與優化3:撤回訊息

12.1 技術難點

撤回訊息”相當於更新原訊息的狀態,是不是也可以通過referid的方式去指向呢?

回執訊息分析過:通過referid指向,必須要知道原訊息的msgid。

區別於回執訊息:撤回訊息需要修改所有接收方的訊息狀態,而不僅僅是傳送方和單個接收方的。訊息擴散寫到每個接收方的訊息流,各自的訊息流對應的msgid是不相同的,如果沿用referid的方式,那就需要記錄所有接收方的msgid。

12.2 解決方案

分析:撤回訊息比回執訊息簡單的是,撤回訊息只需要更新訊息的狀態,而不需要知道原訊息的內容。接收方的訊息的appinfo都是相同的,可以通過appinfo去做指向。

協議流程:

  • 1)使用者a、b、c,都存在同一條訊息,appinfo=s,sendtime=t;
  • 2)a撤回該訊息,則在a的訊息流插入一條撤回的控制訊息,訊息體包含{appinfo=s,sendtime=t};
  • 3)客戶端sync到撤回的控制訊息,獲取到訊息體的appinfo與sendtime,把本地appinfo=s且sendtime=t的原訊息顯示為撤回狀態,並刪除原訊息資料。之所以引入sendtime欄位,是為了防止appinfo碰撞,加的雙重校驗;
  • 4)接收方撤回流程和傳送方一致,也是通過插入撤回的控制訊息。

該方案的優點明顯,可靠性高,協議簡單。

撤回訊息的邏輯示意圖:

13、思考與總結

企業微信的IM訊息架構與微信類似,但是在to B業務場景面臨了一些新的挑戰。結合產品形態、分析策略,通過優化方案,來確保訊息系統的可靠性、穩定性、安全性。

企業微信的to B業務繁雜,有很多定製化的需求,訊息系統的設計需要考慮通用性和擴充套件性,以便支援各種需求。例如:撤回訊息的方案,可以適用於訊息任何屬性的更新,滿足更多場景。

附錄:更多IM架構設計文章

淺談IM系統的架構設計

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

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

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

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

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

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

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

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

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

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

17年的實踐:騰訊海量產品的技術方法論

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

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

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

以微博類應用場景為例,總結海量社交系統的架構設計步驟

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

IM開發基礎知識補課(五):通俗易懂,正確理解並用好MQ訊息佇列

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

微信技術分享:微信的海量IM聊天訊息序列號生成實踐(容災方案篇)

新手入門:零基礎理解大型分散式架構的演進歷史、技術原理、最佳實踐

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

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

社交軟體紅包技術解密(二):解密微信搖一搖紅包從0到1的技術演進

社交軟體紅包技術解密(三):微信搖一搖紅包雨背後的技術細節

社交軟體紅包技術解密(四):微信紅包系統是如何應對高併發的

社交軟體紅包技術解密(五):微信紅包系統是如何實現高可用性的

社交軟體紅包技術解密(六):微信紅包系統的儲存層架構演進實踐

社交軟體紅包技術解密(七):支付寶紅包的海量高併發技術實踐

社交軟體紅包技術解密(八):全面解密微博紅包技術方案

社交軟體紅包技術解密(九):談談手Q紅包的功能邏輯、容災、運維、架構等

社交軟體紅包技術解密(十):手Q客戶端針對2020年春節紅包的技術實踐

社交軟體紅包技術解密(十一):解密微信紅包隨機演算法(含程式碼實現)

即時通訊新手入門:一文讀懂什麼是Nginx?它能否實現IM的負載均衡?

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

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

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

IM開發基礎知識補課(六):資料庫用NoSQL還是SQL?讀這篇就夠了!

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

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

微信後臺基於時間序的新一代海量資料儲存架構的設計實踐

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

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

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

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

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

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

▲ 本文在公眾號上的連結是:點此進入。同步釋出連結是:http://www.52im.net/thread-3631-1-1.html

「其他文章」