默認
打賞 發表評論 5
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
阿里釘釘技術分享:企業級IM王者——釘釘在后端架構上的過人之處
閱讀(9299) | 評論(5 收藏5 淘帖2 3

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


1、引言


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

阿里釘釘技術分享:企業級IM王者——釘釘在后端架構上的過人之處_timg-(3)-opti.jpg

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

2、相關文章


企業微信客戶端中組織架構數據的同步更新方案優化實戰
現代IM系統中聊天消息的同步和存儲方案探討
釘釘——基于IM技術的新一代企業OA平臺的技術挑戰(視頻+PPT) [附件下載]》 (* 推薦

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


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

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

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


阿里釘釘技術分享:企業級IM王者——釘釘在后端架構上的過人之處_11.jpg
本圖引用自:釘釘——基于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)端到端的體驗保證:

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

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


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王者——釘釘在后端架構上的過人之處_22.jpg

企業級 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存儲設計方面的文章也值得一讀:


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


[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 語音消息改版背后的功能設計思路
社交應用教父級人物的張小龍和馬化騰的同與不同
專訪馬化騰:首次開談個人經歷、管理心得、技術創新、微信的誕生等
一文讀懂微信之父張小龍:失敗天才、顛覆者、獨裁者、人性操控師
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:IM里“附近的人”功能實現原理是什么?如何高效率地實現它?下一篇:求助IM中發送者怎么監聽接收者是否在線且處于正在聊天的狀態?

本帖已收錄至以下技術專輯

推薦方案
評論 5
看到釘釘就惡心
除了討好老板
誰想用它
簽名: 周末很無聊,太熱又出不去
3 樓: inrg Lv.1 2 個月前 來自手機 | 只看該作者
有廣告嫌疑,我建議是 開源吧,還可以成為企業im的標桿,賣賣服務器 插件 服務什么的,斗不過微信的,雖然很爛,先入為主
引用:inrg 發表于 2019-12-09 11:03
有廣告嫌疑,我建議是 開源吧,還可以成為企業im的標桿,賣賣服務器 插件 服務什么的,斗不過微信的,雖然 ...

是有吹水的嫌疑,但我沒收釘釘的好處費,只是看到文章里有些地方,稍有些養分,對自已有用吸收它就好了,管它怎么吹
簽名: 每天都很累
確實學到了一些點,智能限流,推拉結合,冷熱數據分離,不過干貨太少了

簽名: now start 。。。
引用:妮子 發表于 2019-12-12 18:07
確實學到了一些點,智能限流,推拉結合,冷熱數據分離,不過干貨太少了

釘釘很少分享技術,有的看就不錯了
簽名: 每天都很累
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
股票配资平台都找股牛网