行业内的 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 语音消息改版背后的功能设计思路》
《社交应用教父级人物的张小龙和马化腾的同与不同》
《专访马化腾:首次开谈个人经历、管理心得、技术创新、微信的诞生等》
《一文读懂微信之父张小龙:失败天才、颠覆者、独裁者、人性操控师》
>> 更多同类文章 ……
哇谷im_im即时通讯_私有云_公有云-哇谷云科技官网-JM沟通
IM下载体验 - 哇谷IM-企业云办公IM即时聊天社交系统-JM 沟通下载
IM功能与价格 - 哇谷IM-提供即时通讯IM开发-APP搭建私有化-公有云-私有化云-海外云搭建
新闻动态 - 哇谷IM-即时通讯热门动态博客聊天JM沟通APP
关于哇谷-哇谷IM-提供企业即时通讯IM开发-语音通话-APP搭建私有化-公有云-私有化云-海外云搭建
联系我们 - 哇谷IM-即时通讯IM私有化搭建提供接口与SDK及哇谷云服务