本文作者潘唐磊，騰訊WXG（微信事業群）開發工程師，畢業于中山大學。內容有修訂。
1、內容概述
本文總結了企業微信的IM消息系統架構設計，闡述了企業業務給IM架構設計帶來的技術難點和挑戰，以及技術方案的對比與分析。同時總結了IM后臺開發的一些常用手段，適用于IM消息系統。
* 推薦閱讀：企業微信團隊分享的另一篇《企業微信客戶端中組織架構數據的同步更新方案優化實戰》也值得一讀。
學習交流：
（本文同步發布于：http://www.52im.net/thread-3631-1-1.html）
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中消息分發的典型方式，一般有兩種：
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業務繁雜，有很多定制化的需求，消息系統的設計需要考慮通用性和擴展性，以便支持各種需求。例如：撤回消息的方案，可以適用于消息任何屬性的更新，滿足更多場景。
附錄：更多精華文章
[1] 有關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系統》
[2] QQ、微信團隊原創技術文章：
《微信朋友圈千億訪問量背后的技術挑戰和實踐總結》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(音視頻技術篇)》
《微信團隊分享：微信移動端的全文檢索多音字問題解決方案》
《騰訊技術分享：Android版手機QQ的緩存監控與優化實踐》
《微信團隊分享：iOS版微信的高性能通用key-value組件技術實踐》
《微信團隊分享：iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的？》
《騰訊技術分享：Android手Q的線程死鎖監控系統技術實踐》
《微信團隊原創分享：iOS版微信的內存監控系統技術實踐》
《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》
《iOS后臺喚醒實戰：微信收款到賬語音提醒技術總結》
《騰訊技術分享：社交網絡圖片的帶寬壓縮技術演進之路》
《微信團隊分享：視頻圖像的超分辨率技術原理和應用場景》
《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊團隊分享：手機QQ中的人臉識別酷炫動畫效果實現詳解》
《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《微信手機端的本地數據全文檢索優化之路》
《企業微信客戶端中組織架構數據的同步更新方案優化實戰》
《微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《QQ 18年：解密8億月活的QQ后臺服務接口隔離技術》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《以手機QQ為例探討移動端IM中的“輕應用”》
《一篇文章get微信開源移動端數據庫組件WCDB的一切！》
《微信客戶端團隊負責人技術訪談：如何著手客戶端性能監控和優化》
《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》
《微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信后臺團隊：微信后臺異步消息隊列的優化升級實踐分享》
《微信團隊原創分享：微信客戶端SQLite數據庫損壞修復實踐》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《微信Mars：微信內部正在使用的網絡層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信后臺保活實戰分享(進程保活篇)》
《微信團隊原創分享：Android版微信后臺保活實戰分享(網絡保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《微信海量用戶背后的后臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬連接背后的后臺解決方案》
《微信朋友圈海量技術之道PPT [附件下載]》
《微信對網絡影響的技術試驗及分析（論文全文）》
《一份微信后臺技術架構的總結性筆記》
《架構之道：3個程序員成就微信朋友圈日均10億發布量[有視頻]》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（一）》
《快速裂變：見證微信強大后臺架構從0到1的演進歷程（二）》
《微信團隊原創分享：Android內存泄漏監控和優化技巧總結》
《全面總結iOS版微信升級iOS9遇到的各種“坑”》
《微信團隊原創資源混淆工具：讓你的APK立減1M》
《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》
《Android版微信安裝包“減肥”實戰記錄》
《iOS版微信安裝包“減肥”實戰記錄》
《移動端IM實踐：iOS版微信界面卡頓監測方案》
《微信“紅包照片”背后的技術難題》
《移動端IM實踐：iOS版微信小視頻功能技術方案實錄》
《移動端IM實踐：Android版微信如何大幅提升交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提升交互性能（二）》
《移動端IM實踐：實現Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《移動端IM實踐：iOS版微信的多設備字體適配方案探討》
《信鴿團隊原創：一起走過 iOS10 上消息推送(APNS)的坑》
《騰訊信鴿技術分享：百億級實時消息推送的實戰經驗》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《騰訊TEG團隊原創：基于MySQL的分布式數據庫TDSQL十年鍛造經驗分享》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
《了解iOS消息推送一文就夠：史上最全iOS Push技術詳解》
《騰訊技術分享：微信小程序音視頻技術背后的故事》
《騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面》
《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
《手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術研究學習)》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《騰訊技術分享：GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐》
《微信團隊分享：Kotlin漸被認可，Android版微信的技術嘗鮮之旅》
《QQ設計團隊分享：新版 QQ 8.0 語音消息改版背后的功能設計思路》
《微信團隊分享：極致優化，iOS版微信編譯速度3倍提升的實踐總結》
《IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術實現》
《微信團隊分享：微信支付代碼重構帶來的移動端軟件架構上的思考》
《IM開發寶典：史上最全，微信各種功能參數和邏輯規則資料匯總》
《微信團隊分享：微信直播聊天室單房間1500萬在線的消息架構演進之路》
本文已同步發布于“即時通訊技術圈”公眾號。
▲ 本文在公眾號上的鏈接是：點此進入。同步發布鏈接是：http://www.52im.net/thread-3631-1-1.html