「字节跳动直播研发团队」是如何每天护航百万直播间的?

  • A+
所属分类:安全闲碎

「字节跳动直播研发团队」是如何每天护航百万直播间的?

2019年,字节跳动整合了旗下抖音、火山小视频、西瓜视频的直播技术、业务团队,成立服务于公司全线产品直播的直播研发团队


他们每天接受上百万直播间实时开播的考验,扛住了数百万人同时在线的抖音奇妙夜直播,护航了抖音奇妙好物节直播带货屡创新纪录……


实时交互、不能延迟、没有补考机会,面对众多技术难题,这支屡屡交上高分答卷的技术团队,都做对了什么?


「字节跳动直播研发团队」是如何每天护航百万直播间的?

01

不打没准备的仗


2020年的愚人节,罗永浩直播在抖音首秀。高峰吸引近300万人同时在线,累计观看人数超4800万,1.1亿GMV,创下抖音电商直播的新纪录。

「字节跳动直播研发团队」是如何每天护航百万直播间的?

开播前大家难免紧张,如此量级的电商场景直播,此前在抖音还从来没有被大规模验证过。

几百万人同时涌入,能不能稳住?
直播期间用户给主播发送大量评论,导致占用CPU、硬件发热,如何使用降级策略解决?
采用功能降级时,如何尽可能不影响用户体验?
大量的C端流水,打赏、主播提现,如何避免资金风险?
……

开播后,紧张很快就变为了淡定,整整3小时,技术问题都在预料的可控范围之内。

先想一步乃至几步,一直是字节跳动直播团队的做事习惯。久经考验的直播研发团队,已经摸索出了举一反三的核心解题思路:

  1. 提前预判,做好资源准备和降级策略方案
  2. 多次彩排追求极致
  3. 重保小组+大后方配合护航

面对类似老罗直播这样的复杂项目,大家会提前1-2个月做准备,拆解划分关键节点目标:

首先,是做好瞬时流量的量级预估判断,从而做好相应资源的准备和扩充。



研发团队通常会先和市场、运营同学沟通,然后通过一套此前经各种活动验证的转化比计算方法,算出瞬时流量的并发量级。


“投放的包括push、开屏,投放时间点,以及整个产生作用的曲线,其实我们是心里有数的,综合考虑这些因素后,我们就大约清楚在某一个时间点会有多大的量进来。” 字节跳动直播研发负责人周鹰说,根据预测量级,团队将设计好相应的预备方案,把资源补充到位,同时留一定的余量出来。



反复调整的压测、彩排,让团队对避免翻车更有信心。



老罗首秀开播前一个月,演练就开始了。由客户端、服务端、平台、流媒体等方向的oncall同学组成了一支重点保障小组,护航整场直播的所有环节。直播当天下午三点的终演彩排,不仅是码率清晰度、网络状况被反复调试至满意,连麦克风放哪个位置更好的细节,重保小组的同学都在现场帮助操作。


彩排再多,总归还是会碰上没遇到过的问题。


罗永浩直播在电商这块的高并发症问题就比较明显,早期也暴露了诸多购买路径、售后等方面的问题,对整个电商直播服务的优化成长帮助很大。


比如首场直播时,对于一些优惠力度大的秒杀活动,老罗喊了开抢后,用户在商品列表却一直刷不到货。技术团队找原因才发现,由于货是先上架到电商后台,再同步到直播的商品列表,结果当初就被某些黑产利用这个漏洞直接在电商后台把单抢完,导致用户感觉有内幕。



监控系统和预备的突发解决方案也在不断完善。



为了缩短定位问题的路径,团队针对高热直播间做了涉及各个节点的端监控。比如进入直播间的首帧画面卡顿率,或者送礼成功率,一旦指标变化较大,就会触发监控系统自动报警。而一旦有用户问题在群里抛出,可以直接分到对应的方向去查,定位到具体问题,比如是CDN的问题、还是服务端问题。


诸如卡顿、清晰度这类问题,十几分钟内就能被解决掉。


“一般最紧张的就是开播后几分钟,以及抢红包的那一秒,这种重点时刻的预判对了,事情就大体稳了。”参与支持了多场大型活动的直播服务端研发沈杰说。




02

自动给自己划重点


并不是所有的考试都会提前划重点。

高峰时近300万人同时在线的罗永浩直播,只是抖音每天实时开播的上百万个直播间其中之一。许多时候,团队可能无法提前预知会有哪些高热直播间在何时出现,更难以有较充分时间做资源准备和压测演练。

「字节跳动直播研发团队」是如何每天护航百万直播间的?

以直播消息服务为例,在实时直播间里,可能短时间就涌入几百上千万人,而且任何观众都可以发言互动,对于直播消息系统的要求非常高,资源配置一旦不到位,消息延迟几秒就会带来不少差评。

“比如有些明星大V不会告诉你什么时候开播,他们粉丝群庞大,一旦开播并发瞬间剧增,但我们没有办法提前准备,最初只能设置预值和监控报警,甚至需要在开播后手改代码。”2019年公司合并成立直播研发团队后,负责直播消息系统的武扬发现,随着大型活动、高热直播间越来越多,自动化的重保需求迫在眉睫。

直播研发团队开始利用算法,在海量的直播中为自己划重点:
高热直播间预测+房间开播实时人数计算的机制
· 根据之前所有的开播历史和一系列相关数据,利用机器学习的手段预测一个直播间是否会在开播后高热,从而予以重点关注
· 秒级计算所有直播间人数,根据直播间人数的变化,自动地做一些相应的重保和降级手段


1、消息写入控制

在直播场景下,每个直播间能够发送成功(被客户端接收并展示)的消息数目是控制在一定范围内的,因为如果一个直播间能够发送的消息特别多,刷屏速度太快,会导致用户体验差,反之如果消息很少会显得直播间很冷清。


每个直播间都有消息发送频控,并且阈值是由服务端动态调整的。对于高热直播间的写入频控阈值就需要降低,这大幅降低了推送端网卡的消耗,保证服务端运行平稳。”


2、消息触达控制


目前直播消息系统采用的推拉结合的模型,给用户提供更优越的直播互动体验。具体采用哪种策略对于客户端来说是透明的,无需关心。


对于近千万人同时在线的直播间来说,服务端全链路的QPS也能够达到千万量级,这对业务服务端来说压力是巨大的,需要有完备的容灾预案——缓存、异步化、压缩算法优化、全链路监控,以及非关键链路的数据动态采样策略,关键链路数据实时双通道保障等多种容灾降级手段。


“对于如抖音美好奇妙夜这种量级在线观众的直播活动来说,适当提高部分消息触达延迟,并且结合客户端的平滑展示的方式,来降低服务端压力,换取服务端的平稳运行。而对于用户体验来说是几乎无感知的。”


当然,由于直播存在突然开播、随时关播、流量随时动态变化的特点,要想在保证最优的用户体验和资源利用率之间寻找平衡点,需要业务系统支持更平滑的弹性伸缩机制。

在自动化重保系统尝试之前,2019年4月,武扬带领团队同学花了近两个双月的时间自研了一套更适合直播场景的分布式存储系统。


它有更完善灵敏的弹性伸缩和流量调度机制,可以根据直播间人数、网卡流量变化等灵活动态扩缩容及流量调度。


这一切对于用户来说都是透明的,保证服务高可用的同时充分提高了资源利用率,顶住了多次流量洪峰。


上述种种机制预案,也让团队在去年10月,数百万在线人数的「抖音美好奇妙夜」直播中应对自如。 

疫情爆发后,短短一两月时间,字节跳动平台同时在线直播间数量从12万指数型暴增至30万。

负责直播架构的原明却早已做好了准备。他带队着手升级重构的「在线房间查询」前不久刚上线,初衷就是为了让在线直播间数据查询这项基础服务能够支撑50万乃至百万在线直播间。
在线房间查询帮助我们抗住了流量快速翻3倍的挑战,哪怕在线直播间涨到30万,并发请求600w QPS,性能却更好了。
不仅节省了大概几千万机器的资源,延时还降到了1/10甚至是1/100。
从用户体验来说,过去主播从开播到房间被推荐可能要5秒,现在低于1秒就行。

在重构过程中,原明还意外发现公司用的Thrift协议,在重IO的场景下存在性能问题。于是跨出边界,主动负责做了两三版升级改造,使得Thrift编解码性能提升4倍,上线后在线房间查询资源节省3/4

“我们也在直播server、火山等上下游团队把thrift做了进一步推广,并合并到字节跳动基础库,这对全公司都有收益的。


03

高效背后的挑战


这个有一百来号工程师的庞大技术团队,同样经历过不那么从容的阵痛期。

服务于公司全线产品直播的直播研发团队成立后,需要把直播中通用的基础能力“平台化”,为字节跳动旗下各个App直播业务的快速迭代提供强有力支持。

一个架构支持多款产品,就得考虑怎么实现App间的快速迁移。对于技术而言,挑战大大增加。“通用”的目标更是导致研发成本的上升,周期变长,如何平衡这个一度成了一大痛点。


「字节跳动直播研发团队」是如何每天护航百万直播间的?

此前来自火山直播的沈杰回忆,公司刚合并直播研发团队的一两个双月,整体节奏比较着急,事故频发。
各个团队以前的实践和做事方式不太一样,对于每个工程师来讲,面临的都是之前没有遇到过的问题。
比如我以前考虑火山App就好,但现在每一个改动,都要面向所有产品线,可能本来只是想改产品a的逻辑,结果影响了产品b。

如何抽象中台能力,去更好满足业务方不一样的需求?团队里一直都在讨论,希望采用「中台+前台」的合作模式,中台把尽可能中台化的东西做厚、做扎实,为前台业务快速迭代提供强有力的支撑。


直播场景丰富多元,有泛娱乐直播、游戏直播,语音直播,主播端开播,当然还有媒体官方直播间,电商直播等。


抖音直播安卓端研发黎新很快发现了一个问题,因为一个功能会在多个类型的直播间存在,基于这个背景,前期如果没有一个很好的框架去支持,就需要通过人工方式去维护。


而安卓之前是用原生的XML模式去描述布局文件,不够灵活,大量不同种的直播间的模式堆积冗杂在一起。


“当时有三四个XML文件,存在大量重复性的代码和样式描述。大家如果要做个新功能,需要在这三四个地方同时添加修改。随着业务迭代开发,大量代码重复存在,对后面的迭代维护也不好,改起来费劲。”

黎新开始和团队同事讨论,能不能尝试用代码写布局?把砌墙方式变成组装式,尽管这种新方式存在不够直观、没有全局感的两个短板,但能通过两个插件来弥补。
这是个比较激进的尝试,但leader就鼓励我、给我时间。
先做出来再说,不要担心其它事情。

历经一个双月,黎新开发了一个可视化的XML逆向生成工具,使直播间layout inspector速度比官方提升了100倍;此外,他还改变了在直播间下的开发方式,开发期间想看代码是否像预期一样运行,点个按钮就会渲染到手机端,不需要重新编译安装。

「字节跳动直播研发团队」是如何每天护航百万直播间的?

在这支成立一年多的直播研发团队里,还有许多如黎新、武扬、原明等一样享受创新的年轻技术人。他们站在一个巨大流量平台上,大胆展开着一次又一次新尝试。

有同学说,做直播的魅力是,大家可以很快聚焦,拆解复杂项目。不少上线前,大家都认为是不可能的事,但是就是做到了。

“从问题中,我发现我们的边界也越来越广,有意思的东西越来越多。”

加入直播研发团队


【社招岗位】

后台核心研发工程师

服务端测试开发工程师

客户端Android/iOS开发工程师

前端开发工程师

图形/图像开发工程师


↓扫码投递

「字节跳动直播研发团队」是如何每天护航百万直播间的?


【实习生岗位】

客户端研发实习生

测试实习生

前端开发实习生

后端研发实习生

图形/图像研发实习生


↓扫码投递

「字节跳动直播研发团队」是如何每天护航百万直播间的?



↓更多「直播」校招岗位持续热招中 

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: