网易云信直播聊天室：无上限人数&系统不卡顿，是不是鱼与熊掌不能兼得？

　　

　　1.直播聊天室的形式和应用场景

　　在一般人的理解中，直播聊天室应该就是直播画面旁边配一个聊天窗口，众多观看者在

　　里面发表自己的评论（如图1）。Oh, NO！这样的场景是不是太Low啦！随着互联网技术和消费者群体的转移，这种简单的聊天室根本就满足不了广大网民的需求。比如小明平时就爱网红视频直播，来了就点亮自己，视频弹幕自己想对网红说的话，高兴的时候要送礼，还要和粉丝积极互动。小军热衷投资，对投资大师们的动向分析实时关注，现在大师们开直播啦，不仅可以听取知识还可以实时互动，有问题及时解答，完美！能满足他们的要求么？

　　答案是当然！发展到现在，直播聊天室的展现形态已经多样化：评论，点亮，弹幕，送礼热你选（如图2），是不是美美哒？而使用直播聊天室的场景也越来越多，网红直播，在线教育，金融等，使用直播聊天室也从网站端转移到移动端，让直播+聊天室实现了全民真正的互动，舞台已经不属于少数人，人人都能参与其中！

　　

　　图1：传统聊天室形态

　　

　　图2：直播聊天室新形态



　　2.直播聊天室的技术难点

　　欣赏完了图2美美的图片，给大家看一个立马毁三观的场景。以下这个画面（图3）是不是很熟悉，善良的你打开直播画面就卡住，几万人同时high翻全场的时候，你的弹幕卡成鬼畜视频，女主播的脸卡成好几节，卡到你怀疑网速、电脑配置、浏览器、怀疑你自己的人品为止。这样的聊天室客户体验是不是太差了？怎么会这样呢？说好的美图2呢？



　　

　　图3：直播卡顿



　　回到正题，开篇阐述了直播各种应用场景，全民互动，对应的问题是：一个热门直播间人数可能达到几十万人，个人发消息几十万人接收，几十万人发消息几十万人接收，这个流量相当惊人，服务端要如何设计才能保证系统流畅？无上限人数&系统顺畅不卡顿，这两个条件如何在直播时同时满足？即如何才能成功搭建一个完美的视频直播系统？

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

　　

　　图4：常见虚拟社群形态的对比



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

　　聊天室目前比较流行的做法说都是建立在群的架构上，但是只要是群就有人数和离线消息的存入上限，所以您看到的图2就不足为奇，聊天室人数越多现象更严重，这里请大家自行脑补下看电视满屏雪花点的感受。

　　问题来了，那跳出群框架就好了啊，如此简单。Oh,No！还真不是你想跳就能跳，下面我们来看看搭建无上线聊天室的难点在哪里？

　　

　　  图5：聊天室搭建技术难点



　　首先第一个难点是客户端多样性：

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

　　

　　  图6：客户端多样性



　　我们曾遇到过一个创业团队，他们想自己实现TCP长连接的逻辑，iOS开发的同学没日没夜干了一个礼拜，终于把第一个RPC请求调通了，结果又在数据包压缩瘦身和加密的坑里爬了大半个月，好不容易发了个demo版出来，结果发现移动网络下各种掉线，最后又不断优化弱网环境下的自动重连机制，负责安卓的同学则在边上观摩了一个月之后彻底放弃了，因为他要用java重新把iOS同学的Objective-C代码再重新实现一遍，里面有多少坑，能不能爬出来说也说不准；而网页开发同学就直接懵了，因为他根本没法理解Web上的长连接是什么鬼，调研半天发现只能用websocket这种方案，但是这种方案已有的服务器又根本没法支持。

　　其次，要考虑到数据安全的保证

　　当前的网络安全形势异常复杂，开发应用时如果不在通信安全上花心思，那你的用户就是在互联网上裸奔；开发者需要针对不同的平台，不同的通信技术实现可靠的安全方案，避免用户数据在传输过程中泄露。在选择一个云提供商时，他们应该具备哪些云安全认证和标准?是否有匹配具体安全服务类型的认证?其实安全需求跨度非常广，涵盖行业甚至企业自己内部，但是确有一些共性的需求来保证云安全认证和标准的开发。一些标准很明显是适用的，比如C-STAR认证和ISO27001，都是国际通行的信息安全方面的认证体系。

　　

　　第三，还需要配备跨机房网络级的高可用方案

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

　　同时，还需要所有环节的单点故障排除

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

　　你一定听说过“蓝翔毕业生挖断机房光缆”这样的故事吧，也听说过天津港爆（bao）炸（zha）引起IDC机房受损这样的真实事件吧，当这种不可预测的天灾人祸降临的时候，如果能不影响服务的话那就更厉害了，所以现在服务提供方都在提“异地双活”之类的高可用方案。更不用提服务器宕机之类的这种家常便饭的小故障了，所以在服务的设计时都需要消除可能存在的单点。

　　

　　然后需要能应对任何用户量级的需求

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

　　网易云信新同事Peter刚进入团队时跟我们分享了一个自己的故事，他和几个小伙伴之前做了一个分享周边美食的App，但是人手紧张啊，想着快速出成效，服务器简单搞了几个Tomcat，前端弄了Nginx就当高可用了，服务器和客户端的数据通讯就简单的http协议实现了，开发速度是真快！iOS和安卓只要在客户端搞个http的库就把数据通信的事情搞完了；为了在一个分享内容发出去之后马上能被其他人看到，客户端同学天真地来了一个5秒轮询的逻辑，产品愉快地被推广出去之后，用户量几百人几千人时大家都一副很轻松的样子，但当用户量过万的时候就发现服务器撑不住了，5秒轮询的坑开始发威了。再然后就是竞品出来了，用户体验被完爆，最后Peter就来网易云信了，这真是个悲伤的故事。Peter泪流满面地说：架构扩展性真的好重要！

　　架构必需要具备足够的弹性，

　　在用户量级上来之后能支持快速的水平扩展，不会因为架构的问题需要重构；

　　最后就是消息投递速度，绝对影响用户体验

　　聊天室对消息的即时性要求非常高，同一条消息在投递给不同成员时需要在毫秒级内完成，如果消息投递慢了容易造成消息时间线错乱，使聊天室里的人无法理解上下文场景。

　　3.无上限不卡顿聊天室架构应具备的条件

　　看了上述描述，是不是觉得很难很复杂哇，那我来总结下这样的聊天室架构应该具备哪些条件吧！

　　跨平台：新型的应用都是能同时跨多种设备实现消息互通的，比如网页端，手机端和桌面端，甚至智能电视等；

　　数据加密：客户端与服务器端之间的通信数据要避免泄露的风险；

　　高可用：任何一个节点故障都不应该引起服务不可用；

　　易扩展：具有水平扩展的特性，对不同量级的在线用户数都有应变的能力；

　　高并发低延迟：能支持大量的用户同时收发消息，消息从发出到送达所有在线端的延时在毫秒级；

　　4.无上限不卡顿聊天室，云信是如何做到的？

　　这里可以分享一下网易云信是如何搭建设计架构的：我们是分了客户端层、网关接入层、路由层、业务层进行分别处理。

　　

　　在客户端层重点解决跨平台问题，SDK实现了多平台覆盖，对iOS、Android、Windows和Web等开发平台都提供了原生SDK版本，最大程度上解决了开发者跨平台需求的难题，使开发者能使用自己熟悉的开发语言和平台快速实现产品功能。此外我们对iOS和Android这种移动网络做了弱网络优化，开发者无需关心移动网络切换时网络断线重连等问题，提高了连接的稳定性。在通信安全方面，对客户端与服务器端之间的通信数据都做了加密压缩处理，一则帮用户节省了网络流量，提高数据传输效率，二则保证了通信数据的安全性，规避数据泄露或中间人攻击等各种安全风险。

　　然后就是网关接入层面，网关接入层主要用于客户端长连接的管理，单个节点可以维护的长连接在十万量级。网关接入层还有一个重要功能是处理不同SDK的协议兼容问题，比如Web端使用的WebSocket协议和iOS端使用的基于TCP的私有协议是不一样的，这类客户端与服务器在数据通信协议上的差异需要通过接入网关做协议转换；另外，我们的网关接入层还要处理数据安全逻辑和跨网络的高可用逻辑(谁知道哪天网线会被蓝翔的毕业生挖断呢?)；最后是广播消息的高效下行分发，网关接入节点需要将收到的广播消息分发到本节点上维护的客户端。

　　路由层，路由层承担了网关接入层和业务层之间解耦的功能，数据包到达接入层之后通过路由层中转送达到正确的业务节点，同时具有负载均衡和高可用的能力，在单个业务节点处理能力达到瓶颈时能方便快速的扩容；路由层使业务层扩容对前置网关层完全透明，当一个网络的业务集群出现网络故障时，可以切换到备用网络，保证服务可用性。

　　最后从业务层上来说，我们聊天室功能上的业务节点主要用于处理收发聊天室消息，成员进出鉴权等具体的业务逻辑，集群内有众多节点，它们角色相互对等，单节点的故障可能会使集群的业务处理能力受影响但不会引起服务的中断，在节点故障发生时可以快速增加新的替代节点来恢复集群的业务处理能力；此外业务集群有多个网络环境的热备，以应对可能出现的区域性网络故障。



　　5.使用网易云信聊天室的原因

　　创业，时间是你最大的成本

　　技术发展到现在已经不流行重复造轮子了，因为轮子的结构越来越复杂，功能性和非功能性的指标要求越来越高；而我们的用户却不会再等我们了。当我们还在画轮子的图纸的时候，竞争对手可能已经把车子都造好，在路上跑了。虽然我们不是非得自己造轮子，但是了解如何完成一个完美的轮子的制作过程和质量标准却是非常有必要的，这也是之前谈这么多的原因。比如要做互联网视频直播，要选一家靠谱的CDN厂商，不靠谱的CDN服务对小产品开发团队就是一个灾难，其次找一个靠谱的技术团队，如何在行业窗口爆发期去迅速找到一批专业的技术高手，是每个创业团队面临的问题。

　　就像近几年大数据技术非常流行，如果你对这个领域有所了解你就会发现几乎所有公司都在使用已有的平台，或者直接使用，或者在上面做二次改造，原因无非就是上面说的几点。现在你遇到的也是同样的问题，聊天室这种功能在最近两年又火了起来，主要还是视频直播业务的大规模扩张；能借用目前已有的平台或工具来实现产品需求是最快捷的路径，创业团队需要关注的是怎样以最快的速度抓住用户。造个好轮子不容易，为什么不用现成的？

　　我们为您的安全保驾护航

　　如前文所述，数据安全需求跨度非常广，涵盖行业甚至企业自己内部，但是确有一些共性的需求来保证云安全认证和标准的开发。一些标准很明显是适用的，比如C-STAR认证和ISO27001，都是国际通行的信息安全方面的认证体系。而网易云信是国内首批通过ISO22301认证的云服务商。

　　ISO 22301是第一份以业务连续管理(Business Continuity Management，简称BCM)为主题的国际标准，提供了一种完整通用的BCM方法论，让企业能够达到国际上公认的最佳实践。该认证适用于所有行业中的大、中、小型公有及私有组织，并且特别适用于处于高风险和高度监管环境下的行业，例如金融业、IT通信业、制造业等，在企业业务的运行过程中，往往会受到各种内在或外在因素的影响，严重时甚至会导致中断业务，而意外的中断会给企业带来重大损失。