本文引用了唐小智發(fā)表于InfoQ公眾號上的“釘釘企業(yè)級IM存儲架構(gòu)創(chuàng)新之道”一文的部分內(nèi)容，收錄時(shí)有改動，感謝原作者的無私分享。

1、引言

業(yè)界的 IM 產(chǎn)品在功能上同質(zhì)化較高，而企業(yè)級的 IM 產(chǎn)品對于高可用、安全性又有更高的要求，如何打造具備差異化的產(chǎn)品，又在高可用、安全性、數(shù)據(jù)一致性等方面具備較高的品質(zhì)，是企業(yè)級 IM 產(chǎn)品成功的關(guān)鍵。釘釘在過去短短幾年時(shí)間里，用戶數(shù)已破 2 億，企業(yè)組織數(shù)破千萬，釘釘是在規(guī)劃企業(yè)級 IM 產(chǎn)品的架構(gòu)上有何過人之處？本文將圍繞這個(gè)話題進(jìn)行展開。

 

閱讀提示：本文適合有一定IM后端架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)的開發(fā)者閱讀，或許出于商業(yè)產(chǎn)品技術(shù)秘密的考慮，分享者在本次所分享的內(nèi)容上有所保留，鑒于阿里對于釘釘在技術(shù)上的內(nèi)容分享做的非常少，所以本文雖然內(nèi)容不夠全面，但仍然值得一讀。

學(xué)習(xí)交流：

- 即時(shí)通訊/推送技術(shù)開發(fā)交流5群：215477170 [推薦]

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

（本文同步發(fā)布于：http://www.52im.net/thread-2848-1-1.html）

2、相關(guān)文章

《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實(shí)戰(zhàn)》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》

《釘釘——基于IM技術(shù)的新一代企業(yè)OA平臺的技術(shù)挑戰(zhàn)(視頻+PPT) [附件下載]》 （* 推薦）

3、不同的場景，釘釘?shù)募軜?gòu)思路不同

釘釘?shù)募夹g(shù)棧繼承自阿里巴巴集團(tuán)。阿里有著”大中臺，小前臺“的組織戰(zhàn)略，所以釘釘在大的框架上是復(fù)用集團(tuán)的能力，包括集團(tuán)的中間件、存儲引擎、微服務(wù)框架等。在此之上，釘釘聚焦在核心能力的研發(fā)，比如：IM 核心系統(tǒng)、系統(tǒng)單元化、音視頻通訊，弱網(wǎng)優(yōu)化，圖片收發(fā)極致體驗(yàn)等等。

釘釘作為 ToB 產(chǎn)品，業(yè)務(wù)場景跟 ToC 的 IM 產(chǎn)品有很大區(qū)別，架構(gòu)上也各有側(cè)重。

3.1 萬人大群的架構(gòu)設(shè)計(jì)思路

 

（本圖引用自：《釘釘——基于IM技術(shù)的新一代企業(yè)OA平臺的技術(shù)挑戰(zhàn)(視頻+PPT)》 ）

在釘釘里，企業(yè)的組織關(guān)系映射到 IM 的群，產(chǎn)生了為數(shù)眾多的超級大群。和 500 群人數(shù)上限相比，釘釘支持萬人大群，大幅提升了群的觸達(dá)人數(shù)。

如此數(shù)目繁多的萬人群給 IM 系統(tǒng)的流量沖擊巨大。在節(jié)假日，特別是元旦、春節(jié)或者雙 11 這樣的重大活動時(shí)期，管理層和員工在大群高頻互動，流量洪峰瞬間流過 IM 系統(tǒng)，挑戰(zhàn)著系統(tǒng)的極限。

為支撐好超級大群，我們做了以下多點(diǎn)的優(yōu)化。

3.1.1）降低存儲擴(kuò)散量：

最早 IM 使用寫擴(kuò)散模型，一萬人的群發(fā)一條消息寫一萬次消息收件箱。優(yōu)化為讀擴(kuò)散模型后，一條消息只需寫一次消息收件箱，擴(kuò)散量降低到萬分之一。

3.1.2）智能限流：

在節(jié)日場景下，一些大群的消息發(fā)送頻率過高，可能超過系統(tǒng)整體容量，影響 IM 系統(tǒng)穩(wěn)定性。如果對每個(gè)群設(shè)置較低的發(fā)送閾值，系統(tǒng)又沒有完全發(fā)揮出容量，從而提供足夠流暢的用戶體驗(yàn)。針對這個(gè)問題，我們設(shè)計(jì)了一種智能限流的方法，當(dāng)總體流量超過系統(tǒng)閾值時(shí)，自動根據(jù)當(dāng)時(shí)情況對消息發(fā)送頻率相對較高的大群進(jìn)行限流。

3.1.3）萬人群成員多級緩存：

我們在客戶端、服務(wù)端建立了群成員的多級緩存。

一方面增強(qiáng)了用戶打開 at 列表、查看群成員列表的體驗(yàn)。因?yàn)槿撼蓡T人數(shù)增大時(shí)，打開群成員列表的延遲提升明顯，用戶能感受到長達(dá)數(shù)十秒的卡頓。增加客戶端緩存后，用戶輸入 @立刻響應(yīng)成員列表，即使群里有幾萬個(gè)群成員。另一方面避免了大量群成員讀寫對 DB 的壓力。如果壓力直接打到 DB 層，萬行記錄的擴(kuò)散量過大，很容易造成熱點(diǎn)，影響系統(tǒng)穩(wěn)定性。

3.1.4）端到端的體驗(yàn)保證：

客戶端定期做極限壓測，在群消息大規(guī)模刷屏的情況，保證用戶體驗(yàn)流暢不卡頓。

更多有關(guān)群聊的架構(gòu)設(shè)計(jì)文章：

《如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”？》

《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》

《IM群聊消息如此復(fù)雜，如何保證不丟不重？》

《微信后臺團(tuán)隊(duì)：微信后臺異步消息隊(duì)列的優(yōu)化升級實(shí)踐分享》

《移動端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》

《關(guān)于IM即時(shí)通訊群聊消息的亂序問題討論》

《IM群聊消息的已讀回執(zhí)功能該怎么實(shí)現(xiàn)？》

《IM群聊消息究竟是存1份(即擴(kuò)散讀)還是存多份(即擴(kuò)散寫)？》

《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐》

《IM群聊機(jī)制，除了循環(huán)去發(fā)消息還有什么方式？如何優(yōu)化？》

《網(wǎng)易云信技術(shù)分享：IM中的萬人群聊技術(shù)方案實(shí)踐總結(jié)》

3.2 歷史消息的架構(gòu)設(shè)計(jì)思路

釘釘中的歷史消息是可回溯的。在 ToB 場景下，數(shù)據(jù)屬于企業(yè)的資產(chǎn)。企業(yè)有需求查看歷史消息，因?yàn)樗顷P(guān)鍵的溝通信息。

3.2.1）首先是既省流量，又不遺漏的歷史消息回溯協(xié)議：最近的消息通過同步協(xié)議推送到達(dá)客戶端本地。而歷史的消息，服務(wù)端不曾推送，客戶端本地沒有入庫。在用戶進(jìn)入會話時(shí)，如果客戶端發(fā)現(xiàn)本地消息不足，自動從服務(wù)端拉取不足的歷史消息。采用這種推拉結(jié)合的協(xié)議，保證了消息不管多么久遠(yuǎn)，都可以毫無遺漏的從服務(wù)端同步下來。

3.2.2）然后是低成本的歷史消息存儲架構(gòu)：消息具有典型的冷熱屬性: 用戶訪問的絕大部分都是最近的數(shù)據(jù)。我們自研了一套冷熱分離架構(gòu)，在冷庫使用低成本高壓縮率的存儲引擎，大幅下降存儲成本。

3.2.3）最后是達(dá)到金融級安全保障的歷史消息加密：為了保證歷史消息的安全性，我們在全鏈路使用金融級的加密算法，不留死角，確保沒有任何人可以非法獲取歷史消息。

3.3 場景化

ToC IM 產(chǎn)品的場景都比較通用。比如微信群，每個(gè)人能夠使用的功能集合是一樣的，大家進(jìn)群聊天，都可以改群昵稱，群名稱。

釘釘則是面向場景打造極致體驗(yàn)。以班級群為例，班級群里面沒有用戶的概念，變成了老師、家長、學(xué)生。進(jìn)群后家長無法修改群昵稱，完全由系統(tǒng)設(shè)置，比如"小明爸爸"。所以，班級群的進(jìn)群路徑、群管理、昵稱展示，都是面向家校溝通場景的特殊優(yōu)化，目的是做到家校場景的極致用戶體驗(yàn)。

這給技術(shù)團(tuán)隊(duì)帶來兩方面的挑戰(zhàn)。一方面是系統(tǒng)模型必須做到可擴(kuò)展性強(qiáng)，足夠靈活，能夠快速地支持業(yè)務(wù)場景化的需求；另一方面是在維持業(yè)務(wù)快速迭代的情況下，保持核心 IM 系統(tǒng)的高可用性。因此釘釘?shù)募軜?gòu)必須做到同時(shí)滿足這兩點(diǎn)需求。

還是以班級群為例。它使用小程序開發(fā)，不需要發(fā)版就可以做 bugfix、實(shí)現(xiàn)業(yè)務(wù)需求。同時(shí)服務(wù)端切分為了業(yè)務(wù)層和 IMCore 層。業(yè)務(wù)層做靈活多變的業(yè)務(wù)邏輯，迭代速度快。IMCore 層提供基礎(chǔ)能力和擴(kuò)展點(diǎn)，改動頻次低，主要是提供高穩(wěn)定性和單元化能力。服務(wù)分層后，基本做到了新需求不改動 IMCore 層。迭代速度快，系統(tǒng)穩(wěn)定性強(qiáng)，達(dá)到了業(yè)務(wù)、技術(shù)皆大歡喜的局面。

3.4 單元化

單元化在釘釘有多層需求。

3.4.1）高可用：釘釘要保證 vip 用戶在地域?yàn)?zāi)難的情況下可用。因此我們設(shè)計(jì)了一套基于單元化的異地容災(zāi)方案。當(dāng)中心宕機(jī)，兩分鐘內(nèi)一鍵把 vip 用戶調(diào)度到容災(zāi)單元，確保用戶能夠正常使用 IM 基本功能。

3.4.2）國際化：海外地區(qū)的對于數(shù)據(jù)有合規(guī)的要求。同時(shí)，釘釘在當(dāng)?shù)夭渴饝?yīng)用，也給海外用戶提供了更流暢的用戶體驗(yàn)。

3.4.3）支持大客戶及特殊行業(yè)：釘釘今天不僅承接中小企業(yè)的溝通辦公，也承接不少政務(wù)大客戶。他們對釘釘?shù)脑V求是具備專有云部署能力。

3.4.4）容量：隨著業(yè)務(wù)發(fā)展，所有流量在中心處理不可擴(kuò)展。把流量分散到多地域是一個(gè)必然選擇。

釘釘通過一套代碼部署，一套運(yùn)維體系實(shí)現(xiàn)單元化，滿足了以上多層次的需求。我們開發(fā)了單元化基礎(chǔ)組件，動態(tài)路由，業(yè)務(wù)層數(shù)據(jù)同步組件等一系列基礎(chǔ)設(shè)施，可以將釘釘部署在任何一個(gè)國家或地區(qū)，甚至客戶的自有機(jī)房。

4、釘釘?shù)母呖捎谩踩匀绾伪ＷC

 

企業(yè)級 IM 產(chǎn)品對于高可用和安全性的要求遠(yuǎn)高于 ToC 場景下的 IM 產(chǎn)品。一旦釘釘?shù)南l(fā)不出去或者收消息出現(xiàn)延遲，就會大面積影響企業(yè)的核心業(yè)務(wù)運(yùn)轉(zhuǎn)。同時(shí)，聊天數(shù)據(jù)長期保存，歷史消息可實(shí)時(shí)回溯，一方面對數(shù)據(jù)存儲提出了更高要求，另一方面也對數(shù)據(jù)的安全性帶來了新的挑戰(zhàn)。

釘釘在高可用性方面的努力，主要包括以下幾個(gè)方面：

1）高可用架構(gòu)：通過異地容災(zāi)、中間件冗余、存儲冗余，在架構(gòu)上避免單個(gè)中間件、存儲或者地域的災(zāi)難對系統(tǒng)可用性產(chǎn)生影響。比如今天 IM 依賴的 DB 宕機(jī)，并不會影響用戶的消息收發(fā)成功率；

2）變更管理：核心系統(tǒng)控制發(fā)布頻率，每一次發(fā)布必須 checklist 校驗(yàn)。發(fā)布可灰度、可監(jiān)控、可回滾，控制問題引入的影響面；

3）持續(xù)精進(jìn)：通常大的故障都是由小的隱患累計(jì)產(chǎn)生。如何發(fā)現(xiàn)并解決系統(tǒng)中的隱患？得有機(jī)制性的解決方案。我們每天投入專人，去發(fā)現(xiàn)系統(tǒng)中的穩(wěn)定性問題。常年累計(jì)下來，系統(tǒng)的健康度越來越高。

作為企業(yè)級應(yīng)用，安全是釘釘?shù)牧⑸碇荆彩瞧髽I(yè)客戶最敏感的關(guān)注點(diǎn)。

釘釘在數(shù)據(jù)安全方面的努力，主要包括以下幾個(gè)方面：

1）釘釘 IM 擁有高強(qiáng)度的鏈路加密，達(dá)到銀行級數(shù)據(jù)加密級別：IM 在全鏈路上都是加密的，因?yàn)榧词褂幸粋€(gè)點(diǎn)疏漏，數(shù)據(jù)就可能泄漏。所以在客戶端、長連接、mq、存儲、業(yè)務(wù)上下游，都做了加密。在接口訪問層面，我們也有完善的鑒權(quán)、訪問控制，確保數(shù)據(jù)不會被非法使用。

2）數(shù)據(jù)安全上，企業(yè)還可以選擇第三方加密：聊天數(shù)據(jù)同時(shí)被釘釘、三方雙重加密，數(shù)據(jù)只屬于企業(yè)。

3）長期的安全技術(shù)沉淀：釘釘背后有阿里集團(tuán)數(shù)千名工程師建立的安全保障機(jī)制。我們每一次發(fā)布都會有代碼安全掃描，一般的水平權(quán)限漏洞都可以在掃描中發(fā)現(xiàn)，用工具把大部分漏洞扼殺在上線前。同時(shí)自主研發(fā)了動態(tài)防入侵系統(tǒng)，實(shí)時(shí)監(jiān)測平臺的安全狀況，對于入侵事件具備分鐘級快速發(fā)現(xiàn)能力及進(jìn)行事件的快速響應(yīng)、止血與溯源能力。

4）攻防演練：平時(shí)多演練，戰(zhàn)時(shí)不流血。我們有專門的安全團(tuán)隊(duì)對系統(tǒng)進(jìn)行攻防演練，紅藍(lán)對抗，及時(shí)發(fā)現(xiàn)潛在的安全問題，提升入侵檢測及安全應(yīng)急響應(yīng)能力。

PS：以上有自high的成分存在，各位選擇性閱讀即可。

5、釘釘在存儲等方面的創(chuàng)新

不同于傳統(tǒng) IM，釘釘在存儲方面的業(yè)務(wù)需求與技術(shù)實(shí)現(xiàn)都有新的要求。

由于消息需要長期保存，釘釘做存儲的一個(gè)重點(diǎn)必然是降低長期數(shù)據(jù)的存儲成本。釘釘在其中做了很多事情，比如冷熱分離，讀寫擴(kuò)散，消息清理。沒有成本上的優(yōu)化，業(yè)務(wù)的增長帶來的是不可持續(xù)的成本增長，這是無法接受的。

另一點(diǎn)是存儲的單元化。一般 ToC 產(chǎn)品的單元化主要是由國際化驅(qū)動。海外市場有合規(guī)的要求，消息必須存儲在當(dāng)?shù)亍τ卺斸攣碚f，除了國際化的需求，也有組織專有部署的需求，因此釘釘?shù)拇鎯軜?gòu)上也支持單元化部署，以及多單元的互通。

除了業(yè)務(wù)場景變化給技術(shù)帶來的新要求，技術(shù)同學(xué)也會有一些 geek 的想法，從而反哺業(yè)務(wù)。比如釘釘?shù)牧奶鞕C(jī)器人，就是 IM 技術(shù)同學(xué)自發(fā)發(fā)起的。最初，很難說清楚聊天機(jī)器人對業(yè)務(wù)的貢獻(xiàn)，因此技術(shù)同學(xué)就自己偷偷把 MVP 做出來。做出來以后，慢慢發(fā)現(xiàn)確實(shí)在工作中很有價(jià)值，包括 IM 的系統(tǒng)報(bào)警、用戶 VOC 問題解決率提醒，命令行重啟單臺機(jī)器等等場景，用聊天機(jī)器人非常方便，很好的提高了工作效率。所以最終決定開放給用戶，也受到了用戶的廣泛好評。

PS：本節(jié)內(nèi)容有點(diǎn)水，各位選擇閱讀性即可。

以下有關(guān)IM存儲設(shè)計(jì)方面的文章也值得一讀：

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》

《IM群聊消息究竟是存1份(即擴(kuò)散讀)還是存多份(即擴(kuò)散寫)？》

《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時(shí)音視頻聊天背后的技術(shù)解密》

《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實(shí)戰(zhàn)》

《微信后臺基于時(shí)間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計(jì)實(shí)踐》

《微信海量用戶背后的后臺系統(tǒng)存儲架構(gòu)(視頻+PPT) [附件下載]》

《微信朋友圈海量技術(shù)之道PPT [附件下載]》

《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲層架構(gòu)演進(jìn)實(shí)踐》

附錄：更多即時(shí)通訊大廠的技術(shù)分享

[1] 來自阿里巴巴的技術(shù)文章：

《阿里釘釘技術(shù)分享：企業(yè)級IM之王——釘釘在后端架構(gòu)上的過人之處》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》

《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫技術(shù)方案的10年變遷史》 

《阿里技術(shù)分享：阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路》 

《來自阿里OpenIM：打造安全可靠即時(shí)通訊服務(wù)的技術(shù)實(shí)踐分享》 

《釘釘——基于IM技術(shù)的新一代企業(yè)OA平臺的技術(shù)挑戰(zhàn)(視頻+PPT) [附件下載]》 

《阿里技術(shù)結(jié)晶：《阿里巴巴Java開發(fā)手冊(規(guī)約)-華山版》[附件下載]》 

《重磅發(fā)布：《阿里巴巴Android開發(fā)手冊(規(guī)約)》[附件下載]》 

《作者談《阿里巴巴Java開發(fā)手冊(規(guī)約)》背后的故事》 

《《阿里巴巴Android開發(fā)手冊(規(guī)約)》背后的故事》 

《干了這碗雞湯：從理發(fā)店小弟到阿里P10技術(shù)大牛》 

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

[2] QQ、微信團(tuán)隊(duì)原創(chuàng)技術(shù)文章：

《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》

《微信團(tuán)隊(duì)分享：微信移動端的全文檢索多音字問題解決方案》

《騰訊技術(shù)分享：Android版手機(jī)QQ的緩存監(jiān)控與優(yōu)化實(shí)踐》

《微信團(tuán)隊(duì)分享：iOS版微信的高性能通用key-value組件技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)分享：iOS版微信是如何防止特殊字符導(dǎo)致的炸群、APP崩潰的？》

《騰訊技術(shù)分享：Android手Q的線程死鎖監(jiān)控系統(tǒng)技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)原創(chuàng)分享：iOS版微信的內(nèi)存監(jiān)控系統(tǒng)技術(shù)實(shí)踐》

《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》

《iOS后臺喚醒實(shí)戰(zhàn)：微信收款到賬語音提醒技術(shù)總結(jié)》

《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》

《微信團(tuán)隊(duì)分享：視頻圖像的超分辨率技術(shù)原理和應(yīng)用場景》

《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時(shí)音視頻聊天背后的技術(shù)解密》

《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（上篇）》

《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（下篇）》

《騰訊團(tuán)隊(duì)分享：手機(jī)QQ中的人臉識別酷炫動畫效果實(shí)現(xiàn)詳解》

《騰訊團(tuán)隊(duì)分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》

《微信團(tuán)隊(duì)分享：微信Android版小視頻編碼填過的那些坑》 

《微信手機(jī)端的本地?cái)?shù)據(jù)全文檢索優(yōu)化之路》 

《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實(shí)戰(zhàn)》

《微信團(tuán)隊(duì)披露：微信界面卡死超級bug“15。。。。”的來龍去脈》

《QQ 18年：解密8億月活的QQ后臺服務(wù)接口隔離技術(shù)》

《月活8.89億的超級IM微信是如何進(jìn)行Android端兼容測試的》

《以手機(jī)QQ為例探討移動端IM中的“輕應(yīng)用”》

《一篇文章get微信開源移動端數(shù)據(jù)庫組件WCDB的一切！》

《微信客戶端團(tuán)隊(duì)負(fù)責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化》

《微信后臺基于時(shí)間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計(jì)實(shí)踐》

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信的臃腫之困與模塊化實(shí)踐之路》

《微信后臺團(tuán)隊(duì)：微信后臺異步消息隊(duì)列的優(yōu)化升級實(shí)踐分享》

《微信團(tuán)隊(duì)原創(chuàng)分享：微信客戶端SQLite數(shù)據(jù)庫損壞修復(fù)實(shí)踐》 

《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》 

《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（下篇）》 

《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（上篇）》 

《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫，即將開源》 

《如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》 

《開源libco庫：單機(jī)千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》 

《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺保活實(shí)戰(zhàn)分享(進(jìn)程保活篇)》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺保活實(shí)戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》 

《Android版微信從300KB到30MB的技術(shù)演進(jìn)(PPT講稿) [附件下載]》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信從300KB到30MB的技術(shù)演進(jìn)》 

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(PPT講稿) [附件下載]》 

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》

《微信海量用戶背后的后臺系統(tǒng)存儲架構(gòu)(視頻+PPT) [附件下載]》

《微信異步化改造實(shí)踐：8億月活、單機(jī)千萬連接背后的后臺解決方案》 

《微信朋友圈海量技術(shù)之道PPT [附件下載]》 

《微信對網(wǎng)絡(luò)影響的技術(shù)試驗(yàn)及分析（論文全文）》 

《一份微信后臺技術(shù)架構(gòu)的總結(jié)性筆記》 

《架構(gòu)之道：3個(gè)程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》 

《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》

《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（二）》 

《微信團(tuán)隊(duì)原創(chuàng)分享：Android內(nèi)存泄漏監(jiān)控和優(yōu)化技巧總結(jié)》 

《全面總結(jié)iOS版微信升級iOS9遇到的各種“坑”》 

《微信團(tuán)隊(duì)原創(chuàng)資源混淆工具：讓你的APK立減1M》 

《微信團(tuán)隊(duì)原創(chuàng)Android資源混淆工具：AndResGuard [有源碼]》 

《Android版微信安裝包“減肥”實(shí)戰(zhàn)記錄》 

《iOS版微信安裝包“減肥”實(shí)戰(zhàn)記錄》 

《移動端IM實(shí)踐：iOS版微信界面卡頓監(jiān)測方案》 

《微信“紅包照片”背后的技術(shù)難題》 

《移動端IM實(shí)踐：iOS版微信小視頻功能技術(shù)方案實(shí)錄》 

《移動端IM實(shí)踐：Android版微信如何大幅提升交互性能（一）》

《移動端IM實(shí)踐：Android版微信如何大幅提升交互性能（二）》

《移動端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》 

《移動端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》 

《移動端IM實(shí)踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》

《移動端IM實(shí)踐：iOS版微信的多設(shè)備字體適配方案探討》 

《信鴿團(tuán)隊(duì)原創(chuàng)：一起走過 iOS10 上消息推送(APNS)的坑》

《騰訊信鴿技術(shù)分享：百億級實(shí)時(shí)消息推送的實(shí)戰(zhàn)經(jīng)驗(yàn)》

《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》

《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》

《騰訊TEG團(tuán)隊(duì)原創(chuàng)：基于MySQL的分布式數(shù)據(jù)庫TDSQL十年鍛造經(jīng)驗(yàn)分享》

《微信多媒體團(tuán)隊(duì)訪談：音視頻開發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》

《了解iOS消息推送一文就夠：史上最全iOS Push技術(shù)詳解》

《騰訊技術(shù)分享：微信小程序音視頻技術(shù)背后的故事》

《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》

《微信多媒體團(tuán)隊(duì)梁俊斌訪談：聊一聊我所了解的音視頻技術(shù)》

《騰訊音視頻實(shí)驗(yàn)室：使用AI黑科技實(shí)現(xiàn)超低碼率的高清實(shí)時(shí)視頻聊天》

《騰訊技術(shù)分享：微信小程序音視頻與WebRTC互通的技術(shù)思路和實(shí)踐》

《手把手教你讀取Android版微信和手Q的聊天記錄(僅作技術(shù)研究學(xué)習(xí))》

《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實(shí)踐（算法原理篇）》

《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實(shí)踐（容災(zāi)方案篇）》

《騰訊技術(shù)分享：GIF動圖技術(shù)詳解及手機(jī)QQ動態(tài)表情壓縮技術(shù)實(shí)踐》

《微信團(tuán)隊(duì)分享：Kotlin漸被認(rèn)可，Android版微信的技術(shù)嘗鮮之旅》

《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》

《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》

《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》

《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對高并發(fā)的》

《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的》

《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲層架構(gòu)演進(jìn)實(shí)踐》

《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運(yùn)維、架構(gòu)等》

《QQ設(shè)計(jì)團(tuán)隊(duì)分享：新版 QQ 8.0 語音消息改版背后的功能設(shè)計(jì)思路》

>> 更多同類文章 ……

[3] 有關(guān)QQ、微信的技術(shù)故事：

《技術(shù)往事：微信估值已超5千億，雷軍曾有機(jī)會收編張小龍及其Foxmail》

《QQ和微信兇猛成長的背后：騰訊網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的這些年》

《閑話即時(shí)通訊：騰訊的成長史本質(zhì)就是一部QQ成長史》

《2017微信數(shù)據(jù)報(bào)告：日活躍用戶達(dá)9億、日發(fā)消息380億條》

《騰訊開發(fā)微信花了多少錢？技術(shù)難度真這么大？難在哪？》

《技術(shù)往事：創(chuàng)業(yè)初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》 

《技術(shù)往事：史上最全QQ圖標(biāo)變遷過程，追尋IM巨人的演進(jìn)歷史》 

《技術(shù)往事：“QQ群”和“微信紅包”是怎么來的？》 

《開發(fā)往事：深度講述2010到2015，微信一路風(fēng)雨的背后》 

《開發(fā)往事：微信千年不變的那張閃屏圖片的由來》 

《開發(fā)往事：記錄微信3.0版背后的故事（距微信1.0發(fā)布9個(gè)月時(shí)）》 

《一個(gè)微信實(shí)習(xí)生自述：我眼中的微信開發(fā)團(tuán)隊(duì)》

《首次揭秘：QQ實(shí)時(shí)視頻聊天背后的神秘組織》

《為什么說即時(shí)通訊社交APP創(chuàng)業(yè)就是一個(gè)坑？》

《微信七年回顧：歷經(jīng)多少質(zhì)疑和差評，才配擁有今天的強(qiáng)大》

《前創(chuàng)始團(tuán)隊(duì)成員分享：盤點(diǎn)微信的前世今生——微信成功的必然和偶然》

《即時(shí)通訊創(chuàng)業(yè)必讀：解密微信的產(chǎn)品定位、創(chuàng)新思維、設(shè)計(jì)法則等》

《QQ的成功，遠(yuǎn)沒有你想象的那么順利和輕松》

《QQ現(xiàn)狀深度剖析：你還認(rèn)為QQ已經(jīng)被微信打敗了嗎？》

《[技術(shù)腦洞] 如果把14億中國人拉到一個(gè)微信群里技術(shù)上能實(shí)現(xiàn)嗎？》 

《QQ和微信止步不前，意味著即時(shí)通訊社交應(yīng)用創(chuàng)業(yè)的第2春已來？》

《那些年微信開發(fā)過的雞肋功能，及其帶給我們的思考》

《讀懂微信：從1.0到7.0版本，一個(gè)主流IM社交工具的進(jìn)化史》

《同為IM社交產(chǎn)品中的王者，QQ與微信到底有什么區(qū)別》

《還原真實(shí)的騰訊：從最不被看好，到即時(shí)通訊巨頭的草根創(chuàng)業(yè)史》

《QQ設(shè)計(jì)團(tuán)隊(duì)分享：新版 QQ 8.0 語音消息改版背后的功能設(shè)計(jì)思路》

《社交應(yīng)用教父級人物的張小龍和馬化騰的同與不同》

《專訪馬化騰：首次開談個(gè)人經(jīng)歷、管理心得、技術(shù)創(chuàng)新、微信的誕生等》

《一文讀懂微信之父張小龍：失敗天才、顛覆者、獨(dú)裁者、人性操控師》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-2848-1-1.html）