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

1、引言

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

 

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

學習交流：

- 即時通訊/推送技術(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)化實戰(zhàn)》

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

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

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

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

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

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

 

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

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

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

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

3.1.1）降低存儲擴散量：

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

3.1.2）智能限流：

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

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

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

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

3.1.4）端到端的體驗保證：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.3 場景化

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

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

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

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

3.4 單元化

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

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

3.4.2）國際化：海外地區(qū)的對于數(shù)據(jù)有合規(guī)的要求。同時，釘釘在當?shù)夭渴饝茫步o海外用戶提供了更流暢的用戶體驗。

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《來自阿里OpenIM：打造安全可靠即時通訊服務的技術(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、微信團隊原創(chuàng)技術(shù)文章：

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

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

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

《微信團隊分享：微信移動端的全文檢索多音字問題解決方案》

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

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

《微信團隊分享：iOS版微信是如何防止特殊字符導致的炸群、APP崩潰的？》

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

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

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

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

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

《微信團隊分享：視頻圖像的超分辨率技術(shù)原理和應用場景》

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

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

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

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

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

《微信團隊分享：微信Android版小視頻編碼填過的那些坑》 

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

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

《微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》

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

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

《以手機QQ為例探討移動端IM中的“輕應用”》

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《微信團隊原創(chuàng)分享：Android版微信后臺保活實戰(zhàn)分享(網(wǎng)絡保活篇)》 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《社交軟件紅包技術(shù)解密(九)：談談手Q紅包的功能邏輯、容災、運維、架構(gòu)等》

《QQ設計團隊分享：新版 QQ 8.0 語音消息改版背后的功能設計思路》

>> 更多同類文章 ……

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

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

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

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

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

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

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

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

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

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

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

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

《一個微信實習生自述：我眼中的微信開發(fā)團隊》

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

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

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

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

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

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

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

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

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

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

《讀懂微信：從1.0到7.0版本，一個主流IM社交工具的進化史》

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

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

《QQ設計團隊分享：新版 QQ 8.0 語音消息改版背后的功能設計思路》

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

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

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

>> 更多同類文章 ……

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