本文作者潘唐磊，騰訊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開發基礎知識補課(五)：通俗易懂，正確理解並用好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架構技術乾貨(上篇)：整體架構、服務拆分等》
本文已同步發佈於“即時通訊技術圈”公衆號。
▲ 本文在公衆號上的鏈接是：點此進入。同步發佈鏈接是：http://www.52im.net/thread-3631-1-1.html
