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

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

推荐阅读

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

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

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

聊天室架构如何设计

• 客户端层

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

• 网关接入层

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

• 路由层

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

• 业务层

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

难点在哪里

• 客户端多样性

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

• 数据安全的保证

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

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

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

• 全部环节的单点故障排除

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

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

架构级作到水平扩展的能力，当用户量增加时随时能够经过堆服务器来解决，而不是将架构推倒重来。

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

---

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

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