导读：

网易云信新晋的 IM 顶流产品「圈组」出道后获取到了极大的关注，很多云信的客户在接入的同时对于「圈组」的底层技术细节和原理也十分关注，为此，咱们决定推出云信「圈组」相干的系列技术文章，分享网易云信在「圈组」技术设计上的一些思考。

文|曹佳俊 网易云信资深服务器开发工程师

一、技术选型

在介绍「圈组」的技术细节之前，咱们先剖析一下圈组的技术特点（理解「圈组」可浏览上面两篇文章：行业洞见丨 Discord 狂奔的背地与网易云信「圈组」的长期主义 或 正式出「圈」丨网易云信圈组的近谋与远虑），「圈组」产品最大的特点是什么？首先是 server/channel 的二级构造 ；其次是构建在二级构造之上的 大规模社群（单个 server 数十万甚至上百万成员），以及应用简单的身份组零碎来治理如此规模的社群组织和成员。

那么对于这样一个新鲜的 IM 零碎，在技术上应该如何实现呢？

一种简略的思路是 革新已有的 IM 零碎，对于「圈组」这样的类 Discord 社群，第一个思路是拓展咱们的群组性能，猛一看在很多方面的确挺像的，咱们做了个简略的比照：

​

从下面的表格能够看到，「圈组」和群组最大的不同，一个是 容量的区别 ，一个是 二级构造。 其余的诸如身份组、个性化推送策略，仿佛只有适配的做一下就能够了，那么是不是只有想方法晋升一下群组的容量，再在业务层封装一下二级构造就能够了呢？答案显然是否定的，或者至多说基于群组去扩大不是一个很好的想法。

首先是 二级构造 ，在类 Discord 的二级构造中，成员的治理在 server 层，而 channel 成员是继承自 server 的，而且在 channel 之上还有很多可见性的配置（ 云信「圈组」提供了黑白名单机制，Discord 则提供了查看频道权限），在这种机制之下，任何 server 层面的成员变动，都可能影响全副或者局部频道的成员列表；面对这种简单的构造，群组有两种思路去实现，一种是 N 个群，逻辑上隶属于同一个 server；还有一种是一个群映射为一个 server。不论哪种形式，先不说音讯投递这块的逻辑，仅成员治理上逻辑的耦合和交错的复杂性，足以劝退任何人。

其次是 容量 ，惯例的群组的容量个别只有数百，最多能够扩大到数千，对于群组成员的治理，咱们个别采取 全量 + 增量 同步相结合的计划，客户端和服务器映射到雷同的群组镜像（群信息 + 群成员等），此时很多操作，例如群成员的展现、检索，音讯的艾特等，都能够基于纯客户端进行。而「圈组」要求几十万甚至上百万的容量，显然客户端无奈一次性获取到所有成员，如果你一次性退出多个 server，那成员的数量将更加收缩。因而在「圈组」这种大规模社群的设计中，很多逻辑都会转向云端，此时不论是 SDK 还是服务器，均须要批改原有的设计逻辑。

此外，大规模社群带来的是音讯爆炸 ，在原有的群组设计中，假如一个人同时退出了 1000 个群，那么这 1000 个群内的所有音讯均会在第一工夫下发给给客户端，然而在个别的业务场景中，不会所有的群都同时沉闷，假如这 1000 个群变成了 1000 个服务器 / 频道，作为一种社群组织，同时沉闷的可能性将大大增加，而且每个服务器 / 频道的人数远远超过一般的群组，叠加之后带来的音讯爆炸景象在原有的群组体系中将带来极大的压力，压力包含多方面：首先是 海量音讯的存储压力 ，其次是海量音讯在线播送 / 离线音讯推送带来的 带宽和服务器压力，以及客户端在面对大量音讯冲击时如何无效地承受和正当的展现。

除了容量和二级构造，包含 身份组、成员治理、个性化推送策略 等等，是否真的适宜在群组中增加这些简单逻辑呢，强行绑定在一起会不会既没有一个好用的类 Discord 平台，也使得原始的群组性能繁冗，反而升高了易用性呢？

通过下面的一些剖析，咱们根本能够得出一个论断，在已有的群组根底上扩大来实现一个类 Discord 性能的社群，显然不是一个很好的思路，那么还有其余“捷径”吗？聊天室也是一个潜在的选项，聊天室的一大特点就是 反对超大规模同时在线（参考文章：网易实际|千万级在线直播弹幕计划），容量仿佛曾经不是问题，然而当思考增加其余一些强社交关系的个性时（如成员、身份组等）就显得有点尴尬了，聊天室自身就是来去自如的一个凋谢空间，这个和圈组的产品自身定位互相冲突的，因而基于聊天室扩大的计划也根本 pass 掉了。

二、技术难点

基于上述种种的思考和探讨，最终网易云信抉择脱离已有 IM 体系，从零研发一套全新的社群计划「圈组」，「圈组」不是一个简略的 IM 性能，而是一套 能够独立运行的 IM 零碎，通过下面的探讨，置信大家对「圈组」自身的技术特点和难点也有所了解，能够演绎为以下几点：

1. 二级构造下成员无下限的社交关系零碎设计。
2. 超大社群下音讯零碎设计。
3. 简单高效的身份组零碎设计。

三、「圈组」音讯零碎技术分析

本文将针对上述三点之中的第二点：超大社群下的音讯零碎设计，分享咱们的一些技术设计原理和教训。

（一）「圈组」整体架构

下面展现了「圈组」服务整体的架构，能够看到 整个「圈组」服务是一个分层的架构 ，首先是 接入层 ，包含 LBS 服务和长链接服务器以及 API 网关，对应客户端 SDK 和用户服务器；前面是 网络层 ，包含大网 WE-CAN 和协定路由服务；其次是 服务层 ，划分了多个服务模块，每个模块都包含多个微服务；最初是 基础设施。

（二）音讯零碎架构

这其中和音讯零碎相关联的包含接入层、网络层、以及后端的登录 / 订阅 / 音讯 / 检索等模块，根本架构如下：

下文咱们将对音讯零碎中各模块别离开展介绍。

（三）音讯零碎技术细节

音讯零碎中第一个要探讨的点就是 音讯的存储和散发形式，包含在线播送、离线推送、历史音讯三个维度。

• 在线播送

对于个别的群组来说，在线播送的个别过程是这样的：顺次查问群组里的所有人的在线状态，如果在线，则将音讯发送给对应的长链接服务器。显然这种机制无奈复制到「圈组」，因为在 「圈组」的一个服务器里可能存在超过 100w 的人；此外，聊天室的播送模式也不能间接复用，因为在聊天室架构中，每个长链接映射到一个聊天室，因而当你登录到某个聊天室的时候，你只会收到该聊天室的音讯，而对于「圈组」来说， 每个用户会同时退出多个服务器 / 频道，而且会同时收到多个服务器 / 频道的音讯。

针对「圈组」的上述特点，云信设计了 音讯订阅模式 ，也就是用户登录之后，须要订阅感兴趣的相干服务器 / 频道，服务器会记录下这个订阅信息，当有新音讯的时候，服务器通过订阅关系（而不是在线状态）查问到须要播送的列表， 通过这种形式就不再须要遍历服务器 / 频道里的所有用户；

然而当一个服务器 / 频道里在线人数十分多的时候，这个订阅关系依然是微小的，为此云信设计了一种 两层订阅模型 ，所有的订阅关系会保留在长链接服务器上（QChatLink/QChatWebLink），同时长链接服务器会定时发送心跳给后端的订阅服务器， 心跳信息相比原始的订阅信息会大大简化，比方长链接服务器上会记录账号 A 订阅了某个频道 A 的音讯，如果有 1w 个账号，则有 1w 条订阅记录，而心跳信息里只会上报有 1w 集体订阅了某个频道 A 的音讯，具体的账号列表则被精简掉了；当一条音讯须要播送时，音讯服务会拜访订阅服务，获取到该服务器 / 频道被订阅的长链接服务器列表，并顺次给该列表中的长链接服务器发送音讯下发告诉，长链接服务器收到告诉后会依据订阅详情再播送给所有客户端。

此外，咱们还提供了 多种订阅类型 ，当你十分关怀某个频道音讯时（比方页面正停留在该频道），此时你能够订阅该频道的音讯；对于其余频道，如果你仅仅须要晓得该频道有多少条未读音讯（或者有无未读音讯），则能够抉择订阅该频道的未读计数（或者未读状态），此时服务下发时仅会播送精简的音讯体用于保护客户端未读计数，并且当未读计数达到肯定阈值之后（比方 99+）， 服务器能够抉择不再下发任何告诉音讯而不影响用户体验。

通过上文介绍的音讯订阅模型，极大地提高了 超大型的圈组频道 / 服务器音讯在线播送 的效率，升高了服务器压力；除此之外，咱们还设计了针对小型频道的非凡策略，对于小型频道，即便不订阅，服务器也会下发音讯告诉给频道里所有人，从而加重端侧音讯订阅模型的保护老本；针对音讯订阅机制自身，后续咱们也会依据不同的业务场景，提供更多 一站式的策略来帮忙升高接入老本，晋升整体的易用性。

• 离线推送

在强社交的场景下，离线推送对于 维持用户粘性 + 晋升产品体验 有很大的作用。从技术角度看的话，次要解决 2 个问题，第一个是 超大型服务器 / 频道的音讯推送的效率问题； 另外一个是 提供足够丰盛的推送策略来帮忙 C 端用户，防止被适量的推送音讯给打搅。

针对第一个问题，云信「圈组」针对不同规模的服务器 / 频道采取了不同的策略，对于 小型频道 ，采纳相似于群组的音讯推送模型；而对于 大型频道 ，对于每一条须要推送的音讯，会依据指标用户的 ID 进行工作分片，多个节点并行操作，进步推送效率。此外分片会采纳 一致性策略，保障单个用户固定为某些节点，从而进步缓存命中效率。

针对第二个问题，云信「圈组」的推送策略能够用以下几句话来形容：

• 既关注促活，又保障不打搅
• 大型 server 是游乐场，只推送与用户相干的重要音讯（如 @音讯）
• 小型 server 是与敌人相处的小天地，反对音讯的全副推送

并且将来用户还能够 自定义音讯的高低优先级 ，并搭配 不同的推送配置（如不同的免打搅配置等）：

• 历史音讯

历史音讯的存储在「圈组」的场景中也须要一些特地的设计。同样以群组为例，一般来说音讯的存储形式有两种，写扩散和读扩散 ，在小型的群组或者多人会话中，写扩散模式能够简化设计，然而当群组规模扩充到肯定水平（如万人群），读扩散就成了抉择，而对于「圈组」这种单个服务器可能上百万人的“群组”中，除了惯例的读扩散之外，咱们还设计了 多级缓存的构造 来应答海量的读申请，根本的存储架构大抵如下：

音讯的存储次要包含两局部，一部分是 音讯自身 ，还有一部分是 未读计数。

首先是写入，对于上述两者，咱们都会应用 中心化的缓存服务器 来存储最近的数据，并应用 异步 + 批量 + 聚合 等伎俩，通过 MQ 异步落库，从而均衡 写入效率 （单条写入性能低）和 写入读取提早 （异步写入有提早）的问题，并且针对不同数据类型的特点，咱们也抉择了不同的存储计划（历史音讯应用分布式工夫序列数据库，未读计数应用分布式 k-v 数据库）， 最大化地晋升音讯存储和查问的性能和效率。

有写就有读，针对读取操作，所有最近的音讯和未读计数均会存储在中心化缓存中，并通过 先进先出和缓存过期 等不同的策略来确保缓存中存储的永远是最新和最热的数据；此外对于音讯 ID 和音讯内容自身，中心化缓存中也会有不同的数据结构和过期策略，来均衡缓存命中率和缓存容量耗费；当缓存过期了，如果有关联的读写申请，将会触发缓存的重建，以保障缓存的命中率始终保持在较高水位；最初，当有高频的读申请，还会触发热点 cache 的检测，并将一部分读申请下沉到各个计算节点的内存中，以应答突发流量的冲击。

上述针对「圈组」的特地设计，音讯存储系统能够应答几十数百人的小型圈组频道，也能够从容应对上百万的超大型频道。

• 特色性能

说完了音讯零碎的外围存储和散发模式，「圈组」的音讯零碎还提供了很多额定的特色性能：

• 音讯更新： 所谓的音讯更新是指音讯发送之后还容许批改，音讯撤回和删除被认为是音讯更新的一种非凡状态，这在治理一个大型社群中的音讯时有着重要的作用。
• 音讯互动 （行将推出）：「圈组」提供了比 Discord 的音讯回复更强的 thread 聊天性能，不同于子区是独自开拓一块空间，thread 聊天能够让你在简单的音讯流中 主动筛选 出对于某一个话题的所有关联音讯。「圈组」也提供了 快捷评论 的性能，你能够给一条音讯增加各种自定义的表情，这在大型的频道中简直是刚需，因为你再也不必忍耐音讯爆炸了。云信针对大型频道的快捷评论也做了非凡的优化，当一条音讯取得大家的统一青睐时，频道里所有人都能够给他点一个😊或者👍，数量不设下限。
• 音讯检索（敬请期待）：「圈组」的检索系统也是一大特色，音讯检索天然是其中重要的一环，音讯检索将助你在繁冗的音讯流中寻找到你想要的音讯
• 第三方回调和抄送： 这充分体现了「圈组」作为云信 PaaS 平台产品的一大特点，通过第三方回调和抄送，你能够在各种各样的操作（如发消息、拉人踢人、批改信息等）的 before 和 after，植入任何你想要的逻辑，譬如机器人、内容审计等（当然云信也有平安通一站式内容平安解决方案，能够按需抉择）。

四、总结

说了这么多，云信「圈组」作为一款全新设计的产品，没有任何历史包袱的限度（然而却能够充沛排汇历史长处），你能够应用它构建一个类 Discord 产品，或者任何你想得到的社交 / 娱乐 / 游戏产品，欢送大家抉择。

作者介绍

曹佳俊，网易云信资深服务器开发工程师，毕业于中国科学院，硕士毕业后退出网易，负责云信 IM/RTC 信令等业务的服务器开发。专一于即时通讯、RTC 信令以及相干中间件等技术，是云信开源我的项目 Camellia 的作者。