几十万人同时在线的直播间聊天，如何设计服务端架构？

一个热门视频直播间人数可能达到几十万甚至上百万人，几十万人发消息，几十万人接收，流量相当惊人，那么服务端要如何设计才能保证系统流畅？本文作者将结合他在网易云信多年IM开发的经验进行深度分析。

推荐阅读

• 高并发 IM 系统架构优化实践
• IM 即时通讯：如何跳出传统思维来设计聊天室架构？

聊天室架构应满足哪些条件

• 高可用：任何一个节点故障都不应该引起服务不可用；
• 易扩展：具有水平扩展的特性，对不同量级的在线用户数都有应变的能力；
• 高并发低延迟：能支持大量的用户同时收发消息，消息从发出到送达所有在线端的延时在毫秒级；
• 客户端兼容性：新型的应用都是能同时跨多种设备实现消息互通的，比如网页端，手机端和桌面端，甚至智能电视等。

聊天室架构如何设计

• 客户端层

处理各种设备的兼容问题，包括对 iOS, Android, Windows, Web 等各种开发平台的语言适配；消息通道的管理维护，包括移动设备上的弱网络管理，断线重连等；保证数据安全，所有上行下行的数据包都需要加解密处理，规避数据泄露或中间人攻击等各种安全风险。

• 网关接入层

管理大量客户端连接，单个节点可以维护的客户端数量在数十万量级；处理不同类型客户端的协议兼容，由于客户端实现技术的多样性，导致客户端与网关之间底层的数据通信协议存在差异，需要由不同的接入网关做协议转换；处理数据安全逻辑；跨网络的高可用逻辑，网络级别的主备（谁知道哪天网线会被蓝翔的毕业生挖断呢？）；广播消息的高效下行分发，将收到的广播消息分发到所有连接在本节点上的客户端。

• 路由层

作为业务层接入的中转，同时承担负载均衡和高可用的作用，单个业务节点处理能力达到瓶颈时更方便的扩容，路由层使业务层扩容对前置网关层完全透明；当一个网络的业务集群出现网络故障时，可以切换到备用网络，保证服务可用性。

• 业务层

处理聊天室内的业务消息，一个集群内有众多节点，节点角色相互对等，任何一个节点的故障会使整个集群的处理能力下降，但不会引起服务的中断，因为其他节点可以继续接管业务数据包的处理；业务集群同样有多个网络环境的热备，以应对可能出现的区域性网络故障。

难点在哪里

• 客户端多样性

目前的应用都存在跨平台的需求，iOS、安卓和 PC 端，网页端，甚至 IoT 物联网设备，能连多少是多少，多多益善；但是不同开发平台之间的技术差异性极大，不是所有公司都有这么全的全栈程序猿的；如果团队开发的话单就客户端开发人员就不是几个人可以完成的。

• 数据安全的保证

当前的网络安全形势异常复杂，开发应用时如果不在通信安全上花心思，那你的用户就是在互联网上裸奔；开发者需要针对不同的平台，不同的通信技术实现可靠的安全方案，避免用户数据在传输过程中泄露，避免中间人攻击等安全风险。

• 跨机房网络级的高可用方案

当机房网络出现故障时把责任推给市政施工队或者“网络抽风”已经不流行了，用户需要的是故障无感知。

• 所有环节的单点故障排除

任何硬件和软件都存在故障的可能，我们无法避免应用罢工，那就需要随时准备替补上场。

• 能应对任何用户量级的需求

架构级做到水平扩展的能力，当用户量增长时随时可以通过堆服务器来解决，而不是将架构推倒重来。

看完文章还是不知道怎么做？那么可以尝试借用目前已有的平台或工具，现在应用需要关注的是怎么以最快的速度抓住用户。网易云信是一个面对开发者的很好的 IM 云平台。十余年的研发积累，使其在即时通讯技术方面处于全国领先水平。网易云信至今已申请了 60 余项 IM 专利，远超市场同类产品。欢迎大家与我们讨论 IM 技术，也欢迎大家多多关注网易云信。

---

随着即时通讯以及音频处理和压缩技术的不断发展，效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现，如果你有好的技术或者分享，欢迎关注网易云信官方博客和 GitHub：

关注更多技术干货内容： 网易云信博客
欢迎关注 网易云信 GitHub
欢迎关注 网易云信官网