因为视频直播业务的大规模扩张,聊天室这种功能在最近几年又火了起来。本篇文章将会重点挑选聊天室这个典型场景,和大家分享一下网易云信在实现这个功能时是如何做架构设计的。
相关推荐阅读
常见的虚拟社群
聊天室的应用场景非常广,除了传统的图文聊天外,时下流行的视频弹幕、在线秀场、在线教育、游戏互动等各式各样产品中都有类似的应用场景。
在讨论聊天室之前,我们先了解下几种常见的虚拟社群形态。下表从参与人数、消息送达即时性、离线消息关注度等维度对论坛、IM P2P、IM 群和聊天室这几种常见的虚拟社群形态做了简单对比,从这个对比可以看到聊天室是不同于论坛和群模式的一种虚拟组织,聊天室的架构需要跳出传统思维来设计。
聊天室跟普通的IM群(微信群,QQ 群等)相比最大的不同点在于它是一个比较开放的虚拟组织。我们可以将聊天室比喻成一个广场,广场是开放无边界的,所有的人都可以随进随出,而群就像一个房间,是一个有边界有容量上限的私密组织,并且进入这个房间需要一定条件,一般是主动申请加入或被邀请加入。聊天室对比 BBS 论坛这种虚拟组织来说,它既具有了IM群消息即时送达的特性又有论坛参与人数无上限的特性。
聊天室关键技术和难点
那么,是否能从一个已有的成熟技术框架上改造一个聊天室出来呢?
经过前面的比较我们看到,聊天室和论坛及 IM 群都具有一定的共性,看起来似乎可以将论坛架构改造成聊天室,也可以将 IM 群改造成聊天室。
路径一:将论坛架构改造成聊天室,首先需要提高消息送达的即时性,由于论坛都是基于 HTTP 协议的,为了保证消息即时送达,需要客户端不断轮询服务器来获取新的消息,如果对即时性的要求越高,那轮询的时间就需要缩短,这种模式在用户量达到一定规模后是无法承载的。为了保证消息的高效送达,客户端与服务器之间的需要采用长连接机制,新消息的送达通过服务器主动向客户端下推来完成。
路径二:将已有的 IM 群改造成聊天室,由于群具有对离线消息关注度高的特性,所有的群消息在成员离线时需要持久化,因而群人数越多效率越低,也正是因为这个原因,一般的IM群都是有人数上限的,如果想把群改造成聊天室,就不能存离线消息,所以这种方式看起来也不是这么顺畅。
现在市场上很多提供聊天室类服务的产品其实都是基于群的模式来实现的,所以人数上限一直是一个难以突破的瓶颈,甚至有的服务直接使用“超大群”或“千人群”这样一种特殊群模式来满足用户对聊天室场景的需求。
下面我们来看下,如果要实现一个人数无上限的聊天室服务,需要解决哪些难题。
首先:客户端多样性。
近几年来移动互联网发展得非常快,现在推出的 APP 一般都需要同时具备 iOS 版、安卓版和 Web 版、PC 版等不同的版本,跨平台的开发需求一直是拦在创业团队面前的一座大山;
第二:数据安全保障。
当前的网络环境异常复杂,我们的 APP 在客户端与服务器之间的数据通信都暴露在复杂的公网环境中,消息经过哪些节点,中间有没有被抓包,数据是否被恶意采集,这些问题普通用户开和发者都容易忽略。如果数据通信过程中忽视了安全需求,很容易造成用户数据的泄露,数据的安全保障对于产品而言也很重要;
第三:需要应对网络故障或服务单点故障的难题。
开发者代码写得再好也无法避免硬件故障或是网络故障这种不可预知的问题,在产品积累了一定的用户量之后,如果遇到服务可用性问题会造成用户流失;
第四:架构需要具备足够的弹性。
在用户量级上来之后能支持快速的水平扩展,不会因为架构的问题需要重构;
最后:消息投递慢。
聊天室对消息的即时性要求非常高,同一条消息在投递给不同成员时需要在毫秒级的延时完成,如果消息投递慢了会造成消息时间线错乱,聊天室里的人无法理解上下文场景。
基于这些难点,我们提出聊天室需要具备这些指标:跨平台、数据加密、高可用、易扩展、高并发低延迟。
网易云信聊天室的架构
上图是网易云信的聊天室分层架构。
客户端层:处理各种设备的兼容问题,包括对 iOS, Android, Windows, Web 等各种开发平台的语言适配;消息通道的管理维护,包括移动设备上的弱网络管理,断线重连等;保证数据安全,所有上行下行的数据包都需要加解密处理,规避数据泄露或中间人攻击等各种安全风险。
网关接入层:管理大量客户端连接,单个节点可以维护的客户端数量在数十万量级;处理不同类型客户端的协议兼容,由于客户端实现技术的多样性,导致客户端与网关之间底层的数据通信协议存在差异,需要由不同的接入网关做协议转换;处理数据安全逻辑;跨网络的高可用逻辑,网络级别的主备(谁知道哪天网线会被蓝翔的毕业生挖断呢?);广播消息的高效下行分发,将收到的广播消息分发到所有连接在本节点上的客户端。
路由层:作为业务层接入的中转,同时承担负载均衡和高可用的作用,单个业务节点处理能力达到瓶颈时更方便的扩容,路由层使业务层扩容对前置网关层完全透明;当一个网络的业务集群出现网络故障时,可以切换到备用网络,保证服务可用性。
业务层:处理聊天室内的业务消息,一个集群内有众多节点,节点角色相互对等,任何一个节点的故障会使整个集群的处理能力下降,但不会引起服务的中断,因为其他节点可以继续接管业务数据包的处理;业务集群同样有多个网络环境的热备,以应对可能出现的区域性网络故障。
看完文章还是不知道怎么做?那么可以尝试借用目前已有的平台或工具,现在应用需要关注的是怎么以最快的速度抓住用户。网易云信是一个面对开发者的很好的IM云平台。十余年的研发积累,使其在即时通讯技术方面处于全国领先水平。网易云信至今已申请了60余项IM专利,远超市场同类产品。欢迎大家与我们讨论IM技术,也欢迎大家多多关注网易云信。
随着即时通讯以及音频处理和压缩技术的不断发展,效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现,如果你有好的技术或者分享,欢迎关注网易云信官方博客和 GitHub:
关注更多技术干货内容:网易云信博客
欢迎关注网易云信 GitHub
欢迎关注网易云信官网
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。