IM即时通讯钉钉技术：企业IM钉钉在后端架构上的优越之处

行业内的 IM产品在功能上具有较高的同质化，而企业级 IM产品对可用性和安全性的要求也更高，如何打造异化程度较低的产品，同时在可用性、安全性、数据一致性等方面具有较高的质量，是企业 IM产品成功的关键。在过去的短短的几年里，用户数已经达到了2万亿，企业组织数量已经达到了千万，钉钉是如何在构架企业级 IM产品的？这篇文章将围绕这个主题。

它

读解：本文适合具有一定 IM后端架构设计经验的开发者阅读，也许是出于商业产品技术秘密的考虑，分享者对本次分享的内容有所保留，由于阿里对技术上的内容分享做得很少，所以本文内容虽然不够全面，但仍然值得一读。

二是相关文章

优化企业微信客户端中组织架构数据同步更新方案实战

浅谈现代 IM系统中聊天消息的同步与存储方案

以 IM技术为基础的新一代企业级 OA平台(视频+ PPT)[附件下载](*推荐)

三，不同的场景，固定结构的设计不同

作为一个 ToB产品，业务场景与 ToC的 IM产品有很大的不同，而且在体系结构上各有侧重。

这一系列的技术从阿里巴巴集团继承而来。阿里有“大中台，小前台”的组织策略，所以钉在大框架上的是复用集团的能力，包括集团中间件，存储引擎，微服务框架等等。此外，还将重点放在了核心能力的研发上，如： IM核心系统、系统单一、音视频通信、弱网优化、图片收发极致体验等。

三万五千人代表大会的结构设计思想

它

(本文引用自：《钉钉——基于 IM技术的新一代企业 OA平台的技术挑战(视频+ PPT)》)

其中，企业组织结构与 IM的组织结构相对应，形成了数量庞大的超级组织。与500个小组的人数上限相比，支持万个小组的钉钉大大增加了接触小组的人数。

这么多的万人聚集给即时通讯系统的流量带来巨大冲击。节日期间，尤其是元旦、春节或双11等大型活动期间，管理层和员工大量高频互动，洪峰瞬间流过 IM系统，对系统提出了挑战。

为了支持这个超级群体，我们做了下面的多点优化。

3.1.1)减少储存扩散：

IM最初使用的是写扩散模型，1万人群发一条消息写1万次消息收件箱。通过对扩散模型的优化，使消息只需写一次消息收件箱，扩散量降至万分之一。

3.1.2)智能流量限制：

节庆场景下，部分群发信息频繁，可能会超出系统总容量，影响 IM系统的稳定。若为每组设置一个较低的发送阈值，系统就不能充分发挥功能，从而提供足够流畅的用户体验。为了解决这一问题，本文设计了一种智能限流方法，当总流量超过系统阈值时，会自动根据当时情况对大量具有较高发送率的群组进行限制。

3.1.3)万群成员多层缓存：

通过客户端，服务端，我们建立了多层成员缓存。

一个是用户打开 at列表时，可以看到群组成员列表。由于群组成员数量增加，开放群组成员列表的延迟提升明显，用户可以感觉到长达几十秒的卡顿。在客户端缓存增加之后，用户在群中输入一个@立刻应成员列表，即使群中有数万人。另外一方面，可以避免大量群成员对数据库的读写压力。若直接压入 DB层，万行记录的扩散量太大，容易引起热源，影响系统稳定。

3.1.4)确保端对端体验：

客户机定期进行极限压力测试，在大规模刷屏群发短信的情况下，保证用户体验流畅不卡顿。

关于群聊的更多架构设计文章：

怎样保证即时通讯信息的“顺序”和“一致性”？在即时通讯单人聊天和群聊中，状态同步应该使用“推”还是“拉”？即时通讯群聊消息这么复杂，怎么保证不丢不重？“微信后台团队：微信后台异步消息队列优化升级实践分享”“移动端 IM群组消息推送如何保证效率、实时？”“现代 IM系统中聊天消息的同步与存储方案”的讨论“IM群聊天消息排序混乱问题的讨论”“IM群聊天消息已读回执功能如何实现？”即时通讯群聊信息到底是储存1 (即扩散读)或多储存(即扩散写)？“高可用、易扩展、高并发的一整套 IM群聊，单聊的架构设计实践”“IM群聊机制，除了循环去发信息之外，还有什么其他方法？”怎样优化？“网易云信技术共享： IM技术万人群聊技术方案实践总结”

3.2历史信息的结构设计思想

在钉子上的历史信息可以被追溯。对于 ToB场景，数据是企业的一种资产。公司需要查看历史信息，因为它是关键的通信信息。

3.2.1)首先是既节省通信量，又不遗漏历史消息回溯协议：通过同步协议，最新消息被推送到客户机本地。而且消息有历史，服务端没有推送，客户端本地没有入库。当用户进入会话时，如果客户端发现本地消息不充分，则会自动从服务端拉取历史信息。使用此推拉式组合的协议，可确保消息无论有多长时间，都能不遗漏地从服务端同步下来。

3.2.2)然后是低成本的历史消息存储架构：消息具有典型的冷热性：大多数用户访问的是最新数据。本公司自主研发了一套冷热分离结构，采用低成本高收缩的冷库储存引擎，显著降低储存成本。

3.2.3)最终实现历史信息加密，以实现金融级别的安全：为了保证历史信息的安全，我们在全链路上使用金融级别的加密算法，确保任何人都不能非法获取历史信息。

3.情景化

所有 ToCIM产品的场景都是比较通用的。就像微信群一样，每个人都能用一套功能集合，大家进群聊天，就可以改成群昵称，群名。

定位就是为场景打造极致的体验。就拿课堂群来说，这个课堂群没有用户的概念，变成了老师，家长，学生。家长进入群后不能修改群名，完全由系统设置，如“小明爸爸”。因此，班级群的进群路径，群组管理，昵称显示等，都是针对家校交流场景进行特殊的优化，目的在于达到家校场景的极致用户体验。

对技术团队来说，这有两个挑战。首先，系统模型必须具有高度的扩展性和足够的灵活性，以快速满足业务场景化的需求；其次，核心 IM系统要保持高可用性，同时保持业务的快速迭代。所以固定的体系结构必须同时满足这两个需求。

或者拿班上的人来说。该软件是用小程序开发的，无需发布就能执行 bugfix，实现业务需求。在业务层和 IMCore层之间也进行了服务端切分。商业层做的是灵活多变的商业逻辑，快速迭代。该软件核心层提供了低频变化的基本功能和扩展点，主要提供高稳定性和单元化功能。在服务分层之后，基本不改变 IMCore层的新需求。迭代率高，系统稳定性好，达到了商业、技术上的一致状态。

3.4单一体

钉子的单元化有多层需求。

3.4.1)高可用性：钉子要确保 vip用户能够应对地域灾难。为此，设计了一套基于单元化的异地容灾方案。在中央断电的两分钟内，将 vip用户一键调度到容灾单元，确保用户可以正常使用 IM的基本功能。

3.4.2)国际化：海外地区对数据有遵守规定的要求。与此同时，将应用部署到本地，也为海外用户提供了更加流畅的用户体验。

3.4.3)支持大客户和特殊行业：今天的钉子不仅承接中小企业的沟通办公室，还承接了不少政府的大客户。它们对于“钉子”的要求是拥有专有的云部署能力。

3.4.4)容量：随着业务发展，不能扩大中央处理的所有流量。将流量分散到多个地区是一种必要的选择。

通过一整套代码部署、一整套运营体系，实现了单机化，满足了上述多层需求。本公司已开发出各种基础组件，如动态路由、业务层数据同步组件等，可以部署到任何国家、地区，甚至客户自有机房。

钉子的高可用性，安全是如何保证的？

它

对于高可用性和安全性，企业级 IM产品比 ToC场景中的 IM产品更具优势。当信息发送失败或接收消息出现延迟，将会对企业的核心业务运作产生较大影响。聊天数据长期保存，历史信息可以实时回溯，一方面对数据的存储提出了更高的要求，另一方面也给数据的安全带来了新的挑战。

在高可用性方面的努力主要包括以下几个方面：

1)高可用架构：通过容灾、异地容灾、中间件冗余、存储冗余，可以避免架构上的单一中间件、存储器或地域灾难，从而影响系统的可用性。例如，现在 IM所依赖的数据库宕机不会影响用户的消息接收和发送成功率；2)变更管理：核心系统控制发布频率，每次发布都必须进行检查。释放可调、可监测、可回滚，控制问题带来的影响；3)持续改进：通常情况下，大的故障是由小的隐患累积而成。怎样找出和解决系统的隐患？必须有制度性的解决办法。我们每天都派人去找出系统的稳定性问题。年复一年累积下来，系统健康程度越来越高。

对于企业级应用来说，安全是钉钉的立身之本，也是企业客户最为关注的焦点。

为保证数据安全所作的努力，主要包括以下几个方面：

一、钉钉 IM具有高强度的链路加密，可以达到银行级数据加密级别： IM可以加密整个链路，因为即使有一点疏漏，数据也会泄露。因此客户端，长连接， mq，存储，业务上下游，都做了加密。对于界面访问，我们还拥有完善的鉴权、访问控制，保证数据不被非法使用。二、数据安全，企业也可选择第三方加密：聊天数据同时被钉钉，三方双重加密，数据只能属于企业。三是长期安全技术沉淀：阿里集团数千名工程师在钉钉背后建立了安全机制。每个版本都有代码安全扫描，一般水平权限漏洞都能在扫描中找到，使用工具可以将大多数漏洞扼杀在上线之前。并自主研发了动态防入侵系统，实时监控平台安全状态，对入侵事件具有分钟级的快速发现能力，对事件具有快速响应、止血和追踪等功能。攻防练习：平时多练习，战时不流血。公司拥有专业的安全队伍，对系统进行攻防演练、红蓝对抗，及时发现安全隐患，提升入侵检测和安全应急响应能力。

注：以上所说的自上而下成分都存在，大家可以选择性地阅读。

第五，钉钉在存储等领域的创新

与传统 IM不同的是，钉钉对存储的业务需求和技术实现都有了新的要求。

因为信息需要长时间的保存，所以固定存储的一个重点就是减少长时间数据的存储成本。这里面有很多东西是需要做的，比如冷热分离、读写扩散、消息清理。如果不进行成本优化，就不能接受业务增长所带来的成本增长。

还有一点就是存储的单元化。通常， ToC产品的单一性主要受国际化驱动。国外市场有法规要求，信息必须储存在本地。就钉钉而言，除了国际化需求外，还需要组织专有部署，因此钉钉还在存储架构上支持单元化部署和多单元互通。

除商业场景的改变对技术提出了新的要求外，技术同学还会有一些 geek的想法来反哺商业。例如钉子聊天机器人，就是 IM同学自发发起的。起初，很难说清楚聊天机器人对企业的贡献，所以技术型同学自己偷偷做 MVP。制作完成后，慢慢发现真的在工作中很有价值，包括 IM的系统报警，用户 VOC问题解决速度提醒，

[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 语音消息改版背后的功能设计思路》
《社交应用教父级人物的张小龙和马化腾的同与不同》
《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》
《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》
>> 更多同类文章 ……