本文引用了唐小智發表于InfoQ公眾號上的“釘釘企業級IM存儲架構創新之道”一文的部分內容，收錄時有改動，感謝原作者的無私分享。

1、引言

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

 

閱讀提示：本文適合有一定IM后端架構設計經驗的開發者閱讀，或許出于商業產品技術秘密的考慮，分享者在本次所分享的內容上有所保留，鑒于阿里對于釘釘在技術上的內容分享做的非常少，所以本文雖然內容不夠全面，但仍然值得一讀。

學習交流：

- 即時通訊/推送技術開發交流5群：215477170 [推薦]

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

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

2、相關文章

《企業微信客戶端中組織架構數據的同步更新方案優化實戰》

《現代IM系統中聊天消息的同步和存儲方案探討》

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

3、不同的場景，釘釘的架構思路不同

釘釘的技術棧繼承自阿里巴巴集團。阿里有著”大中臺，小前臺“的組織戰略，所以釘釘在大的框架上是復用集團的能力，包括集團的中間件、存儲引擎、微服務框架等。在此之上，釘釘聚焦在核心能力的研發，比如：IM 核心系統、系統單元化、音視頻通訊，弱網優化，圖片收發極致體驗等等。

釘釘作為 ToB 產品，業務場景跟 ToC 的 IM 產品有很大區別，架構上也各有側重。

3.1 萬人大群的架構設計思路

 

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

在釘釘里，企業的組織關系映射到 IM 的群，產生了為數眾多的超級大群。和 500 群人數上限相比，釘釘支持萬人大群，大幅提升了群的觸達人數。

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

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

3.1.1）降低存儲擴散量：

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

3.1.2）智能限流：

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

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

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

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

3.1.4）端到端的體驗保證：

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

更多有關群聊的架構設計文章：

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

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

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

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

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

《現代IM系統中聊天消息的同步和存儲方案探討》

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

《IM群聊消息的已讀回執功能該怎么實現？》

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

《一套高可用、易伸縮、高并發的IM群聊、單聊架構方案設計實踐》

《IM群聊機制，除了循環去發消息還有什么方式？如何優化？》

《網易云信技術分享：IM中的萬人群聊技術方案實踐總結》

3.2 歷史消息的架構設計思路

釘釘中的歷史消息是可回溯的。在 ToB 場景下，數據屬于企業的資產。企業有需求查看歷史消息，因為它是關鍵的溝通信息。

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

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

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

3.3 場景化

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

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

這給技術團隊帶來兩方面的挑戰。一方面是系統模型必須做到可擴展性強，足夠靈活，能夠快速地支持業務場景化的需求；另一方面是在維持業務快速迭代的情況下，保持核心 IM 系統的高可用性。因此釘釘的架構必須做到同時滿足這兩點需求。

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

3.4 單元化

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

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

3.4.2）國際化：海外地區的對于數據有合規的要求。同時，釘釘在當地部署應用，也給海外用戶提供了更流暢的用戶體驗。

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

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

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

4、釘釘的高可用、安全性如何保證

 

企業級 IM 產品對于高可用和安全性的要求遠高于 ToC 場景下的 IM 產品。一旦釘釘的消息發不出去或者收消息出現延遲，就會大面積影響企業的核心業務運轉。同時，聊天數據長期保存，歷史消息可實時回溯，一方面對數據存儲提出了更高要求，另一方面也對數據的安全性帶來了新的挑戰。

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

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

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

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

作為企業級應用，安全是釘釘的立身之本，也是企業客戶最敏感的關注點。

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

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

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

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

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

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

5、釘釘在存儲等方面的創新

不同于傳統 IM，釘釘在存儲方面的業務需求與技術實現都有新的要求。

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

另一點是存儲的單元化。一般 ToC 產品的單元化主要是由國際化驅動。海外市場有合規的要求，消息必須存儲在當地。對于釘釘來說，除了國際化的需求，也有組織專有部署的需求，因此釘釘的存儲架構上也支持單元化部署，以及多單元的互通。

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

PS：本節內容有點水，各位選擇閱讀性即可。

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

《現代IM系統中聊天消息的同步和存儲方案探討》

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

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

《企業微信客戶端中組織架構數據的同步更新方案優化實戰》

《微信后臺基于時間序的海量數據冷熱分級架構設計實踐》

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

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

《社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》

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

[1] 來自阿里巴巴的技術文章：

《阿里釘釘技術分享：企業級IM之王——釘釘在后端架構上的過人之處》

《現代IM系統中聊天消息的同步和存儲方案探討》

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

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

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

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

《阿里技術結晶：《阿里巴巴Java開發手冊(規約)-華山版》[附件下載]》 

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

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

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

《干了這碗雞湯：從理發店小弟到阿里P10技術大牛》 

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

[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紅包技術方案——架構、技術實現等》

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

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

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

《社交軟件紅包技術解密(五)：微信紅包系統是如何實現高可用性的》

《社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》

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

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

>> 更多同類文章 ……

[3] 有關QQ、微信的技術故事：

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

《QQ和微信兇猛成長的背后：騰訊網絡基礎架構的這些年》

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

《2017微信數據報告：日活躍用戶達9億、日發消息380億條》

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

《技術往事：創業初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》 

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

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

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

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

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

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

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

《為什么說即時通訊社交APP創業就是一個坑？》

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

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

《即時通訊創業必讀：解密微信的產品定位、創新思維、設計法則等》

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

《QQ現狀深度剖析：你還認為QQ已經被微信打敗了嗎？》

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

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

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

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

《同為IM社交產品中的王者，QQ與微信到底有什么區別》

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

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

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

《專訪馬化騰：首次開談個人經歷、管理心得、技術創新、微信的誕生等》

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

>> 更多同類文章 ……

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