本文由网易云信资深服务端开发工程师曹佳俊分享，本文收录时有内容订正和从新排版。
1、引言
聊天室是一类十分重要的 IM 业务状态，不同于单聊和群聊，聊天室是一种大规模的实时音讯散发零碎。聊天室有多种技术实现计划，业界也有一些开源的实现，每种实现都有本人的特点和利用场景。本文将分享网易云信针对海量用户 IM 聊天室的架构设计与利用实际，心愿能带给你启发。
技术交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）
（本文已同步公布于：http://www.52im.net/thread-4404-1-1.html）
2、本文作者
曹佳俊：网易云信资深服务端开发工程师，中科院研究生毕业后退出网易，始终在网易云信负责 IM 服务器相干的开发工作。对 IM 零碎构建以及相干中间件的开发有丰盛的实战经验。
3、聊天室整体架构
首先，咱们先来看一下网易云信以后聊天室的具体技术架构，以及咱们在架构降级优化过程中做的一些事件。
如下图，是网易云信聊天室的技术架构：
次要包含以下局部：
1）接入层的 ChatLink；
2）网络传输层的 WE-CAN、WE-CAN bridge；
3）调度层的 Dispatcher；
4）服务层的 Callback、Queue、Presence、Tag、History 等；
5）CDN 散发层的 CDN Manager、CDN Pusher、CDN Source。
上面，咱们针对每一层开展详细分析。
4、聊天室的接入层
接入层依据客户端的类型不同会有不同的实现，例如常见客户端（iOS、Andriod、Windows、Mac 等）基于公有二进制协定，Web 端基于 Websocket 协定实现。
接入层作为间隔客户端的最初一公里，其接入速度、品质以及数据安全都是至关重要的，上面咱们逐个探讨。
1）接入速度和品质：目前咱们搭建了覆盖全国各省份以及全世界各大洲的边缘节点，缩短最初一公里，缩小不确定性，晋升服务的稳定性。
2）数据安全：基于对称 + 非对称加密，客户端与服务器之前实现 0-RTT，实现秘钥替换和登录，同时也反对 RSA/AES/SM2/SM4 等各种加密算法。接入层除了承受来自客户端的申请，还负责进行音讯的单播和播送，因而接入层须要治理本节点的所有长连贯，包含每个聊天室房间的连贯以及每个连贯的标签属性。此外接入层会上报本人的负载信息给后端服务，不便调度层进行正当的调度。当流量洪峰来长期，因为须要进行音讯的播送，接入层往往是压力最大的，为了保障服务的稳定性，咱们做了很多优化策略。
3）自适应的流控策略：单机流控：接入层服务会监控本机整体的网络带宽应用状况，并设置 2 个阈值 T1 和 T2，当带宽使用率超过 T1 时，触发流控，如果进一步超过了 T2，则不仅触发流控还会一直的调整流控的强度。最终的指标是使带宽使用率稳固在 T1 和 T2 之间。单连贯流控：除此之外，接入层服务还会记录每个长连贯的音讯散发速度，并进行细粒度的调整，防止单机粗粒度流控导致单个连贯散发过少或者过多，做到音讯散发的平滑，即缩小了带宽流量的稳定尖刺，也改善了端侧的体验。
4）性能优化：ChatLink 高负载运行时，除了网络带宽，调用链路上的各个环节都可能成为性能的瓶颈。咱们通过缩小编解码的次数（包含序列化、压缩等）、多线程并发、缩小内存拷贝、音讯合并等多种形式，显著地晋升了服务性能。
5、聊天室的网络传输层
咱们的 IM 聊天室零碎最后的架构是将接入层和后端服务层都部署在同一个机房的，大部分用户都是直连 BGP 机房的 ChatLink，对于偏远地区或者海内，则通过专线的形式部署代理节点实现减速。该计划存在显著的毛病就是服务能力下限受制于单机房的容量。此外，专线也是一笔不小的开销。在咱们接入 WE-CAN 大网后，接入层 ChatLink 能够做到客户端就近接入，进步服务质量的同时升高了老本。此外，多机房的架构也使得咱们的服务能力回升了一个台阶。
为了适配 WE-CAN 大网，咱们设计了 WE-CAN Bridge 层，作为大网接入协定和聊天室协定的桥接层，负责协定转换、会话治理、转发接管。通过这种分层架构，接入层和后端业务层能够少批改或者不批改，缩小对已有零碎的革新老本，也升高了架构降级带来的危险。
什么是 WE-CAN？
WE-CAN（Communications Acceleration Network）是网易自研的新一代大规模分布式传输网络，WE-CAN 的基本指标是建设一个能将任意数据从寰球任一点稳固、疾速、高效地发送到寰球任何其余角落的通用传输网络，且这个网络是架设在公共互联网之上的 —— 即无需借助任何非凡的硬件设施或架设专线，而是通过软件计划来达到目标。
6、聊天室的调度层
调度层是客户端接入聊天室零碎的前提。客户端登录聊天室之前须要先获取接入地址，调配服务咱们称之为 Dispatcher。
Dispatcher 是中心化的，会承受来自 WE-CAN 和 ChatLink 的心跳信息，依据心跳状况来抉择最佳接入点。
调度零碎设计次要思考的是以下两个关键点。
1）调度精度：调度零碎会依据申请方的 IP 判断地区和运营商信息，比照各个边缘节点的所属区域、运营商以及节点自身的负载（如 CPU、网络带宽等）。此外还思考边缘节点到核心机房的链路状况（来自 WE-CAN），计算综合打分，并把最优的若干节点作为调度后果。
2）调度性能：面对高并发场景，比方一个大型聊天室，流动初期往往随同着大量人员的同时进入，此时就须要调度零碎做出疾速的反馈。为此，咱们会将上述的调度规定以及原始数据进行本地缓存优化。此外，为了防止心跳信息滞后导致调配不合理引起节点过载，调配服务时还会动静调整负载因子，在保障调度性能的前提下，尽量做到调配后果的平滑。
7、聊天室的服务层
服务层实现了各种业务性能，包含：
1）在线状态；
2）房间治理；
3）云端历史；
4）第三回调；
5）聊天室队列；
6）聊天室标签等。
其中最根底的是在线状态治理和房间治理：
1）在线状态治理：治理某个账号的登录状态，包含登录了哪些聊天室、登录在了哪些接入点等；
2）房间治理：治理某个聊天室房间的状态，包含房间散布在哪些接入点，房间里有哪些成员等。
在线状态治理和房间治理的难点在于如何无效治理海量用户和房间。因为 PaaS 平台的个性，使得咱们能够依据不同的租户来进行 Region 划分，从而做到程度扩大。此外：因为状态数据有疾速变动的特点（短 TTL），当某些外围用户或者某个客户报备了大型流动时，能够在短时间内进行相干资源的疾速拆分和隔离。服务层除了要反对海量客户接入、程度扩大外，还有一个很重要能力，就是须要提供各种各样的扩大性功能来适配客户各种利用场景。
为此咱们还提供了丰盛的性能，比方：
1）第三方回调：不便客户干涉 C 端用户的登录、发消息等外围环节，自定义实现各种业务逻辑（因为波及到服务调用，而这个调用是跨机房甚至是跨地区的，为了防止第三方服务故障导致云信服务异样，咱们设计了隔离、熔断等机制来缩小对要害流程的影响）；
2）聊天室队列：能够不便用户实现一些诸如麦序、抢麦等业务场景需要；
3）聊天室标签：作为特色性能，反对音讯的个性化分 发（其实现原理是通过客户端登录时设置标签组以及发消息时设置标签表达式，来定义音讯散发和接管的规定。标签信息会同时保留在服务层以及接入层，通过将局部标签计算下推到接入层，节俭了核心服务的带宽和计算资源）。
8、聊天室的 CDN 散发层
当咱们评估一个牛 x 的 IM 聊天室零碎时，罕用的一个词是无下限。架构反对无下限不代表真的无下限。一个 IM 聊天室零碎，在逻辑上，各个组成单元都是能够程度扩大的，然而每个服务所依赖的物理机、交换机、机房带宽等都是有容量下限的。因而，可能正当地调配多个地区的多个机房，甚至是内部的其余资源，能力真正体现出一个聊天室零碎所能撑持的容量下限。在咱们的聊天室零碎中，用户所有的接入点遍布各地机房，人造的将各地的资源进行了整合，所能撑持的容量下限天然高于单机房或者单地区多机房的部署模式。进一步的：当面临一个更大规模的聊天室，此时如果能利用一些内部的通用能力不失为一种适合的抉择。交融 CDN 弹幕计划就是这样一种技术实现计划，它能够利用各大 CDN 厂商部署在各地的边缘节点，利用动态减速这样的通用能力来反对超大规模的聊天室音讯散发。基于交融 CDN 弹幕散发计划，其外围点就是弹幕的散发和治理，这是一个可选的模块，咱们外部对此进行了封装，能够依据不同的业务特点来抉择是否开启而不须要批改任何业务代码。
在开启交融 CDN 弹幕散发计划的状况下，所有的弹幕播送会划分成两条链路：
1）重要的且须要实时送达的音讯会走长连贯达到客户端；
2）其余的海量音讯则会进入 CDN Pusher，通过各种策略进行聚合后送达 CDN Source。
客户端 SDK 会采取肯定的策略定时从 CDN 边缘节点获取弹幕音讯。SDK 会聚合不同起源的音讯，排序后回调给用户，App 层无需关系音讯来自哪里，只需依据本人的业务需要进行解决即可。
如上图，展现了 CDN 弹幕散发链路的音讯流转过程。
CDN Manager 负责：
1）治理不同 CDN 厂商的调配策略（登录时会通过长连贯下发，且能动静调整）
2）负责管理平台上各个聊天室交融 CDN 模式的开启和敞开；
3）对应的 CDN Pusher 资源的调配和回收。
CDN Pusher 理论负责：
1）接管来自客户端音讯；
2）并依据音讯的类型、音讯的优先级等，组装成以一个一个的动态资源，推给 CDN Source，期待 CDN 回源拉取。
9、大规模场景利用案例
在 2020 年 8 月，网易云音乐 TFBoys 的 7 周年线上演唱会就是一个聊天室大规模场景利用的典型案例。在这场流动发明了 78w+ 的在线付费演唱会的世界纪录，其弹幕互动的实现形式采纳了咱们基于交融 CDN 弹幕散发计划。事实上：在筹备环节，咱们的聊天室零碎达成了 20 分钟实现从 0 到 1000w 在线，上行音讯 tps 达到 100w 的性能指标。
如上图：是反对本次流动弹幕散发的架构图，一般弹幕和礼物音讯别离通过客户端 SDK 以及服务器 API 达到云信服务器，并最终进入弹幕播送服务，随后分流到长连贯和 CDN 上，再通过 pull / push 混合的形式送达客户端。
PS：有趣味的同学能够深刻浏览对于这个案例的技术分享：《直播零碎聊天技术 (九)：千万级实时直播弹幕的技术实际》。
10、聊天室标签利用案例
近年来，随着互联网的倒退，在线教育越来越火爆，最近又衰亡了“超级小班课”模式。所谓超级小班课，指的是大型多人课堂与小班互动模式联合。在线直播场景下，文字互动作为其中重要的一环，是 IM 聊天室的典型利用场景。但在超级小班课的模式下，惯例的 IM 聊天室零碎却存在各种各样的问题，不论是建设多个聊天室，还是单个聊天室进行音讯过滤，都存在一些重大的问题。由此咱们凋谢了聊天室标签性能，完满反对了上述业务场景。基于聊天室标签：能够灵便地反对聊天室音讯定向收发、聊天室权限定向治理、聊天室成员定向查问等个性化性能，真正实现大型直播下多场景的分组互动。
比方：
1）对学生进行分组标签后，不便进行因材施教；
2）分小组讨论，小组间外部探讨和组间 PK 等等。
如上图，展现了超级小班课的一个场景：1 个主讲老师 + N 个互动小班 + N 个助教，所有学生被划分成了一个一个的小班，由对应的助教实现预习揭示、课后答疑、作业监督、学员学习状况反馈等工作，同时又接管来自主讲老师的直播画面，做到了大课的规模，小课的成果。
11、本文小结
以上，就是本文的全副分享，次要介绍了咱们构建一个大型聊天室零碎的次要技术以及架构原理。任何零碎的搭建都不是欲速不达的，咱们也会持续打磨底层技术，就像引入 WE-CAN 来晋升网络传输成果，也会持续丰盛欠缺咱们的性能图谱（如独创的聊天室标签性能等）。
12、参考资料
[1] 直播零碎聊天技术 (九)：千万级实时直播弹幕的技术实际
[2] 海量实时音讯的视频直播零碎架构演进之路 (视频 +PPT)
[3] 百万在线的美拍直播弹幕零碎的实时推送技术实际之路
[4] 阿里电商 IM 音讯平台，在群聊、直播场景下的技术实际
[5] 微信直播聊天室单房间 1500 万在线的音讯架构演进之路
[6] 百度直播的海量用户实时音讯零碎架构演进实际
[7] 百万人在线的直播间实时聊天音讯散发技术实际
[8] 直播间海量聊天音讯的架构设计难点实际
[9] vivo 直播零碎中 IM 音讯模块的架构实际
[10] 万人群聊音讯投递计划的思考和实际
[11] IM 中的万人群聊技术计划实际总结
（本文已同步公布于：http://www.52im.net/thread-4404-1-1.html）