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

本文做者潘唐磊，騰訊WXG（微信事業羣）開發工程師，畢業於中山大學。內容有修訂。

一、內容概述

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

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

二、名詞解釋

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

• 1）seq：自增加的序列號，每條消息對應一個（見：《微信的海量IM聊天消息序列號生成實踐》）；
• 2）ImUnion：消息互通系統，用於企業微信與微信的消息打通；
• 3）控制消息：即控制指令，屬不可見消息，是複用消息通道的一種可靠通知機制；
• 4）應用消息：系統應用下發的消息；
• 5）api 消息：第三方應用下發的消息；
• 6）appinfo：每條消息對應的惟一strid，全局惟一。同一條消息的appinfo在全部的接收方中是相同的。

三、技術背景

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

消息系統的構建與設計的過程當中，面臨着較多的難點。並且針對toB場景的消息系統，須要支持更爲複雜的業務場景。

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

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

四、總體架構設計1：架構分層

如上所示，總體架構分層以下。

1）接入層： 統一入口，接收客戶端的請求，根據類型轉發到對應的CGI層。客戶端能夠經過長連或者短連鏈接wwproxy。活躍的客戶端，優先用長鏈接發起請求，若是長連失敗，則選用短連重試。

2）CGI層： http服務，接收wwproxy的數據包，校驗用戶的session狀態，並用後臺派發的祕鑰去解包，如解密失敗則拒絕請求。解密成功，則把明文包體轉發到後端邏輯層對應的svr。

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

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

五、總體架構設計2：消息收發模型

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

如下是消息推拉的時序圖：

PS： 如上圖所示，發送方請求後臺，把消息寫入到接收方的存儲，而後push通知接收方。接受方收到push，主動上來後臺收消息。

不重、不丟、及時觸達，這三個是消息系統的核心指標：

• 1）實時觸達：客戶端經過與後臺創建長鏈接，保證消息push的實時觸達；
• 2）及時通知：若是客戶端長鏈接不在，進程被kill了，利用手機廠商的推送平臺，推送通知，或者直接拉起進程進行收消息；
• 3）消息可達：假如遇到消息洪峯，後臺的push滯後，客戶端有輪訓機制進行兜底，保證消息可達；
• 4）消息防丟：爲了防止消息丟失，只要後臺邏輯層接收到請求，保證消息寫到接收方的存儲，失敗則重試。若是請求在CGI層就失敗，則返回給客戶端出消息紅點；
• 5）消息排重：客戶端在弱網絡的場景下，有可能請求已經成功寫入存儲，回包超時，致使客戶端重試發起相同的消息，那麼就形成消息重複。爲了不這種狀況發生，每條消息都會生成惟一的appinfo，後臺經過創建索引進行排重，相同的消息直接返回成功，保證存儲只有一條。

六、總體架構設計3：消息擴散寫

IM中消息分發的典型方式，通常有兩種：

• 1）擴散讀；
• 2）擴散寫。

6.1 擴散讀

即： 每條消息只存一份，羣聊成員都讀取同一份數據。

優勢： 節省存儲容量。

缺點：

• ① 每一個用戶需存儲會話列表，經過會話id去拉取會話消息；
• ② 收消息的協議複雜，每一個會話都須要增量同步消息，則每一個會話都須要維護一個序列號。

6.2 擴散寫

即： 每條消息存多份，每一個羣聊成員在本身的存儲都有一份。

優勢：

• ① 只須要經過一個序列號就能夠增量同步全部消息，收消息協議簡單；
• ② 讀取速度快，前端體驗好；
• ③ 知足更多ToB的業務場景：回執消息、雲端刪除。

同一條消息，在每一個人的視角會有不一樣的表現。例如：回執消息，發送方能看到已讀未讀列表，接受方只能看到是否已讀的狀態。雲端刪除某條羣消息，在本身的消息列表消失，其餘人仍是可見。

缺點： 存儲容量的增長。

企業微信採用了擴散寫的方式，消息收發簡單穩定。存儲容量的增長，能夠經過冷熱分離的方案解決，冷數據存到廉價的SATA盤，擴散讀體驗稍差，協議設計也相對複雜些。

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

如上圖所示：

• 1）每一個用戶只有一條獨立的消息流。同一條消息多副本存在於每一個用戶的消息流中；
• 2）每條消息有一個seq，在同個用戶的消息流中，seq是單調遞增的；
• 3）客戶端保存消息列表中最大seq，說明客戶端已經擁有比該seq小的全部消息。若客戶端被push有新消息到達，則用該seq向後臺請求增量數據，後臺把比此seq大的消息數據返回。

七、系統穩定性設計1：柔性策略

7.1 背景

企業微信做爲一款to B場景的聊天im工具，用於工做場景的溝通，有着較爲明顯的高峯效應（以下圖所示）。

正如上圖所示： 工做時間上午9:0012:00、下午14:0018:00，是聊天的高峯，消息量劇增。工做日和節假日也會造成明顯的對比。

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

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

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

7.2 問題

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

發消息是im系統的最基礎的功能，可用性要求達到幾乎100%，因此這個策略確定須要優化。

7.3 解決方案

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

爲了保證消息系統的可用性，規避高峯期系統出現過載失敗致使前端出紅點，作了不少優化。

具體策略以下：

• 1）邏輯層hold住失敗請求，返回前端成功，不出紅點，後端異步重試，直至成功；

• 2）爲了防止在系統出現大面積故障的時候，重試請求壓滿隊列，只hold住半小時的失敗請求，半小時後新來的請求則直接返回前端失敗；

• 3）爲了不重試加重系統過載，指數時間延遲重試；

• 4）複雜的消息鑑權（好友關係，企業關係，集團關係，圈子關係），耗時嚴重，後臺波動容易形成失敗。若是並不是明確鑑權不經過，則冪等重試；

• 5）爲了防止做惡請求，限制單個用戶和單個企業的請求併發數。例如，單個用戶的消耗worker數超過20%，則直接丟棄該用戶的請求，不重試。

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

如下是優化先後的流程對比：

八、系統穩定性設計2：系統解耦

因爲產品形態的緣由，企業微信的消息系統，會依賴不少外部模塊，甚至外部系統。

例如： 與微信消息互通，發送消息的權限須要放到ImUnion去作斷定，ImUnion是一個外部系統，調用耗時較長。

再如： 金融版的消息審計功能，須要把消息同步到審計模塊，增長rpc調用。

再如： 客戶服務的單聊羣聊消息，須要把消息同步到crm模塊，增長rpc調用。爲了不外部系統或者外部模塊出現故障，拖累消息系統，致使耗時增長，則須要系統解耦。

咱們的方案： 與外部系統的交互，全設計成異步化。

思考點： 須要同步返回結果的請求，如何設計成異步化？

例如： 羣聊互通消息需通過ImUnion鑑權返回結果，前端用於展現消息是否成功發送。先讓客戶端成功，異步失敗，則回調客戶端使得出紅點。

若是是非主流程，則異步重試保證成功，主流程不受影響，如消息審計同步功能。那麼，只須要保證內部系統的穩定，發消息的主流程就能夠不受影響。

解耦效果圖：

九、系統穩定性設計3：業務隔離

企業微信的消息類型有多種：

• 1）單聊羣聊：基礎聊天，優先級高；
• 2）api 消息：企業經過api接口下發的消息，有頻率限制，優先級中；
• 3）應用消息：系統應用下發的消息，例如公告，有頻率限制，優先級中；
• 4）控制消息：不可見的消息。例如羣信息變動，會下發控制消息通知羣成員，優先級低。

羣聊按羣人數，又分紅3類：

• 1）普通羣：小於100人的羣，優先級高；
• 2）大 羣：小於2000人的羣，優先級中；
• 3）萬人羣：優先級低。

業務繁多： 若是不加以隔離，那麼其中一個業務的波動有可能引發整個消息系統的癱瘓。

重中之重： 須要保證核心鏈路的穩定，就是企業內部的單聊和100人如下羣聊，由於這個業務是最基礎的，也是最敏感的，稍有問題，投訴量巨大。

其他的業務： 互相隔離，減小牽連。按照優先級和重要程度進行隔離，對應的併發度也作了調整，儘可能保證核心鏈路的穩定性。

解耦和隔離的效果圖：

十、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次的數據請求，形成系統的巨大壓力。

控制消息在小羣是頗有必要的，能讓羣成員實時感知羣信息的變動。

可是在大羣： 羣信息的變動其實不那麼實時，用戶也感受不到。因此結合業務場景，實施降級服務，控制消息在大羣能夠直接丟棄、不分發，減小對系統的調用。

十一、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的用戶請求串行化處理，簡單易行，邏輯改動較少。

十二、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）接收方撤回流程和發送方一致，也是經過插入撤回的控制消息。

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

撤回消息的邏輯示意圖：

1三、思考與總結

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

企業微信的to B業務繁雜，有不少定製化的需求，消息系統的設計須要考慮通用性和擴展性，以便支持各類需求。例如：撤回消息的方案，能夠適用於消息任何屬性的更新，知足更多場景。（本文同步發佈於：www.52im.net/thread-3631… ）