是时候给钉钉和腾讯会议算算账了
杨净 萧箫 发自 凹非寺
量子位 | 公众号 QbitAI
这几天，工作和上课等事情开始有回归线下的迹象，腾讯会议、钉钉似乎也可以松口气了。
毕竟云会议的这两大APP，前段时间一直在被网友找平替。
一来，它们要收费了；二来，网络流量太大还会造成部分用户进不去，这段时间腾讯会议、钉钉就相继“崩”上热搜。
还有很多吐槽的点。比如设计出的功能不好用，网友不买账：
部分功能人数受限，抢不到、上不了网课：
但即便如此，甚至开始收费……不少用户不断找寻平替之后，却仍然只能在这两者之间做出选择。同时，二者的月活和用户数也已经上亿计，据第三方机构QuestMobile和腾讯财报数据，腾讯会议用户已超3亿，10月钉钉的月活也达到2.37亿。
问题来了，为什么找来找去，却没有找到免费的云会议或者网课APP，作为它俩的替代选项？这背后究竟有怎样的原因？
我们探究了一下背后的技术原理和底层架构，有不少意外发现。
云会议APP，难做在哪？
至少从看得见的技术层面来看，门槛并不低。一个云会议APP，需要满足几大用户刚需：
音画效果、多人协同、多设备适配以及其他附加功能。
而要想实现上述功能，开发商们首先得应对这两大基本技术挑战。
一方面，云会议实时性强、参会人数变化大，这对云端的计算资源和带宽资源的分配提出了很大的挑战。
尤其软件使用高峰期，不仅对服务器等硬件性能有所要求，软件算法同样起关键作用。
如编码标准的选择，直接影响编码压缩性能。数据压缩比率高，有助于提升音画清晰度，让带宽利用更高效，但也会带来更高的运算复杂度。
又如系统搭建，传统云会议系统的集中式架构，比如MCU，难以适应大规模部署、灵活动态收缩，容易造成资源浪费。
再如网络传输，如何确保大流量下资源的灵活分配，选择最佳的路由，降低时延，也是算法设计需要考虑的因素。
另一方面，用户端不同设备类型和网络环境，对稳定性和安全性提出考验。
如何确保APP的稳定性，是一大难点。无论上课或开会，用户设备和网络环境都有差异，像孩子用爷爷的旧手机上课、或是“天选打工人”在电梯间接到了视频电话。
以安卓APP为例，安卓设备繁多，导致不同设备上的H264硬件加速能力参差不齐，这给软件开发商的适配带来了巨大的工作量和难度。
在隐私与安全措施上，此前爆火的Zoom就曾遭过质疑。如何提升安全性，包括在架构设计中融入隐私保护、端到端加密、密钥生成机制等，同样有待研究。
这两方面外，提升美颜美化、实时转录、降噪等功能便捷性，又要求掌握大量AI算法。
综上来看，实时会议APP涉及的技术是全方位的，关乎软硬件协同、技术资源调度、复杂算法研发等难题。
不过即便这些难点“看得见摸得着”，也不一定就能靠提升技术实力解决。
做出来也不一定能用
毕竟云会议APP讲求的是实时，无法保证实际使用情况都能被预测。上述任意一个难点都有可能随着环境变化呈指数增加——
尤其是面对大流量时。
可以说，一旦遭遇大流量，所有云会议平台都容易出现问题。（这里排除了只有几百万用户的平台，由于同时在线用户少，不会遭遇流量冲击问题）
例如根据2020年钉钉公布的一组数据，“企业组织在钉钉上发起在线会议的数量，单日突破2000万场、超1亿人次，且每天还在快速增长”就是典型的大并发。
这还是两年前的数据，如今随着钉钉和腾讯会议用户量增加，突发流量只会比这组数据更高。
其他云会议APP要想占领腾讯会议、钉钉的位置，首先就得考虑能否扛得住这种大流量。
因此，短期具备迅速调度资源、扩展技术架构的能力，本质是大厂的底层优势之一。
从云会议APP背后的高并发能力、高可用保障和运维效率来看，保持这种状态绝非一件轻松的事情。
其中高并发能力，对带宽资源、扩容速度和服务器数量提出了更高要求。
无论是带宽资源、服务器，还是扩容所需的云原生技术，都依托于阿里云、腾讯云提供。
2020年初，就出现过腾讯会议8天扩容100万核、钉钉扩容十万台服务器（每台服务器几十核）的新闻。
扩容，即扩大通信设备的容量，它取决于几个前提条件：
首先，是否有充足的云资源。流量并发时，各类APP都需要扩容，如果无法优先拿到云计算提供商的云资源，导致可用云资源不足，就会直接被涌入的流量打爆、导致服务器宕机。
其次，大流量涌入是瞬时的，不可能等APP慢悠悠地扩容。即便云资源足够，从技术上如果无法迅速扩容，宕机仍然不可避免。
最后，即使给了足够云资源，云会议平台能否接得住。这一点在架构设计时，就要做好适配，而很多软件的扩容上限很低，技术上也无法做到无限扩容。
还有高可用保障，对云资源调度、架构稳定性同样要求不低。
如资源调度上支持的异地多活，就属于容灾技术的一种，能确保服务器使用效率的同时做好风险保障；再结合负载均衡对网络流量的灵活分配，又进一步降低了设备“崩”掉的概率。
前面提到的旧手机、复杂网络环境等难点，就同样是高可用技术保障的一部分。
最后，即便云厂商具备上述能力，在面对突发状况时也得确保关键一环，即“时刻在线”的运维。
而这同样是大厂的另一底层优势。无论是故障恢复能力、还是自动化运维技术，都是提升云会议APP使用体验的关键一环。
无论是高可用、还是高并发、或是运维能力，本质上都是钉钉、腾讯会议背后阿里云和腾讯云的优势，毕竟对于网课这种场景，可以拿到更高的资源优先级。
但钉钉腾讯会议之所以能屹立于国内市场潮头，其背后还有更深层次，也是更为关键的原因。
看不见的成本冰山，“砸”不起
前期开发到后期运营所需要的资源和能力，更是海平面下“看不见的壁垒”。
单从前期投入来看，其资源消耗成本就分为两大部分——技术和人力。
技术资源被分为服务器、存储和带宽成本。
随着用户数量增加、网络带宽需求增大，成本投入也会剧增，大部分云会议APP根本把握不住。
单就服务器、存储等硬件来看，除了使用损耗外，为了确保扩容速度，硬件资源储备必须充分。
BUT意外的是，无论是服务器还是存储，硬件资源的消耗对企业而言，并不占资源的大头。
据了解，钉钉上个月在音视频中投入了2.5亿元技术资源，其中服务器和存储仅占20%左右。其余70%以上的成本，都是在网络带宽消耗上。
为了确保网络传输效果，需要采用BGP技术，给各运营商支付费用后，将电信、联通和移动等多个运营商网络融合在一起，让路由器具备“选择权”，切换最快的路线传输信号。
技术资源以外，还要考虑人力资源的投入。
以人力为基础建立起来的技术和研发壁垒，又令不少同类产品望尘莫及。
据职友集透露，目前音视频工程师平均工资收入在3-5万每个月，较2021年增长58%。
但这背后却是音视频高端人才的稀缺，各大厂也在投入大量研发资源招人储备音视频实力。
如腾讯引进了刘杉等多媒体专家，评级在T5科学家级别。根据HR人力资源成长俱乐部透露的2020年数据，腾讯T4年薪在200-300w左右，T5级别的科学家只会在这之上。
更别提还要考虑到音视频引擎、AI算法等方面的工程师，如果按百万年薪来计算，人力投入同样是一笔不小的数字。
又如钉钉去年就从达摩院引入了声学专家冯津伟建立蜂鸣鸟音频实验室，研发核心就包括弱网场景、3D音频、智能降噪、远距离拾音等音频技术。
至于腾讯，前几年也在音视频领域发表了二十多篇论文：
前期大量投入建立技术壁垒，后期运营则将这层壁垒更加强化。
可以说，技术以外的大厂投入和运营，又反过来进一步强化了技术本身，成为海平面底下看不见的壁垒。
如今，云会议APP却仍然面临技术壁垒、研发运营等难题——
包括如何提升线上会议的氛围感、以及多人会议中的降噪问题等，仍然是各家APP着力解决的场景。
这看似给更多云会议APP留下了反超的空间。
但身为云会议APP中坐“头两把交椅”的钉钉和腾讯会议，却依旧在进一步加大研发和投入力度。
例如腾讯会议与更多硬件厂商合作，优化音视频产品的同时推出智能会议空间解决方案；钉钉也在最近推出了XR办公，让用户在AR智能眼镜上也能开启线上会议……
如此来看，钉钉和腾讯会议，短期内确实无法找到更好的替代品。
One More Thing
还记得上面高昂的70%带宽成本吗？
如果按2.5亿元来算，钉钉一个月光是带宽成本就花了1.75亿元。
这笔钱到底是怎么花出来的？
前面提到，BGP线路是一种将移动、联通、电信等多家运营商网络融合起来的技术，目的是让大伙儿总能用上最快的网络。
但如果给带宽成本算笔账，会发现背后成本极高。
以阿里云最便宜的带宽单价为例，1Mbps每个月就需要20.7元。
如果按一个公司网络带宽需求计价（每月2Gbps左右）的话，光是带宽费用就要花掉14.7万元多。
加上CDN加速节点（如直播回放时快速加载视频会用到）等业务，按钉钉的2.37亿月活来看，1.75亿元的带宽成本似乎也不难想象……
不过，要是你以为这是阿里云（或腾讯云）决定的费用，那还是naive了。
对于带宽成本，云厂商们还真压不下价格，它是由各家运营商的BGP业务收费情况决定的。
即使阿里和腾讯在全国各地建再多机房，服务器也并不能解决所在地区的网络传输问题。
说白了，网络带宽不是云厂商能hold得住的，还是得老老实实给各个运营商交钱，而这些成本的大头，也基本都付给了运营商。钉钉、腾讯会议能扛几年，直到现在才收费，也不容易，如果按目前状况来看，这个收费显然无法覆盖成本。
△上海联通BGP收费情况
这样看来，我们给手机交的流量费用还真不算多（手动狗头）。
参考链接：
[1]https://mp.weixin.qq.com/s/gNW8Pm0njkgA98r9Z0UYRw
[2]https://www.zhihu.com/question/475673432/answer/2208119721
[3]http://www.chinanet-sh.com/product.asp?id=29
[4]https://developer.android.com/guide/topics/media/media-formats
