写点什么

双 11 猫晚互动前端容器化之路

2020 年 4 月 04 日

双 11 猫晚互动前端容器化之路

一、猫晚简介

天猫双 11 狂欢夜,以下简称“猫晚”。晚会有丰富的节目以及多样的互动,用户可以在互动中得到双 11 所需的购物权益。在这三年中,互动也从简单的 H5 互动逐渐演变成为依赖 Weex、 H5、游戏引擎的多样互动。



二、互动技术挑战

1. 多平台同时直播

2019 年猫晚在优酷、淘宝、天猫同时播出,同时附带了 13 种互动,其中不乏“叠叠乐”等流程复杂的游戏。开发会面临两个问题:


a)渠道多、平台多。如何保证多平台开发效率且体验一致?


b)互动类型多,每个互动都有独立逻辑,直播间需要将所有互动做串联。这些看似独立又有关联的互动,如何能高效、健壮地落地在不同平台呢?


2. 年年创新、迭代速度快

我们需要在既定的时间内,实现快速迭代,并且要保证用户的良好体验。那么又会碰到一些问题:


1)迭代速度快。开发期只有几个月,客户端发版节奏无法满足。如何处理“发版”“快速迭代”这两个互相冲突的要求?


2)PC 端、H5 如何跟上移动端的脚步?


3. 如丝般顺滑的体验

“双 11 天猫狂欢节”的品牌有多响亮,“猫晚”同时在线人数就有多高。人数多就等于“机型多”,每年做猫晚几乎什么型号的手机都能碰到。


从服务端的角度来看,高同时在线就意味着服务端需要承担更高的 QPS,部署更多的机器。又会引出几个问题:


a)同时在线高的情况下,如何保证每个用户的体验?


b)高并发下如何保证服务稳定?


三、技术策略

为了更好的解决上述问题,我们提出了组件化、容器化方案。同时针对一些用户体验,从技术方面进行了优化。


1. 组件化

需要在优酷、淘宝、天猫至少三个平台同时落地互动,的前提下如何保证同时进行多个平台开发的效率呢?


1)互动组件化


经过需求分析发现,每种互动其实是个较为封闭的环,每种互动都在内部有套独立的逻辑。


那是不是可以使用“组件化”的思想把不同互动拆分成“互动组件”然后分配出去,让每个开发只负责某一种或几种互动,通过内部 NPM 分发,在不同平台统一依赖这些“互动组件”,最终组装成直播间。



2)抹平平台差异


组件化要想同时运行在多个平台上,就要处理平台差异,有两种选择:


a)组件适配不同平台;


b)统一标准,平台去兼容组件。


两种方案没有好坏之分,但由于今年猫晚有着多达十多种互动模式,为了减少适配的工作量,选择了第二种方案。


我们在平台上实现了一套“适配框架”,抹平不同平台的差异,它主要有三个职责:


a)提供标准化 API,整合容器能力;


b)提供标准化数据模型,不同平台组件可以获取相同的数据;


c)提供节目单与互动服务通信,获取数据,控制互动组件的渲染逻辑。



这样,互动组件只需要对接“适配框架”,无需关心平台。


3)组件标准化


决定“适配框架”方案后,就需要统一组件的整个生命周期,使得每个组件都有统一的标准。在此基础上,我们提供了统一的“脚手架”,把控组件从创建到部署的过程:


a)自动化创建组件托管仓库;


b)自动生成初始化目录和模版;


c)统一编码风格,统一 ES 版本;


d)提供开发调试能力;


e)自动化部署 NPM。


4)方案



跨平台输出效果



2. 容器化

每年的用户诉求都有所不同,每年的产品方案也在变化,必须要做好充足的准备。我们使用“容器”支撑不断变化的需求。


1)热更新与选型


客户端依赖版本发布、用户更新的策略来分发,比 H5 的分发效率低。但使用 H5 在移动浏览器环境下渲染复杂互动,会遇到性能瓶颈。选型方面,我们需求:


a)热更新


b)高性能渲染


c)前端可以轻松上手


框架上我们选择了 Weex,引用一则 Weex 官网的介绍:


Weex 致力于使开发者能基于通用跨平台的 Web 开发语言和开发经验,来构建 Android、 iOS 和 Web 应用。简单来说,在集成了 WeexSDK 之后,你可以使用 JavaScript 语言和前端开发经验来开发移动应用。


Weex 最终渲染的是 Native UI,性能上要优于浏览器渲染。借助 Weex 的渲染远程 jsBundle 的能力,实现实时更新。


Weex 的渲染引擎与 DSL 是分开的,在 DSL 选型上有两个选择 Rax 或 Vue,考虑到阿里集团内复用性上,选择了 Rax。Rax 在几届双 11 中也有很好的表现。同时,我们也保留了 Webview,渲染一些 H5 游戏。


2)容器化的能力


Weex 有两种方式来扩展能力:


a)Module 可以封装一些接口,调用原生能力;


b)Component 可以使用原生实现 Weex 组件。


有了手段以后,容器能力需要封装到哪种程度?有两个选择:


a)提供完整的业务组件,开箱即用。业务只需摆放位置,拼装;


b)只提供基础能力,业务需要在此基础上实现业务逻辑。


显而易见,想要支撑不断变化的需求,容器的能力不能太定制化。所以我们选择了第二种方案:


a)在 Module 方面,容器提供了包括“流媒体、下载、相册、通信、埋点、键盘、支付、屏幕旋转”等 31 个 Module,给容器扩展出近几十种原生能力;


b)在 Component 方面,封装了“Webview、播放器、动画、进度条、聊天列表、弹幕”等 18 个 Component,扩展出了一些通用的 Native View,提高渲染性能。


最后,我们抽离了直播间逻辑。使播放,通信等基础功能功能可以单独剥离出来,做为“直播间基础逻辑”,业务层可以选择继承方式来扩展自己的能力。


3)模版,创造更多的搭配


在日常的业务中,容器需要支撑多种多样的直播。有普通直播,也有猫晚这种大型互动直播。


我们在容器中增加了“模版”的概念,把模版和直播类型建立起关系,通过不同的模版来支撑不同类型的直播。例如猫晚直播间会渲染“2019 猫晚模版”,展现给用户相应的界面。在模版加载过程中,加入了提前推送 Cache 的能力,使得大部分用户可以直接从本地加载模版,大大加快了首屏渲染的速度。


4)输出到多终端


搞定了移动端后,我们还需要处理 PC 和 H5,每个终端单独开发有些费时费力。在多端输出方案上,容器借助了 Rax 的跨平台渲染能力。剥离了组件的样式和业务逻辑,使得各终端可以共用一份业务逻辑,然后实现不同的样式,最后分别构建后运行在各终端的容器中。


5)方案


最终形成了容器化的方案:



最终渲染结果:



3. 体验优化

在保证了产品需求落地后,还需要考虑如何保证互动有“丝般顺滑”的体验,下面介绍其中几个优化方案。


1)互动游戏秒开优化


今年双 11,用户在直播间内和现场进行了游戏互动。互动开始后,会进入选队阶段,用户在此阶段可以选择自己喜欢的队伍。选队阶段结束后,线上会和现场连线,一起进行一次互动游戏。


游戏本身是依赖 H5 游戏引擎实现的,代码体积较大。在浏览器环境中,会遇到加载速度的挑战。网络层面上,每个用户网络环境不同,必然有网络不好的情况出现。用户可能会等待很长时间才能玩到游戏,体验非常不好。


我们来看一下游戏加载的流程:



可以看到,服务器会在“选队阶段”开始一段时间后,发送“选队结束”的信号,让所有用户停止选队。等待晚会现场可以进行游戏后,会发送“游戏开始”信号,客户端会拉起 webveiw 面板去加载游戏。


有两个阶段用户无法操作互动,需要等待。一个是“选队结束”信号收到后,直到收到“游戏开始”信号。随后会拉起 webveiw 面板;另外一个是“游戏开始”信号收到后,直到游戏加载成功。


第一个阶段服务器发送“选队结束”、“游戏开始”这两个信号之间所需时间,是依据晚会现场的节奏,这个优化空间比较小。


第二个阶段,游戏本身会做一些资源压缩,资源整合,可以从体积层面提高游戏加载速度。但是这也有局限性,游戏的图片、特效等很丰富,优化后的资源体积也是远远大于普通 H5 页面的,再叠加游戏初始化耗时,在普通网络环境下无法做到“秒开”。


在“空间”层面上,我们无法再优化的情况下,我们是否可以从“时间”层面上做一些优化?从上面的流程图中可以看到,选队结束后,就已经可以做游戏的加载初始化工作了。随后游戏初始化完成,收到“游戏开始”指令后,只需拉起面板即可。这样游戏就会是提早准备好,大大缩短了等待时间。



2)互动与视频对齐


晚会虽然是同步直播给用户的,但综合每个用户的网络情况以及客户端解码性能,每个用户在同一时刻看到的画面是不同的。以“互动开始”信号为例,“互动指令”是在主持人说出“开始”等关键信号时,下发给客户端。



“视频”和“互动”是两条互不相干的链路。我们把用户看到“视频画面”的时刻记为 T1,看到“互动”的时刻记为 T2。可以看出,“T1”与“T2”是没有任何关系的,除非凑巧,理论上用户是无法在看到“主持人喊开始”时,同时看到相应的互动。这样就会缺失“现场感”,互动直播的质量会大打折扣。


那如何让用户看到相应视频时,同时看到相应互动呢?


视频编码中的 SEI(附加增强信息),可以附带一些自定义数据。如果使用 SEI 附带互动标识,真正的互动数据则提早一些下发到客户端。互动可以实时监听解码视频时的 SEI 标识,发现当前互动的标识时,执行相应的操作。



这样用户就会在看到“主持人喊开始”时,同时看到相应的互动展示,就有了“现场感”。


3)高并发下的服务端稳定性优化


在互动开发中,避免不了客户端与服务端做一些数据的通信,其中又有许多,是程序自动触发的。尤其在互动直播场景下,用户会集中在某个时间段内做一些操作。QPS 监控上,往往可以看到一根尖刺,请求时机都比较集中。同时在线只有几千个人的情况下,没有什么优化的价值。但是如果像猫晚这种百万级别同时在线的互动直播中,就很有优化的必要了。


这样会带来几个好处:


a)可以大大降低 QPS,减少部署工作成本;


b)减少集群机器数量,节省开支。


同时在线越高,这些好处就越明显。在开发大型直播互动时,提前要建立起流量评估模型,方案细化到每一个接口。如果一些请求过于集中,就通过一些手段打散掉(在一个时间段内取一个随机时间点,发送请求)。后续演练场次里面,不断地验证模型的准确性。如果有不符合的地方及时修正。


四、大型直播互动经验

最后分享在参与大型直播互动中的经验:


a)技术设计、选型,以稳定性为标准,客户第一,保证用户权益、用户体验;


b)多进行演练,并且搜集数据,重点分析预期外指标,调整对应技术参数;


c)多平台统一架构,一套代码,多平台部署,保证一致性;


d)建立流量评估模型,消峰策略,降级策略;


e)监控体系要齐全,预案要细化。


作者介绍


阿里文娱前端专家沐南


2020 年 4 月 04 日 18:08159

评论

发布
暂无评论
发现更多内容

充分释放数据价值:安全、可信6到飞起

华为云开发者社区

区块链 数据共享 华为云 可信安全计算 数据价值

NIO的组成有哪些——奈学

古月木易

nio

打造高转化率网站不得不遵循的3条规范

姜奋斗

网站架构 网站 网站搭建 高转化率 转化

Week 09 命题作业

Jeremy

JVM系列之:从汇编角度分析NullCheck

程序那些事

Java JVM JIT

一文教会你嵌入式网络模块的联网操作

良知犹存

物联网 网络 嵌入式

如何保存我们的资产

不在调上

「查缺补漏」巩固你的Redis知识体系

Kerwin

Java redis

女博士年薪156万入职华为!网友:实力演绎美貌与智慧并存

程序员生活志

华为 少年天才

9-1垃圾回收原理和秒杀系统

burner

【架构师训练营】第九期作业

云064

学习总结(训练营第九课)

看山是山

产品经理【三句半】,说清你的【酸甜苦辣】

Java_若依框架教程

产品经理 产品设计

浙江上线市场监管区块链电子取证平台,武汉出台“区块链八条”,

CECBC区块链专委会

区块链 行业资讯 产业落地

《RabbitMQ》如何保证消息不被重复消费

Java旅途

RabbitMQ 消息队列

《深度工作》学习笔记(5)

石云升

读书笔记 专注 深度工作

未来云原生世界的“领头羊”:容器批量计算项目Volcano 1.0版本发布

华为云开发者社区

Kubernetes 容器 华为云 Volcano 元原生

NIO的组成有哪些——奈学

奈学教育

nio

日入斗金,稳赚不赔?小心泛滥网络的兼职刷单让你钱尽财空

360安全卫士

9-2 秒杀系统的挑战和问题

burner

架构师训练营-week09 作业

GunShotPanda

架构师训练营 -week09 学习总结

GunShotPanda

架构师0期第九周命题作业

何伟敏

中国四大银行正在大规模内测数字货币APP|可凭手机号完成转账

CECBC区块链专委会

数字货币 DCEP 中国人民银行

华为云的研究成果又双叒叕被MICCAI收录了!

华为云开发者社区

学习 AI 计算机视觉 医疗 华为云

获得高手的精英思维,从写作开始。

叶小鍵

高手 万维钢 得到精英日课

Week 09 学习总结

Jeremy

week9 学习总结

任小龙

架构师训练营第九周

WW

Week09作业

熊威

换一种方式构建镜像

北漂码农有话说

编译系统设计赛(华为毕昇杯)技术报告会|5月1日

编译系统设计赛(华为毕昇杯)技术报告会|5月1日

双 11 猫晚互动前端容器化之路-InfoQ