阿里釘釘技術分享：企業級IM王者——釘釘在後端架構上的過人之處
本文引用了唐小智發表於InfoQ公衆號上的「釘釘企業級IM存儲架構創新之道」一文的部份內容，收錄時有改動，感謝原做者的無私分享。php
一、引言
業界的 IM 產品在功能上同質化較高，而企業級的 IM 產品對於高可用、安全性又有更高的要求，如何打造具有差別化的產品，又在高可用、安全性、數據一致性等方面具有較高的品質，是企業級 IM 產品成功的關鍵。釘釘在過去短短几年時間裏，用戶數已破 2 億，企業組織數破千萬，釘釘是在規劃企業級 IM 產品的架構上有何過人之處？本文將圍繞這個話題進行展開。html
閱讀提示：本文適合有必定IM後端架構設計經驗的開發者閱讀，或許出於商業產品技術祕密的考慮，分享者在本次所分享的內容上有所保留，鑑於阿里對於釘釘在技術上的內容分享作的很是少，因此本文雖然內容不夠全面，但仍然值得一讀。程序員
學習交流：算法
- 即時通信/推送技術開發交流5羣：215477170 [推薦]數據庫
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》小程序
（本文同步發佈於：http://www.52im.net/thread-2848-1-1.html）後端
二、相關文章
《企業微信客戶端中組織架構數據的同步更新方案優化實戰》微信小程序
《釘釘——基於IM技術的新一代企業OA平臺的技術挑戰(視頻+PPT) [附件下載]》 （* 推薦）安全
三、不一樣的場景，釘釘的架構思路不一樣
釘釘的技術棧繼承自阿里巴巴集團。阿里有着」大中臺，小前臺「的組織戰略，因此釘釘在大的框架上是複用集團的能力，包括集團的中間件、存儲引擎、微服務框架等。在此之上，釘釘聚焦在覈心能力的研發，好比：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羣聊消息到底是存1份(即擴散讀)仍是存多份(即擴散寫)？》
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）容量：隨着業務發展，全部流量在中心處理不可擴展。把流量分散到多地域是一個必然選擇。
釘釘經過一套代碼部署，一套運維體系實現單元化，知足了以上多層次的需求。咱們開發了單元化基礎組件，動態路由，業務層數據同步組件等一系列基礎設施，能夠將釘釘部署在任何一個國家或地區，甚至客戶的自有機房。
四、釘釘的高可用、安全性如何保證
企業級 IM 產品對於高可用和安全性的要求遠高於 ToC 場景下的 IM 產品。一旦釘釘的消息發不出去或者收消息出現延遲，就會大面積影響企業的核心業務運轉。同時，聊天數據長期保存，歷史消息可實時回溯，一方面對數據存儲提出了更高要求，另外一方面也對數據的安全性帶來了新的挑戰。
釘釘在高可用性方面的努力，主要包括如下幾個方面：
1）高可用架構：經過異地容災、中間件冗餘、存儲冗餘，在架構上避免單箇中間件、存儲或者地域的災難對系統可用性產生影響。好比今天 IM 依賴的 DB 宕機，並不會影響用戶的消息收發成功率；
2）變動管理：核心系統控制發佈頻率，每一次發佈必須 checklist 校驗。發佈可灰度、可監控、可回滾，控制問題引入的影響面；
3）持續精進：一般大的故障都是由小的隱患累計產生。如何發現並解決系統中的隱患？得有機制性的解決方案。咱們天天投入專人，去發現系統中的穩定性問題。常年累計下來，系統的健康度愈來愈高。
做爲企業級應用，安全是釘釘的立身之本，也是企業客戶最敏感的關注點。
釘釘在數據安全方面的努力，主要包括如下幾個方面：
1）釘釘 IM 擁有高強度的鏈路加密，達到銀行級數據加密級別：IM 在全鏈路上都是加密的，由於即便有一個點疏漏，數據就可能泄漏。因此在客戶端、長鏈接、mq、存儲、業務上下游，都作了加密。在接口訪問層面，咱們也有完善的鑑權、訪問控制，確保數據不會被非法使用。
2）數據安全上，企業還能夠選擇第三方加密：聊天數據同時被釘釘、三方雙重加密，數據只屬於企業。
3）長期的安全技術沉澱：釘釘背後有阿里集團數千名工程師創建的安全保障機制。咱們每一次發佈都會有代碼安全掃描，通常的水平權限漏洞均可以在掃描中發現，用工具把大部分漏洞扼殺在上線前。同時自主研發了動態防入侵系統，實時監測平臺的安全情況，對於入侵事件具有分鐘級快速發現能力及進行事件的快速響應、止血與溯源能力。
4）攻防演練：平時多演練，戰時不流血。咱們有專門的安全團隊對系統進行攻防演練，紅藍對抗，及時發現潛在的安全問題，提高入侵檢測及安全應急響應能力。
PS：以上有自high的成分存在，各位選擇性閱讀便可。
五、釘釘在存儲等方面的創新
不一樣於傳統 IM，釘釘在存儲方面的業務需求與技術實現都有新的要求。
因爲消息須要長期保存，釘釘作存儲的一個重點必然是下降長期數據的存儲成本。釘釘在其中作了不少事情，好比冷熱分離，讀寫擴散，消息清理。沒有成本上的優化，業務的增加帶來的是不可持續的成本增加，這是沒法接受的。
另外一點是存儲的單元化。通常 ToC 產品的單元化主要是由國際化驅動。海外市場有合規的要求，消息必須存儲在當地。對於釘釘來講，除了國際化的需求，也有組織專有部署的需求，所以釘釘的存儲架構上也支持單元化部署，以及多單元的互通。
除了業務場景變化給技術帶來的新要求，技術同窗也會有一些 geek 的想法，從而反哺業務。好比釘釘的聊天機器人，就是 IM 技術同窗自發發起的。最初，很難說清楚聊天機器人對業務的貢獻，所以技術同窗就本身偷偷把 MVP 作出來。作出來之後，慢慢發現確實在工做中頗有價值，包括 IM 的系統報警、用戶 VOC 問題解決率提醒，命令行重啓單臺機器等等場景，用聊天機器人很是方便，很好的提升了工做效率。因此最終決定開放給用戶，也受到了用戶的普遍好評。
PS：本節內容有點水，各位選擇閱讀性便可。
如下有關IM存儲設計方面的文章也值得一讀：
《IM羣聊消息到底是存1份(即擴散讀)仍是存多份(即擴散寫)？》
附錄：更多即時通信大廠的技術分享
[1] 來自阿里巴巴的技術文章：
《阿里釘釘技術分享：企業級IM之王——釘釘在後端架構上的過人之處》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《來自阿里OpenIM：打造安全可靠即時通信服務的技術實踐分享》
《釘釘——基於IM技術的新一代企業OA平臺的技術挑戰(視頻+PPT) [附件下載]》
《阿里技術結晶：《阿里巴巴Java開發手冊(規約)-華山版》[附件下載]》
《重磅發佈：《阿里巴巴Android開發手冊(規約)》[附件下載]》
[2] QQ、微信團隊原創技術文章：
《騰訊技術分享：騰訊是如何大幅下降帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅下降帶寬和網絡流量的(音視頻技術篇)》
《騰訊技術分享：Android版手機QQ的緩存監控與優化實踐》
《微信團隊分享：iOS版微信的高性能通用key-value組件技術實踐》
《微信團隊分享：iOS版微信是如何防止特殊字符致使的炸羣、APP崩潰的？》
《騰訊技術分享：Android手Q的線程死鎖監控系統技術實踐》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《微信團隊披露：微信界面卡死超級bug「15。。。。」的前因後果》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《微信客戶端團隊負責人技術訪談：如何着手客戶端性能監控和優化》
《微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信團隊原創分享：微信客戶端SQLite數據庫損壞修復實踐》
《騰訊原創分享(一)：如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬鏈接、支撐微信8億用戶的後臺框架基石 [源碼下載]》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信後臺保活實戰分享(進程保活篇)》
《微信團隊原創分享：Android版微信後臺保活實戰分享(網絡保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《微信海量用戶背後的後臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬鏈接背後的後臺解決方案》
《架構之道：3個程序員成就微信朋友圈日均10億發佈量[有視頻]》
《微信團隊原創分享：Android內存泄漏監控和優化技巧總結》
《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》
《移動端IM實踐：Android版微信如何大幅提高交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提高交互性能（二）》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《信鴿團隊原創：一塊兒走過 iOS10 上消息推送(APNS)的坑》
《騰訊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》
《2017微信數據報告：日活躍用戶達9億、日發消息380億條》
《技術往事：創業初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》
《技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》
《開發往事：深度講述2010到2015，微信一路風雨的背後》
《開發往事：記錄微信3.0版背後的故事（距微信1.0發佈9個月時）》
《前創始團隊成員分享：盤點微信的前世此生——微信成功的必然和偶然》
《即時通信創業必讀：解密微信的產品定位、創新思惟、設計法則等》
《[技術腦洞] 若是把14億中國人拉到一個微信羣裏技術上能實現嗎？》
《QQ和微信止步不前，意味着即時通信社交應用創業的第2春已來？》
《讀懂微信：從1.0到7.0版本，一個主流IM社交工具的進化史》
《還原真實的騰訊：從最不被看好，到即時通信巨頭的草根創業史》
《QQ設計團隊分享：新版 QQ 8.0 語音消息改版背後的功能設計思路》
《專訪馬化騰：首次開談我的經歷、管理心得、技術創新、微信的誕生等》
《一文讀懂微信之父張小龍：失敗天才、顛覆者、獨裁者、人性操控師》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-2848-1-1.html）
- 1. 阿里釘釘技術分享：企業級IM王者——釘釘在後端架構上的過人之處
- 2. 企業IM，阿里釘釘「惡」企業微信「善」？
- 3. 企業版移動端釘釘對接
- 4. 從釘釘後臺API獲取企業通信錄之後，獲取每一個人的釘釘運動步數
- 5. 釘釘四大天王
- 6. 釘釘機器人
- 7. 阿里釘釘架構師，20頁ppt講透2億用戶的釘釘系統架構實踐
- 8. 阿里釘釘VS企業微信 誰纔是企業級一哥?
- 9. 釘釘h5項目實戰|仿釘釘聊天|h5移動端釘釘案例
- 10. 使用Foxmail登錄阿里企業郵箱（釘釘郵箱）
- 更多相關文章...
- • Hibernate的快照技術 - Hibernate教程
- • XML 相關技術 - XML 教程
- • TiDB 在摩拜單車在線數據業務的應用和實踐
- • 使用阿里雲OSS+CDN部署前端頁面與加速靜態資源
-
每一个你不满意的现在，都有一个你没有努力的曾经。