从最初的三个按钮,到一年功能迭代优化超过20000次。
腾讯会议这款上线之初仅支持5万日活的产品,到如今稳定支撑数亿的用户量级,背后的设计架构、技术性能,何以扛住如此大规模的流量洪峰,从而保障用户的流畅体验。
今天,我们就揭开这款国民级产品背后的技术之道。
这是腾讯会议的创业史,更是关乎整个音视频行业的技术进化史。
网络毫秒级切换背后的杀手锏
“稍等1分钟,刚进电梯……”
“不好意思我在高铁上,刚才没信号了。”
不知道从什么开始,我们的会议已经不局限于会议室本身了。
连接的稳定性,对于会议这样的APP来说,重要性甚至超过了功能的丰富性,但在现实场景下,网络环境往往极为复杂。
比如从家到电梯,再从电梯到车库,如果所在的企业有海外业务, 经常会经过边境口岸,网络频繁切换成为常态。
即便在高铁上,你以为全程连着同一个网络,实际上接入地可能早已随着火车的前进切换了好几处/轮。
在C端场景下,用户对连接时间或者延迟的容忍度通常高于B端场景,比如我的手机没有信号可以等到搜索可用网络,但是在企业环境开会时,几秒钟的掉线或卡顿可能就让你错过一个极为关键的信息,这就对平台的稳定性有着近乎苛刻的要求。
作为会议技术团队的一员,黄星所在团队的目标是最大限度保障用户使用会议的稳定性。随着越来越多的个人和企业选择腾讯会议作为办公日常,他们发现, 由于用户使用习惯, 办公设备, 工作环境等差别,网络传输面对的挑战也与日俱增。
按照传统理解,网络的问题,要么是运营商的信号问题,要么是手机的通信问题,但腾讯会议还希望做的更多。“对于网络来说,核心突破点有两个,一是感知网络环境和网络变化,二是适应网络环境和网络变化。在会议场景下,绝大部分遇到的体验问题都是网络变化造成的,于是我们做了大量工作来争取网络主动权”,黄星说。
通常情况下,当网络切换或者连接超时,最常见的处理方式是等待网络重新连回去,但是这会导致用户很被动,同时要忍受一度达到几十秒甚至几分钟的失联状态。
为了解决上面的网络难题,腾讯会议开发了一个使用频率非常高,但用户却几乎无感知的能力:腾讯会议快重连。
用通俗的话来说,就是当腾讯会议感知到网络切换时,就会触发快重连机制,基于会话代理和会话池的管理方式“另谋出路”,瞬间完成网络的重定向,同时还不损伤原有会话的音视频。
这就要求会议一旦发现网络发生变更,首先要能发现,然后快速完成切换。
拆开来看,背后其实有多个难题亟需解决,本地网络变更的感知能力、客户端地域变动的感知能力,以及快速的本地会议切换能力。
说起来简单,但如果考虑到硬件的适配、系统的兼容,背后的复杂度难以想象,而且在市场上已经拥多有会议产品的前提下,用户的体验甚至成为产品能否脱颖而出的关键,正所谓高手过招,胜负往往就在毫秒之间。
首先,要对网络连接情况“当机立断”。为此,腾讯会议采用了全新的方式,开创了一套灵敏的网络感知机制,可以基于操作系统内核能够更加直接、精准地感知本地网络的切换,同时,后台也会根据客户端反射IP和实时IP地域数据库,共同判断客户端最佳接入点,实时决策网络切换。
而在切换的时候,腾讯会议基于会话代理和会话池的管理方式瞬间就完成网络的重定向,还能不损伤原有会话的音视频,最大程度地做到了“纵享丝滑”。
(电梯环境对网络的要求极高,这也成为团队测试网络细微变化的天然场景)
为了模拟真实的生活场景,技术人员就以经常出入的电梯作为测试环境,因为腾讯的电梯白天人来人往,员工上班进进出出很多,塑造了一个天然的真实场景。
黄星回忆,有几天几乎就在电梯上度过,因为需要不断的调整参数,不断的对网络细微的变化做实验,少说也乘了上千次电梯。谈到那时的情形,他现在依然“心有余悸”。
因为乘坐的次数太多,以至于大厦的保安认为他们是来捣乱的。
除了电梯,为了测试腾讯会议在人流量密切场所的网络效果,他们把目光锁定在深圳北站,这里每日的客流量超过百万,人员密集、网络环境复杂,是理想的“实验场所”。
有一段时间,黄星和宇锋、景禧等小伙伴乘坐一辆小车在深圳北站附近转悠,时不时还下车,拿着实验设备在广场上测试,因为形迹可疑,险些被公安民警请到警卫室喝茶。
正是源于复杂场景的频繁实验,以及对网络切换的苛刻要求,腾讯会议目前已经能够做到毫秒级快速切换网络,而行业还停留在“秒”的水平。
这就好像以前只有一条公路可以运送货物,公路一旦出现走不通的情况,只能等待把路修好疏通。如今,一旦公路出现拥堵或者走不通,会议立马可以提供高铁甚至飞机的选择,保障货物更快速送达目的地。
在纯粹的B端场景下,腾讯会议作为后入者,如何打磨每一个细分领域和场景,让企业和组织的数字化沟通更加简单、智能、高效,都不断地考验着会议团队的专注和耐心。对会议来说,这更是一场马拉松长跑。
一年功能迭代20000次背后
用户体验起来简单的技术,背后反而是最复杂的。
为了优化用户体验,腾讯会议技术团队常常进入一种不疯魔不成活的状态。
做过App的人应该深有体会,一款App不仅需要适配不同的客户端,还需要适配不同的操作系统。比如你是苹果,我是华为,他还是OPPO,操作系统更是囊括了Android、iOS、Windows、Mac、Linux等。
作为天然的一个跨平台的产品来说,如果每个系统使用独立的一套架构,后果将会难以想象,不仅开发起来工作量巨大,对于后期升级和运维来说,也堪称灾难。
腾讯会议客户端开发负责人陈志兴是最早参与架构设计的成员之一,他回忆称,从腾讯会议的第一行代码开始,团队就坚持同源同构的思想,即同一套架构,同一套代码,服务所有场景。
更重要的是,主框架全部基于自研。
“虽然开源也可以实现功能上的创新,但对于会议场景来说,因为各个组件和模块之间的拼接,将会导致信号在传输过程中产生延迟,自研的架构天然就是一个整体,在全链路的延迟上,有机会比开源做到更低”。
基于在音视频实时传输系统搭建和优化上的经验积累,腾讯会议技术团队自研了一个跨平台而且高效的引擎 —xCast。这种端的优势在于实时性,在最短时间内根据网络等状况做出反应,配合云上的后台优势,可以做到灵活调整云端策略。
有了这样统一的架构,腾讯会议在面对新的移动场景端时,能够做到最快的平台兼容和稳定。
目前,在腾讯内部,腾讯会议是最快支持苹果M1芯片的内部应用。
“在底层能力上,腾讯会议坚持自主研发,这可以认为是一种腾讯传统的自然延续,但对于腾讯会议技术团队来说,xCast就是要做世界上最好的音视频通信基础服务”,腾讯会议平台架构组负责人D老师表示。
2021年,腾讯会议迭代优化了20000个功能,实现小步快跑,背后的杀手锏就是xCast。
一群做软件的,被逼成硬件工程师
其实,对于交互类产品来说,解决了稳定适配和兼容这个最大公约数的问题还只是刚刚开始,为了给用户最优质的沟通体验,还需要针对每个端的性能进行不断的优化。
拿用户最关心的手机电量这个点来说,开会作为一个高频场景,用户格外关注电量问题,现在很多用户都有电量焦虑症。
在会议诞生之初,特别是在夏天,腾讯会议总是会收到比较多的用户反馈。当时很多学生在使用会议来考试,老师要求必须开摄像头,他们基本上边充电,边开着摄像头。
(为了测试耗电量,技术团队对各种款式的老旧手机进行反复测试)
有大量同学反馈说,经常设备发烫特别厉害,电量消耗得特别快。
为了搞清楚问题,负责性能优化的猫哥特别针对相关反馈,一个用户一个用户打电话询问,究竟在什么样的场景下,掉电比较厉害。通过这种大范围纯手工的“人肉筛查”,团队最终在超过180例反馈中,梳理出了问题症结,并做了专门的优化。
当时发现,在双行卡的Mac机器上使用了高性能一些GPU,它对于非开摄像头的场景,对电量或者是发热的影响是非常大的,后来发现这个问题以后,针对性的做了多轮测试和优化,极大减少了电量的消耗。
除此之外,还做了一些边界的裁剪,因为刚刚做视图播放的时候,渲染边界或者动画会对CPU的消耗影响非常大。
把线上比较紧急的问题解决完了以后,会议团队也在思考怎么样常规化、自动化地发现这样一些问题。
但是问题接踵而来,电量的测试环境会因为不同的温度、光照而存在差异,对整个电量消耗都是影响非常大的因素,需要做多次反复的操作,才能达到相对稳态的状态。
为了从根本上解决难题,团队成员开始“不务正业”,研究起来了数据线的电路原理。
于是,一群会议的软件工程师,硬是捣鼓出来一块智能充放电控制板。
(为了提升电量消耗测试的效率,会议技术团队做了一块控制板)
经过一番研究之后,发现数据性的原理并不复杂,它内部的主要电路一部分是支持充电用的,一部分控制信号用的,充电本身就是一个继电器和控制信号,继电器的本质作用是为了给它做充电的操作,控制信号主要用来控制充电的开关。通过一台PC或者Mac的电脑,可以对手机做自动充放电的管理。
摸透了原理之后,会议技术团队便自己动手焊接了一块自动控制板,灌上程序,跑了起来,硬生生把一群程序员逼成了硬件工程师。
有了这个电路板之后,技术团队就能够更加精准地去测试。比如在80%的电量场景下掉电是什么样子的,当电量到30%的情况下,又是什么情形。
一个直观的例子,很多人在参加会议时,如果细心的话会发现,每个人像旁边有个麦克风音量动画显示对应讲话人声音,当多个人同时有讲话时,存在多个动画,但该动画频率高数量大时,对电量的影响也就越明显。
经过分析后,技术团队通过动态调整动画帧率合并刷新等方式,降低了多音频场景下电量的消耗,以macOS为例,6人参与的音频会议,半小时电量消耗下降达到100mAh。
生于云、长于云
除了网络上、架构上的优化,腾讯会议还依靠腾讯云,在更宏观的维度上作了系统级的规划。
最开始,腾讯会议的设计容量支持5万人同时在线,但是2020年3月腾讯会议的日活就突破了一千万。如今,腾讯会议的用户已经超过两亿,在一场又一场“大考”中历练成长。
就拿扩容来说,以往提到扩容,很容易联想到堆机器、堆资源、抢IP。
2020年初,腾讯会议就遭遇了一场硬仗。为了紧急扩容,支持爆发增长的远程协作需求,整个公司几乎所有有着海量服务经验的12级专家,都参与到这场战斗中。
当时,负责媒体传输的黄志海、负责媒体流控的薛笛、会议后台整体架构的王彬三个团队,更是组成了跨部门铁三角战队。
在多个团队日以继夜的 “空降式“救援后,腾讯会议顺利完成了会议扩容、稳定了后台服务,还创下8天扩容超过10万台云主机,创造了云计算历史记录。
这一切,都源于背靠腾讯云完成的。生于云、长于云的腾讯会议交出了一份崭新的答卷。
(会议扩容之战的特别作战室)
根据腾讯云副总裁、腾讯会议技术负责人陈健生介绍,在整体架构上,腾讯会议采用了容器化的云原生方案,真正做到弹性伸缩、自动扩容、异地容灾备份、服务化治理。
其次,腾讯会议全面使用腾讯云的云原生组件和能力,比如TDSQL、对象存储、CDN加速器、文件存储、日志监控、消息队列等。同时,基于云原生的模式,会议的开发、测试、部署、运营等四个域的研发效能全面得到提升,也让腾讯会议在快速成长的时候得以保持敏捷的迭代节奏。
“现在要说扩容,几十万核心的扩容,一个按钮就能搞定”,王彬说道。
后台团队的大鹏也深有感触,腾讯会议把云上通用型的能力做成了灵活可配置,随时可以上,随时可以下,“原来很多人的苦活累活都被机器替换掉了。”
今年以来,全国疫情形势严峻,当某个地方出个疫情,腾讯会议可以通过用户需求观察,进行系统性立体式的管理,及时发现流量异常,依靠全自动或极少人工参与的方式进行系统容量的保障,快速支撑疫情地区人民群众的远程需求。
云给腾讯会议带来的改变远远不止扩容这个点。云资源的保障能力不仅体现在人数的垂直维度,还在地理的水平维度上。
2021年的时候,在一场有200方的会议中,成员遍布全球150多个国家。当时面临的最大的问题就是有些国家网络好,有些国家网络很差,甚至有些非洲地区的网络,网络状况还是十几年前的水平。
为了保障整个会议的质量,腾讯会议依靠腾讯云遍布全球27个国家的70多个可用区,以及2800多个加速节点,为220多个国家和地区的用户提供就近接入能力,同时借助腾讯云网络的高质量低延迟的传输能力,为会议的稳定进行提供了基础保障。
毫无疑问,生于云、长于云,让腾讯会议有了一个坚实的技术底座,扛住了洪流般的用户需求,经历了一场场大规模云端实践。
对于会议的未来技术演进目标,腾讯云副总裁,腾讯会议负责人吴祖榕总结了四个“any”,他希望用户无论是anytime(任何时间)、anywhere(任何地点)、anydevice(任何设备)、anynetwork(任何网络),都能稳定流畅的开会。
“腾讯会议会开会”,不仅是腾讯对于会议这款产品的承诺,也是一种底气。