专访融云岑裕：复杂场景下，如何解放开发者？| Q推荐

作者 | 闫园园  

今年年初，语音社交软件 Clubhouse 突然风靡全球，短短数周内，各行各业名人和意见领袖涌入，一时间一码难求。不仅如此，Clubhouse 还一同带火了音频社交概念，基于语聊而衍生的多种社交玩法也层出不穷。

究其背后原因，主要因为疫情的影响，人们足不出户，刺激了各类网络社交、影音娱乐、远程办公、在线教育、远程医疗等需求的大爆发。人们把生活中熟悉的一幕幕，搬上了虚拟社交的“云平台”，形成了云办公、云服务、云娱乐、云聚会等云社交的新场景。

有史以来第一次，无论是 IM 还是 RTC，都开始进入以多样化场景应用为主题的新时代。但不同场景对通信技术的要求不同，带来的技术挑战也不同，需要的技术方案也不同。作为开发者，该如何了解即时通信领域的全新技术趋势，掌握相关技术栈呢？带着这个问题，InfoQ 特别采访了融云技术 VP 岑裕。

1 场景抽象：如何用四个人开发五天，上线语聊房业务

在新场景方面，一方面，疫情的推动，加速了各领域应用的线上化。另一方面， 无论是行业应用市场还是互联网市场，都出现了线上政务、远程庭审、无接触金融服务等多个新场景。诚然，场景的日趋多样化和复杂化加速了通信行业的发展，但在行业高速发展过程中，不可避免的对开发者的各项能力也提出了考验。

在常规场景化解决方案下，行业经历了两个发展阶段：

第一阶段是利用后端开源代码加前端开源代码做二次开发，难度大，学习成本高；

第二阶段只需在前端做二次开发，少了一端的接入，但对于开发者来说仍然需要学习底层知识，“技术虽谈不上多复杂，但是开发人员会花费大量时间在理解实时音视频的相关概念上，这大大降低了开发效率。”

因此，在今年 6 月，融云上线了语聊房 SDK 1.0，让开发者可以快速搭建一个语聊房。有多“快”？

岑裕给我们举了一个例子：“我们的某个客户团队，研发人员大概 3-4 人左右，在使用语聊房 SDK 的情况下，大概用了五天上线了这部分业务，而在我们没有推出语聊房 SDK 之前，另一个客户团队，研发人员 20-30 人左右，用 RTC 底层去集成，大概用了 20 天左右。”

目前单一形式的社交 APP 并不多，多数情况下都会加入语聊房的相关场景，基于用户的需求以及行业研究，融云推出了语聊房场景 SDK。场景化 SDK 方案大大降低了开发者的开发难度和学习难度，提高了开发效率，也直接推动行业进入了新的发展阶段，“此外，我们还推出了直播 SDK、呼叫 SDK，并将在未来推出更多热门场景 SDK，不断丰富场景化 SDK 的覆盖面。”岑裕向我们透漏。

体验使用场景化SDK搭建语聊房等互动社交场景可扫描下方二维码。

2 技术挑战：如何突破直播场景的人数限制及首帧体验

除了对全新场景做抽象，尽可能地服务开发者，降低开发成本。IM/RTC 服务场景的更迭，也将高并发问题再次提到了开发者的案头前。

对高并发支撑能力，比较“极端”的展示，是融云的“无观众上限”互动直播服务。

通常“无上限”服务只是个象征性的表述，即便是大型的公有云服务商，也无法真正实现“无限扩容、无限弹性”。对于 IM/RTC 行业而言，“无上限”服务更是个吓人的承诺，因为直播间不仅要承受与不同终端之间的 TCP 连接，还要支撑海量的弹幕转发服务、海量的礼物效果转发服务，可能要在信令控制层面同时控制几千万人。

前段时间，某香港明星出道 40 周年直播，抖音直播间观看人次破亿。此外，岑裕也为我们举了一个例子：

“最近，我们支撑了客户的一场直播，大概几百万人的级别。4 个小时之内，我们分发了 1900 亿条消息。”

支撑此类高并发直播，实现“无观众上限”互动直播的关键在于两点：

1、消息分发的机制和控制：说白了，就是实现消息分级体系，在融云被称为消息“白名单”。举个例子，礼物信息一般要全数分发，因为贵重礼物对用户身份的体现，本来就是直播业务的核心运营价值之一；相反，弹幕的分发是有选择的，一个观众不太可能在手机屏幕上同时阅读上千条弹幕，所以也没必要实现全量分发；

2、音视频处理：音频和视频的处理分发有两种处理策略，一种是追求实时性和交互的灵活度，这种一般采用分流分发的模式；一种是在实时性和带宽之间进行折中，进行合流分发。在业内，前者和后者的技术方案分别叫 SFU 和 MCU，在近些年的 RTC 低延迟直播，会将两者结合起来用，比如合完流再推送给主播。但是近来由于疫情推动，超大会议室和小班课、语聊房等场景下，进一步模糊了两者的技术边界。音频的部分，除了分流全分发和合流完再分发，还可以在服务上，对所有上行音频的音量进行逐节点权重选路再分发，兼顾实时性和带宽。视频的部分，常用的合流分发会带来一定的延迟，分流分发交互更灵活和延迟较高，但是人数多时带宽占用会较大。在直播时，这两种模式可以一起使用，并支持随意切换。在分屏较多时，通过提前订阅，翻页显示几乎无延迟；通过链路复用和内容分层，跳页显示延迟在 200ms 以内。

除此之外，直播首帧显示也是重要用户体验指标之一，也是作为开发者需要重点关注的点。融云提供的低延迟互动直播是基于 RTC 技术做的直播推流，它不依赖 CDN 推流，首帧显示上延迟在 300ms 左右。“首帧显示这件事我们同样分为几个维度来做。”融云技术 VP 岑裕向大家介绍：

第一，链路层面。在保证全球覆盖的前提下，融云结合所有运营商接入节点、客户端物理特性等，帮助用户在第一时间选择到最正确的链路，这也是基于融云历史数据不断去学习的过程；

第二，音频和视频的对齐。针对在不同情况下进行音频首先下发，包括提前多少，视频如何跟随调整以及调配链路首帧比例，融云会针对不同场景相应做策略上的调整；

第三，首帧 buffer 的设计。传统 CDN 链路涉及直播地址分发、GOP buffer 数据请求等一系列耗时操作，无法满足用户对于“打开一个直播，希望立即加载出视频画面”的需求。融云在 RTC 技术上实现了客户端动态缓存，并配合服务端对关键帧请求处理，把 buffer 变成静态加动态的过程。但关键帧请求过程会对网络有一定压力，所以在此过程中，融云又对关键帧请求做一定的限频，和静态的 buffer 配合形成动态的首帧 GOP buffer 缓存，从而提高首开效率；

第四，针对不同客户场景提供不同方案。融云在服务器端提供大小流或者是分层编码方案，针对不同客户场景提供不同选项，从而保证客户依据自己的业务情况选择不同的解决方案；

第五，首帧数据监控。融云打造了一套完整的体系监控全球网络首开的质量以及具体数据情况，并依据数据情况针对不同地区网络情况进行优化。

当然，支撑高并发直播的“内功”，还是分布式架构的设计、分布式事务的处理能力。作为 IM/RTC 服务提供者，还是要优先保证自身基础设施不被流量压垮，才有余力考虑消息的分级、合并、渲染和分发。

3 WICC 与通信云的未来

服务开发者，除了提供高标准的技术方案以外，融云也在探索更多形式，全球互联网通信云大会（WICC） 便是其中之一。

聊到 WICC，岑裕表示“举办 WICC 的初衷是，我们希望为开发者提供一个平台来和大家交流，帮助他们看清通信技术的发展的趋势。”同时，他还为大家介绍，每届大会都会为大家带来技术分享，在刚刚过去的广州站，WICC 为各位开发者设立了两场技术分论坛：“社交分论坛”、“出海分论坛”，是对以上场景化趋势的实践解读。

在社交分论坛中，融云场景化研发负责人臧其龙带来《融云社交场景化 SDK 探索》主题演讲，介绍了融云社交场景化 SDK 的发展规划；积目风控负责人徐铭带来了《陌生人社交生态治理实践》主题演讲，介绍了积目在对抗网络诈骗类黑产中的防控思路与实践经验；StarMaker 广州研发负责人林瑞群带来了《StarMaker 音视频直播架构演进之路》主题演讲，从后端架构、海外 CDN、直播协议等方面为直播行业开发者提供了自己的经验。对于身在社交场景的开发者而言，该场分享是必听的。

在出海分论坛中，荔枝运维总监熊振带来《全球化业务基础设施建设》主题演讲，分享了出海业务在基础设施上的技术难点，并为各位开发者带来了解决方案建议；阿里云智能视频云高级技术专家邹娟带来《面向全球竞争，阿里云视频云的最佳技术实践》主题演讲，分享了阿里云视频云的演进路线与技术架构；LiveMe 技术总监邹义鹏带来《跨境支付体系的演进之路》主题演讲，分享了跨境支付体系的搭建实践过程，并给予各位开发者实际案例讲解。出海基础设施层和架构层涉及的问题比较多，这一场分享可以让音视频领域开发者补充自身技术栈。（关注融云公众号：RongCloud2014，回复 WICC，可以领取现场讲师PPT和直播回看链接）

两个分论坛都覆盖了当下通信云最前沿的技术知识，某种意义上，也向开发者描绘了行业未来的整体趋势。谈及通信云的未来，“我们目前看到的场景中的需求，我认为还是在 4G 或者说 4G 末期积累下来的，至于 5G 下应该如何走，我觉得大家都还处于探索阶段。”岑裕说道。

对此，融云也针对行业目前的现状提出了应对挑战的发展规划：

第一，在技术前沿探索方面，融云将不断挖掘新的场景下的需求，通过和 相关前沿技术厂家的合作等方式来不断满足新场景下的新需求，为开发者减负赋能；

第二，在推动整个行业方面，融云将不断总结自己的通信云领域经验，并将经验传递给整个行业。具体包括：未来将会与产学研界加深合作，进一步明确、推进相关行业标准的建设工作；同时会支持、推进WICC等行业各类主题峰会的开展；同时将加强开源文化、技术社区的建设，逐步推动完善行业生态。