阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处

时间:2022-04-17 11:28:50

本文引用了唐小智发表于InfoQ公众号上的“钉钉企业级IM存储架构创新之道”一文的部分内容,收录时有改动,感谢原作者的无私分享。

1、引言

业界的 IM 产品在功能上同质化较高,而企业级的 IM 产品对于高可用、安全性又有更高的要求,如何打造具备差异化的产品,又在高可用、安全性、数据一致性等方面具备较高的品质,是企业级 IM 产品成功的关键。钉钉在过去短短几年时间里,用户数已破 2 亿,企业组织数破千万,钉钉是在规划企业级 IM 产品的架构上有何过人之处?本文将围绕这个话题进行展开。

阿里钉钉技术分享:企业级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王者——钉钉在后端架构上的过人之处

(本图引用自:《钉钉——基于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王者——钉钉在后端架构上的过人之处

企业级 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