聊天室和群聊的区别?

聊天室是一类非常重要的 IM 业务形态,不同于单聊和群聊,聊天室是一种大规模的实时消息分发系统。聊天室有多种技术实现方案,业界也有一些开源的实现,每种实现都有自己的特点和应用场景。

首先,我们先来看一下网易云信当前聊天室的详细技术架构,以及我们在架构升级优化过程中做的一些事情。

接入层根据客户端的类型不同会有不同的实现,例如常见客户端(iOS、Andriod、Windows、Mac 等)基于私有二进制协议,Web 端基于 Websocket 协议实现。

接入层作为距离客户端的最后一公里,其接入速度、质量以及数据安全都是至关重要的,下面我们逐一讨论。

目前我们搭建了覆盖全国各省份以及全世界各大洲的边缘节点,缩短最后一公里,减少不确定性,提升服务的稳定性。

基于对称+非对称加密,客户端与服务器之前实现 0-RTT,完成秘钥交换和登录,同时也支持 RSA/AES/SM2/SM4 等各种加密算法。

接入层除了接受来自客户端的请求,还负责进行消息的单播和广播,因此接入层需要管理本节点的所有长连接,包括每个聊天室房间的连接以及每个连接的标签属性。

当流量洪峰来临时,因为需要进行消息的广播,接入层往往是压力最大的,为了保证服务的稳定性,我们做了很多优化策略。

单机流控:接入层服务会监控本机整体的网络带宽使用情况,并设置 2 个阈值 T1 和 T2,当带宽使用率超过 T1 时,触发流控,如果进一步超过了 T2,则不仅触发流控还会不断的调整流控的强度。最终的目标是使带宽使用率稳定在 T1 和 T2 之间。

单连接流控:除此之外,接入层服务还会记录每个长连接的消息分发速度,并进行细粒度的调整,避免单机粗粒度流控导致单个连接分发过少或者过多,做到消息分发的平滑,即减少了带宽流量的波动尖刺,也改善了端侧的体验。

ChatLink 高负载运行时,除了网络带宽,调用链路上的各个环节都可能成为性能的瓶颈。我们通过减少编解码的次数(包括序列化、压缩等)、多线程并发、减少内存拷贝、消息合并等多种方式,显著地提升了服务性能。

我们的IM聊天室系统最初的架构是将接入层和后端服务层都部署在同一个机房的,大部分用户都是直连 BGP 机房的 ChatLink,对于偏远地区或者海外,则通过专线的方式部署代理节点完成加速。

在我们接入 WE-CAN 大网后,接入层 ChatLink 可以做到客户端就近接入,提高服务质量的同时降低了成本。此外,多机房的架构也使得我们的服务能力上升了一个台阶。

为了适配 WE-CAN 大网,我们设计了 WE-CAN Bridge 层,作为大网接入协议和聊天室协议的桥接层,负责协议转换、会话管理、转发接收。通过这种分层架构,接入层和后端业务层可以少修改或者不修改,减少对已有系统的改造成本,也降低了架构升级带来的风险。

WE-CAN(Communications Acceleration Network)是网易自研的新一代大规模分布式传输网络,WE-CAN的根本目标是建立一个能将任意数据从全球任一点稳定、快速、高效地发送到全球任何其他角落的通用传输网络,且这个网络是架设在公共互联网之上的 —— 即无需借助任何特殊的硬件设备或架设专线,而是通过软件方案来达到目标。

调度层是客户端接入聊天室系统的前提。客户端登录聊天室之前需要先获取接入地址,分配服务我们称之为 Dispatcher。

Dispatcher 是中心化的,会接受来自 WE-CAN 和 ChatLink 的心跳信息,根据心跳情况来选择最佳接入点。

调度系统会根据请求方的 IP 判断地域和运营商信息,对比各个边缘节点的所属区域、运营商以及节点本身的负载(如 CPU、网络带宽等)。

此外还考虑边缘节点到中心机房的链路情况(来自 WE-CAN),计算综合打分,并把最优的若干节点作为调度结果。

面对高并发场景,比如一个大型聊天室,活动初期往往伴随着大量人员的同时进入,此时就需要调度系统做出快速的反应。

此外,为了避免心跳信息滞后导致分配不合理引起节点过载,分配服务时还会动态调整负载因子,在保证调度性能的前提下,尽量做到分配结果的平滑。

由于状态数据有快速变化的特点(短 TTL),当某些核心用户或者某个客户报备了大型活动时,可以在短时间内进行相关资源的快速拆分和隔离。

服务层除了要支持海量客户接入、水平扩展外,还有一个很重要能力,就是需要提供各种各样的扩展性功能来适配客户各种应用场景。

第三方回调:方便客户干预 C 端用户的登录、发消息等核心环节,自定义实现各种业务逻辑(因为涉及到服务调用,而这个调用是跨机房甚至是跨地区的,为了避免第三方服务故障导致云信服务异常,我们设计了隔离、熔断等机制来减少对关键流程的影响);

聊天室标签:作为特色功能,支持消息的个性化分发(其实现原理是通过客户端登录时设置标签组以及发消息时设置标签表达式,来定义消息分发和接收的规则。标签信息会同时保存在服务层以及接入层,通过将部分标签计算下推到接入层,节省了中心服务的带宽和计算资源)。

一个IM聊天室系统,在逻辑上,各个组成单元都是可以水平扩展的,但是每个服务所依赖的物理机、交换机、机房带宽等都是有容量上限的。因此,能够合理地调配多个地域的多个机房,甚至是外部的其他资源,才能真正体现出一个聊天室系统所能支撑的容量上限。在我们的聊天室系统中,用户所有的接入点遍布各地机房,天然的将各地的资源进行了整合,所能支撑的容量上限自然高于单机房或者单地区多机房的部署模式。

当面临一个更大规模的聊天室,此时如果能利用一些外部的通用能力不失为一种合适的选择。融合 CDN 弹幕方案就是这样一种技术实现方案,它可以利用各大 CDN 厂商部署在各地的边缘节点,利用静态加速这样的通用能力来支持超大规模的聊天室消息分发。

基于融合 CDN 弹幕分发方案,其核心点就是弹幕的分发和管理,这是一个可选的模块,我们内部对此进行了封装,可以根据不同的业务特点来选择是否开启而不需要修改任何业务代码。

其他的海量消息则会进入 CDN Pusher,通过各种策略进行聚合后送达 CDN Source。

客户端 SDK 会采取一定的策略定时从 CDN 边缘节点获取弹幕消息。SDK 会聚合不同来源的消息,排序后回调给用户,App 层无需关系消息来自哪里,只需根据自己的业务需求进行处理即可。

并根据消息的类型、消息的优先级等,组装成以一个一个的静态资源,推给 CDN Source,等待 CDN 回源拉取。

在2020年8月,网易云音乐 TFBoys 的 7 周年线上演唱会就是一个聊天室大规模场景应用的典型案例。

在这场活动创造了 78w+ 的在线付费演唱会的世界纪录,其弹幕互动的实现方式采用了我们基于融合 CDN 弹幕分发方案。

在筹备环节,我们的聊天室系统达成了 20 分钟完成从 0 到 1000w 在线,上行消息 tps 达到 100w 的性能指标。

有兴趣的同学可以深入阅读关于这个案例的技术分享:《直播系统聊天技术(九):千万级实时直播弹幕的技术实践》。10、聊天室标签应用案例

但在超级小班课的模式下,常规的IM聊天室系统却存在各种各样的问题,不管是建立多个聊天室,还是单个聊天室进行消息过滤,都存在一些严重的问题。

可以灵活地支持聊天室消息定向收发、聊天室权限定向管理、聊天室成员定向查询等个性化功能,真正实现大型直播下多场景的分组互动。

我们规定的聊天室是由系统管理员来创建的一个固定的用户容器,这里分两类,一类是所有用户都可以自由加入或者离开这个群组而不用任何人同意;第二种是所有注册用户按照预定条件自动分到相应的群组里,不可以离开。聊天室的主题性比较强,由系统管理员固定,用户没有权限创建或更改。比如我们是做学校教育相关的,第一种是语文,数学这种固定的课题讨论小组,学生可以选择性的进入或者离开;第二种是班级这种固定的群组,学生注册成功后就会被分到这个班级中,并且不能退出。

除了即时通信产品之外,其他类产品也在尝试群聊功能,例如:去年3月份,美团App“内测”群聊功能;21年下半年小红书上线了群聊功能;马蜂窝、最右等等也都加入了群聊模块,希望通过群聊来增强自己的产品优势。

不同产品增加群聊目的各不相同,有些是给商家或创作者提供私域变现工具,增强整个产品的生态体系;有些为了提升产品的活跃,最终带来产品上留存的提升;有的只是把群聊当成一个纯信息传递的工具。

对于群聊产品的加入方式,一种是有一定的加入门槛,需要群主审核或者付费加入,这种群内的用户质量也相对较高;另一种无需审核即可加入,用户质量一般偏低,很多最后都变成了广告群。

群聊功能虽然好,但并不是那么好驾驭,特别是对私域变现、提升留存来说,还需要有多种其他因素的支撑,否则最后的结果是群里没有聊天、没人活跃,也就是我们常说的“死群了”。

今天我们就聊聊什么会影响群聊效果好坏,主要针对像小红书、最右等加入的群聊类型,像即时通信类性质的群聊,不在我们讨论范围内。

群聊是一个实时互动的功能,它对同时在线或能实时触达人数要求较高,否则很难聊起来,而对于粘性远不如微信、QQ的产品来说,就必须要有足够大的用户基数来保障。而人从哪里来?这就得依赖流量分发,创建的群能够曝光出去,并且用户感兴趣,这样才会有人加入到群里。

流量的转化转化效果,说白了就是群曝光了多少次,用户点击了加群多少次。转化率一个是跟推荐算法的精准度有关,能把群推荐给感兴趣的用户,用户跟群的匹配度越高,进群的转化也就越高,否则那就白白浪费了曝光机会。

再就是群的质量,曝光出去的群的质量应该有一定的筛选,将更多的曝光机会给到优质的群,否则即使这个群跟我很匹配,但是质量很差,那么用户加进去后也会再退群,而且对群产生了不好的印象。

用户加完群之后,接下来就要增加用户每天进群的频率了,只有用户多进到群里,才更有可能聊起来,一般分为主动进群方式、被动进群方式。主动进群最核心的就在于进群的入口以及路径了,入口明显程度、路径的长短决定了用户进群的次数。

因为对一个产品来说,本身每天的启动次数就有限,再加上目前我们给用户提供的功能都是过剩的,如果没有明显的入口或者操作路径较长,用户可能都把你给忘了,更不用说进到群里聊天了。

之前看到过一个产品,能直接把聊天界面悬浮应用右下角,用户不管进到哪个页面,都能一键进入群聊,就跟微信之前的文章悬浮球一样(现在改版了),就是为了缩短用户进群路径。

上面说了群入口以及路径对用户进群次数的影响,接下来就是应用内的消息提醒、应用外Push推送被动吸引用户进群的形式。应用内消息提醒跟进群入口是相辅相成的,明显入口配合提醒才会发挥更好的效果,最常见的提醒就是消息小红点,当然也有产品是全局消息提醒,不管用户此时在哪个页面都会看到新消息的提示。

而对于那些此时不在应用内用户,需要通过Push推送来触达,而影响Push推送效果的因素也有很多,这直接决定了你的推送能触达多少人,现如今很多产品的Push到达率其实都不高。

一是在于用户Push的开启率,如果不是特别重要的产品,大家一般都习惯把Push权限关闭掉,所以开启率是基础,否则根本没有触达用户的可能。

再就是即使推送到了用户手机上,用户也不一定打开,因为手机上的其他产品的Push也在跟你争夺用户注意力,所以这个时候推送的时机跟文案就显得更为重要。

当然从产品体验上来说,作为群聊功能也不适合来一条消息就提醒用户一次,因为毕竟是群的场景,大家有时候聊的其实跟我并没有关系,过多的提醒反而对我造成了打扰,因此需要在产品上制定相应的策略。。

要想保持群的持续活跃,只把用户拉进来还不够,还需要用心的维护经营,否则要么整个群变成死群,要么充斥各种乱七八糟的内容。维护好一个群跟运营一整个产品很相似,核心的思路都是一致的,那么要维护好一个群,都需要群主做哪些事情呢?

维护群内秩序:对用户发一些违规、广告以及与本群无关的内容,用户间谩骂、攻击等行为,及时处理解决。

新用户的拉新:通过各种渠道拓展群内用户数量,同时针对新进群用户进行欢迎,告知群规则同时提升新用户归属感。

带动群内活跃:通过各种话题(没话题也得天南海北的找话题),带动群内用户间讨论,培养聊天氛围。

群内用户管理:如果加入需要审核的群,群主还需要审核新加入申请,同时对群内不活跃的老用户进行剔除,保证群内用户新鲜度。

对于平台来说,自身能维护的群数量有限,更多的还是要靠广大的用户,既然维护好一个群需要做这么多事情,耗时又费力,所以如何能让群主愿意做这些事情就很关键。

有一部分群主完全是出于兴趣,一个人或者几个人共同维护一个群,但是无论从持久性、还是用心程度等等都还是差一些。

除了部分精神激励之外,要真正激发群主的积极性,最本质的还是要有物质激励,通过运营这个群可以让群主进行变现,获取收益,这样才能充分调用群主积极性,愿意花更多时间精力在这上面。

话题其实是大家聊天的引子,否则想说话也无从下嘴,不知道该说什么。上边说了群主、管理员要主动找话题、带动聊天,但群主、管理员也不可能一直盯着聊天页面,他们做的更多的也是冷启动时期的引导。最理想的状态还是:即使管理员不制造话题,大家互相之间也能聊得起来。

要达到这种状态,初期肯定离不开群管理人员的引导,但随着运营的深入,管理人员介入的应该越来越少,让用户间能自发的聊天。

再就是让群内成员之间尽可能的彼此熟悉起来,而熟悉的基础其实在于用户的身份,我需要先知道你是谁,了解的越多,信任度也越高,彼此产生话题机会也越大。

等群内成员熟悉起来之后,其实可聊的话题就不限于群内主题了,什么家长里短、生活趣闻、时事热点等等都可以成为聊天的话题。

群聊工具分两块,一是面向群主&管理员的基础管理维护工具;二是面向所有成员,方便大家更好的聊天互动。面向群主&管理员部分,主要方便对群进行管理,像群公告、进群欢迎语设置、批量剔除不活跃用户、撤回群消息等等。

面向所有成员部分,主要为一些互动工具,促进群内活跃,像群小游戏、群红包、表情包、群接龙、修改群昵称、等级成长体系等等。

除了像群公告、表情包等基础工具之外,其他功能增加需要循序渐进,群活跃是根本,否则群里都没人聊天,那加什么群小游戏、群红包都没有什么意义。

回到现实中来,目前任何一个产品的粘性都无法跟微信比,大家可以想想自己一天打开微信多少次,而打开其他产品多少次。在微信这座大山面前,想要通过群聊解决用户的需求,还是要寻找一些差异服务,否则用户为什么不去微信群里聊,还要“翻山越岭”来你这个产品当中来聊呢。

You May Also Like

More From Author