网易云信技术分享：IM聊天室架构如何跳出传统思维来设计？

幸福小鱼儿 · 8 年前

演讲者

周梁伟

现任网易云信 IM云服务器端开发负责人，浙江大学计算机学院硕士；
2011年加入网易，先后担任网易后台技术中心与网易大数据平台资深开发工程师，
负责即时通讯领域的产品开发与应用服务器与大数据领域战略规划与设计。

下文根据周梁伟在高升云道深圳站演讲整理而成。

概述

网易云信是网易公司推出的一个面向开发者的IM云平台。今天，结合《性能当道优化为王》的主题，重点挑选聊天室这个典型场景，和大家分享一下网易云信在实现这个功能时是如何做架构设计的。

常见的虚拟社群

聊天室的应用场景非常广，除了传统的图文聊天外，时下流行的视频弹幕、在线秀场、在线教育、游戏互动等各式各样产品中都有类似的应用场景。

在讨论聊天室之前，我们先了解下几种常见的虚拟社群形态。下表从参与人数、消息送达即时性、离线消息关注度等维度对论坛、IM P2P、IM群和聊天室这几种常见的虚拟社群形态做了简单对比，从这个对比可以看到聊天室是不同于论坛和群模式的一种虚拟组织，聊天室的架构需要跳出传统思维来设计。

聊天室跟普通的IM群（微信群，QQ群等）相比最大的不同点在于它是一个比较开放的虚拟组织。我们可以将聊天室比喻成一个广场，广场是开放无边界的，所有的人都可以随进随出，而群就像一个房间，是一个有边界有容量上限的私密组织，并且进入这个房间需要一定条件，一般是主动申请加入或被邀请加入。聊天室对比BBS论坛这种虚拟组织来说，它既具有了IM群消息即时送达的特性又有论坛参与人数无上限的特性。

聊天室关键技术和难点

1是否能从一个已有的成熟技术框架上改造一个聊天室出来呢？

经过前面的比较我们看到，聊天室和论坛及IM群都具有一定的共性，看起来似乎可以将论坛架构改造成聊天室，也可以将IM群改造成聊天室。

路径一：将论坛架构改造成聊天室，首先需要提高消息送达的即时性，由于论坛都是基于HTTP协议的，为了保证消息即时送达，需要客户端不断轮询服务器来获取新的消息，如果对即时性的要求越高，那轮询的时间就需要缩短，这种模式在用户量达到一定规模后是无法承载的。为了保证消息的高效送达，客户端与服务器之间的需要采用长连接机制，新消息的送达通过服务器主动向客户端下推来完成。

路径二：将已有的IM群改造成聊天室，由于群具有对离线消息关注度高的特性，所有的群消息在成员离线时需要持久化，因而群人数越多效率越低，也正是因为这个原因，一般的IM群都是有人数上限的，如果想把群改造成聊天室，就不能存离线消息，所以这种方式看起来也不是这么顺畅。

现在市场上很多提供聊天室类服务的产品其实都是基于群的模式来实现的，所以人数上限一直是一个难以突破的瓶颈，甚至有的服务直接使用“超大群”或“千人群”这样一种特殊群模式来满足用户对聊天室场景的需求。

2下面我们来看下，如果要实现一个人数无上限的聊天室服务，需要解决哪些难题

首先：客户端多样性。近几年来移动互联网发展得非常快，现在推出的APP一般都需要同时具备iOS版、安卓版和Web版、PC版等不同的版本，跨平台的开发需求一直是拦在创业团队面前的一座大山；
第二：数据安全保障。当前的网络环境异常复杂，我们的APP在客户端与服务器之间的数据通信都暴露在复杂的公网环境中，消息经过哪些节点，中间有没有被抓包，数据是否被恶意采集，这些问题普通用户开和发者都容易忽略。如果数据通信过程中忽视了安全需求，很容易造成用户数据的泄露，数据的安全保障对于产品而言也很重要；
第三：需要应对网络故障或服务单点故障的难题。开发者代码写得再好也无法避免硬件故障或是网络故障这种不可预知的问题，在产品积累了一定的用户量之后，如果遇到服务可用性问题会造成用户流失。
第四：架构需要具备足够的弹性。在用户量级上来之后能支持快速的水平扩展，不会因为架构的问题需要重构。
最后：消息投递慢。聊天室对消息的即时性要求非常高，同一条消息在投递给不同成员时需要在毫秒级的延时完成，如果消息投递慢了会造成消息时间线错乱，聊天室里的人无法理解上下文场景。

基于这些难点，我们提出聊天室需要具备这些指标：跨平台、数据加密、高可用、易扩展、高并发低延迟。

云信聊天室的架构

▲ 上图是网易云信的聊天室分层架构

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

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

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

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

题外话

技术发展到现在已经不流行重复造轮子了，因为轮子的结构越来越复杂，功能性和非功能性的指标要求越来越高；而我们的用户却不会再等我们了。当我们还在画轮子的图纸的时候，竞争对手可能已经把车子都造好，在路上跑了。虽然我们不是非得自己造轮子，但是了解如何完成一个完美的轮子的制作过程和质量标准却是非常有必要的，这也是我前面和你介绍了这么多的原因。

就像近几年大数据技术非常流行，如果你对这个领域有所了解，你就会发现几乎所有公司都在使用现有的平台，比如Hadoop；或者直接使用，或者在上面做二次改造，原因无非就是上面说的几点。

现在你遇到的也是同样的问题，聊天室这种功能在最近两年又火了起来，主要还是视频直播业务的大规模扩张；所以能借用目前已有的平台或工具是最快捷的路径，应用需要关注的是怎么以最快的速度抓住用户。