首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如果微博、贴吧变成即时聊天,程序员该怎么办?

刷微博是许多人每天的“例行指部锻炼”,一扫一划,就能评论热点话题,订阅热门动态。当然,也有不少人对明星不感兴趣,转而去刷 Reddit、贴吧、虎扑、知识星球或是其他 BBS 社区。对于 90、80 后来说,这个被“刷”的对象可能是曾经的即刻、糗百,天涯、猫扑。

可以说,“聚众看热闹”是人类永恒不变的爱好,但我们看热闹的方式却并不丰富:要么刷 BBS 社区,要么扎进社交软件的群聊。

不知你有没有想过,如果将二者合二为一,让微博、贴吧这样的社区,全部变成即时聊天,各个博主、吧友的动态,全部以群聊消息的形式推送给你,你又可以即时地回复、互动,甚至和这些博主、吧友连麦视频,情况会是怎样的?

这将是一个超级社区,或者更准确地说,这将是一个无人数上限的“超级群”。

可是,这个“超级群”,实现起来将非常困难。在程序员看到产品设计的那一刻,就有精神崩溃的风险。

真正的服务器压力

“崩溃”主要源自技术挑战,更确切地说,是服务器面临的巨大的读写压力和存储压力。

微博曾出现过几次著名的故障:赵丽颖领证、关晓彤官宣、王宝强离婚。在调侃微博崩溃的各种网络段子背后,我们能看到的是,一个架构师面对一条微博下几秒新增数万条评论,服务器压力瞬间暴涨几十倍的无奈身影。

与此类似的是直播弹幕的分发场景。无论是近期的视频号五月天跨年演唱会,还是 B 站春晚,弹幕过百万轻而易举(“二零一九最美的夜”bilibili 晚会弹幕超过 170 万条)。

理论上讲,每一条弹幕都要向直播间内观众做全量分发。以五月天跨年演唱会为例,当晚有 1,680 万人在线上观看,如果保守假设当晚共发送 100 万条弹幕,那么单是弹幕的写操作,就至少要执行 16,800,000 x 1,000,000 次。因为实际支撑有困难,又要顾及用户的屏幕根本无法同屏显示上万条评论,所以弹幕的转发一般都是降级处理 —— 只分发一小部分给你看,其他的略过。

而如果将微博评论、直播弹幕,全部“群聊化”,问题会更加恐怖。“群聊化”后,产品形态成为“超级群”,问题进入 IM 场景,可以做相应的流控,但不能丢弃信息。且无论是微博评论还是直播弹幕,对信息上下文的关注度都不高,但这恰恰是 IM 关注的重点。

可以说,至少在 3 年以前,能够系统解决这些问题并将其打磨为一个成熟产品的人不多。直到 2018 年,国外出现了一个名叫 Discord 的软件,网友才体验到了这种全新的社区形式。Discord 最初只服务于游戏语音连麦,但很快演化为一个超级社区。2021 年,据 CNN 报道,Discord 已有超过 1.4 亿名注册用户,微软正在谈判以 100 亿美元收购它。而在 npr 的采访中,美国芝加哥地区的一名 18 岁少年表示,他 2020 年的大部分时间都在 Discord 上闲逛,并将其形容为“Reddit 和群聊的混合体”。元宇宙的支持者们也惊奇地发现,所谓的“Discord 模式”,不就是未来元宇宙虚拟社区的基础模式么?在元宇宙里,总不能先加个 500 人的群再开始聊天吧。

抛开模式创新不谈,如果要深究 Discord 的技术核心,恰恰就是我们前面所描述的“超级群”。而在 2022 年 1 月 11 日,融云也发布了一款名为“超级群”的 PaaS 产品,以此为例,我们或许能搞清楚,这种带了点科幻色彩的未来社区,究竟是如何实现的。

超级群的设计架构和实施方案

超级群的底层技术支撑能力,可以简单分为两部分来谈,分别是超级群业务能力、IM 底层技术能力。

超级群的业务能力,在架构设计层面共分为四层,分别是加速网络、接入层、核心服务层以及底层存储。之所以要做这样的划分,是为了充分利用融云自身的统一加速网络机制, 保障网络连通性以及连接质量,让超级群可以根据自身业务需求, 在连接通道的基础上,专心实现更高效的业务交互。

在融云,传统的群消息建立在收发模型(收件箱、发件箱)的基础上,独立维护会话列表和历史消息存储。从用户发送群消息,到群内 (成员数量为 N ) 接收群消息。整个过程将产生四类消息:

  1. 一条发送方发件箱记录;
  2. N-1 条接收方的收件箱记录;
  3. 1 条群历史消息记录;
  4. N 条会话列表记录。

消息存储投递流程为:

终端 A -> 发送消息 -> 接入服务 -> 群管理 (群消息上行) -> 分发 -> 群聊消息分发节点 -> 消息节点 -> 通知拉取 (直接发送) -> 终端 B/C/D

在这样的流程下,消息分发节点与消息节点交互密切,通常合并部署。同时,消息节点也会直接触发收件箱、发件箱的消息存储。

但在超级群的场景下,群成员数量理论上是无上限的,无论是消息的上行、下行,还是消息在存储层的写入和查询,都将导致空前的服务承载压力,以上方案因此不再适用。于是,融云在现有连接机制之上, 针对超级群做了交互设计优化,设计了两种分发模型: 分别叫做消息驱动模型和会话驱动模型。

对于消息驱动模型而言,消息节点将不再直接触发收件箱存储操作。融云特别设计了一个环状消息队列, 通过内存搭配外部缓存的方式,完成最近 N 条消息的缓存, 并通过对消息存储模型优化, 完成热点数据的快速读写。对消息的下行,则做聚合处理,保障客户端能够处理大量消息变更通知,并且尽量减少交互次数,也让消息的拉取变得更快速、精准。

会话驱动模型则是在消息驱动模型的基础之上, 做进一步的优化。

首先,消息节点不会再通知客户端拉取消息,而是通过触发实时会话, 通知客户端会话发生变更。而这里的实时会话,则是实现客户端订阅机制的基础, 让客户端可以只获知已订阅的会话变更消息,从而进一步缩小需要处理的会话以及消息数量。

其次,客户端在收到会话变更通知后, 会根据通知,判断是否要发起会话消息查询操作。如果是,则按照一定的机制查询最新或特别范围的消息。

除消息分发层面的优化外,对存储的优化也非常关键。融云超级群的所有服务,均按照业务维度进行一致性哈希分发。比如,上行服务可以按照群 ID 或 channel ID 做哈希,分发服务可以按照接收方 ID 做哈希。核心目标在于确保热数据的命中,优先使用内存、LRU 缓存、再使用分布式缓存、磁盘冷存储。

APP、群组、信令级别的流控,则是另一重保障,它将一个看似无边界的产品需求,转化为了可琢磨、可实现的技术问题。因此,虽然流控不是超级群实现方案的重点,但依然不可或缺。

整体而言,融云的超级群构建方案可以分为四个要点:

  1. 弱化原发件箱 / 收件箱模型, 尤其是收件箱, 以极大提升读写性能,避免因 I/O 而产生的性能瓶颈;
  2. 通过"变更通知"聚合等方式,尽量减少终端与服务端交互次数,减少因网络交互而产生的延时;
  3. 设计专用数据结构 (环形队列), 并设置内存、外部缓存等多级缓存结构, 提升超大规模下的消息分发存储速度, 并提供快速查询能力;
  4. 通过会话驱动模型, 进一步减少网络交互过程中,待传输的数据量。

那么,有了以上方案,是否就可以构建出一个“超级群”呢?显然还不够,在超级群的场景之下,IM 底层技术能力的积累可能更为重要。

IM 底层技术能力与网络层性能优化

如果要对融云超级群所依赖的 IM 基础能力做一个解读,恐怕一本迷你书也写不完,其粗略架构图如下:

但好在,关于超级群,我们只需重点关注其在网络层面的依赖即可。对于所有的 IM 服务而言,底层网络的加速能力都是关键。融云的底层服务网络全称是融云全球通信网络 (以下简称为 SD-CAN,Software Defined - Communication Accelerate Network) ,集合了 BGP anycast、SD-WAN、对等连接、动态 CDN、智能 DNS 等多种网络加速方式。

对于超级群来说,SD-CAN 允许客户端 SDK 通过查询和探测确定地域和运营商以及最后一公里的网络情况,将用户就近调度到融云的网络边缘节点, 边缘节点依据信令的请求目标地址投递到路由节点,完成数据汇集,再由路由节点识别并转发到对应的数据中心。

举个例子,如果北美用户要访问中国国内的数据中心,典型的两条路径是:

  1. 北美用户 -> 直接连接 -> 国内数据中心接入服务 -> 业务服务;
  2. 北美用户 -> anycast -> 北美数据中心边缘节点 -> 北美数据中心路由节点 -> SD-WAN/ 对等连接 -> 国内数据中心路由节点 -> 国内数据中心接入服务 -> 业务服务;

客户端会按照服务下发的策略,做并行探测并同时建立连接。对最优链路的选择,依赖于建连延迟、心跳间隔、链路发送接收状况等信息。服务器也会定期检查连接的健康度,主动关闭长尾连接,结合客户端的重连机制,一起保障对最优链路的调用。

PaaS 产品接近完备,或将填补元宇宙到来前的空白

除了技术实现,挑战也出现在产品设计层面。

由于超级群中的信息量太大,需要支持将群分割为不同的频道,类似传统的 topic 或 channel。即使相同的群和群成员,通过不同的频道,仍然能将会话、消息、未读数分门别类聚合。用户可以更关注自己感兴趣的部分,提升用户黏性。

这也反映了用户在超级群场景下的真正需求:我或许会希望在一个有数十万网友的超级群中建立社交关系,但却不希望被数十万消息打扰生活。

此外,对于融云来说,超级群是个 PaaS 产品,这意味着要为客户端留下充裕的可定制空间,在不同的场景,对信息推送的方式、逻辑、频率都有不同的要求。同时,将信息和聊天结合的场景,一般都有多端的需求。不同的平台,比如 Android、iOS、Web 等,在海量消息的网络请求和存储方面都有不同的技术特点,甚至同平台不同厂商的推送通道特性也不同,这些都需要一一考虑。

最近几年,社交领域的新兴公司新增不多,整体增长呈下降趋势。这一方面是因为流量向头部高度集中,挤压了新玩家的空间;另一方面也是因为缺少新模式,大家仍在围绕存量用户做竞争。

超级群这一新应用形态,可能会对社交软件整体的发展,产生巨大的牵引作用,从而带来新的机会。同时,PaaS 产品的完备,也标志着实现产品创新的技术基础已经夯实,这或将在产品层面,填补从微信、语聊房迈入元宇宙的最后一段空白。

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/iyzrBRoc2qPwWvFOTdJj
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券