ALive：淘宝双11直播，技术同学却可以“偷懒”？

阿里云云栖号

于 2019-12-05 12:07:51 发布

阅读量1.2k

点赞数

文章标签：容器淘宝性能

本文链接：https://blog.csdn.net/yunqiinsight/article/details/103400232

版权

“疯狂的”淘宝直播间

今年直播又火了！

2019年双11淘宝直播带来近 200亿成交，以天猫双11交易总额2684亿计算，直播已经占总成交额的近 7.45%！

今年的变化

除了以往的手淘和猫客，现在 UC 浏览器、新浪微博、支付宝、优酷、闲鱼、飞猪、饿了么、口碑等等一系列阿里系 APP 里也可以观看直播、购买商品了，可以想象一下这些场景：

点了一杯奶茶外卖，在本地生活 APP 里通过直播能够看到小哥哥正在制作谁的订单，我排在第几号了，线下门店的卫生情况、制作过程、客流量、商品咨询都可以在直播间里了解到
在支付宝小程序里，边看直播边抢主播发来的口令红包
在阿里健康的消费医疗直播间里，跟今日特约的医师进行线上咨询
最近在计划一趟旅行，在飞猪APP里通过直播看着小姐姐介绍航旅套餐，还有小窗合流的当地风景观光片
...

除了导购直播、客服直播、医疗直播、手艺直播等等，我们还能看到各种风格类型和互动形式的台网联动直播、秀场直播、晚会直播，以下是今年承接的几场大型互动晚会：

这些直播无论内容和互动有什么样的区别，他们都有一个共同的特征：直播间右上角「淘宝直播」的水印
问个问题，所有这些类型的直播间，都是淘宝直播的开发同学支持的吗？这需要一个多么庞大的技术团队呢？答案是这个团队其实很缺人，所以他们「勤奋」地做了一件「偷懒」的事情：ALive 开放，让阿里经济体里需要直播能力的业务能自主接入、自主开发，于是就有了今年百花齐放的直播生态。

ALive演进

ALive 的使命是汇集淘宝直播强大的音视频处理能力，提供直播、互动、营销一体化解决方案，实现「生态开放、直播未来」的愿景。

时移到2018年7月，当时的淘宝直播还是小作坊模式，所有的业务对接都由淘宝直播技术团队承接，各团队都在超负荷工作。随着对接的外部业务越来越多，各类直播间定制化需求越来越高，技术团队开始构思开放之路，解放一方生产力，赋能二方、三方直播能力。

▶ 分析

直播对于观众来讲其实就是两个诉求：观看直播、参与互动。来看下当时的淘宝直播是如何满足用户这两个诉求的：

整体结构分为两部分：一个是直播能力，一个是互动通信能力。通过直播能力，观众能观看直播流；通过互动通信能力，观众能在直播间里参与实时互动。

直播能力：最简单的模型就是“两端加一服”，即推流端、播放端、流媒体服务器。主播通过推流客户端进行直播推流，我们提供了PC端推流工具和淘宝主播APP进行ARTP低延时推流，流媒体服务经过转码、切片、存储、分发等，供播放端拉流播放。
互动通信能力：主播在中控台创建、管理直播，开播后推送互动，经过业务服务调用和消息下发，端上渲染业务组件。当时的架构，每一个组件都跑在独立的Weex容器或H5容器里。

**▶ 问题
**
直播能力主要由淘宝直播音视频团队提供，依托阿里云构建了完整的音视频端到端闭环，包括音视频编解码、传输通道、网络调度技术，提供超低延时、超高画质、超大并发访问的音视频服务。二、三方业务只需要接入播放器 SDK ，主播使用我们的推流工具，即可支持直播能力。

互动通信能力主要依赖端侧的技术架构，从上图的架构可以看出两个核心痛点问题：

性能低下：每个组件都是独立的 Weex/H5 页面，内存占用较高，直播间流媒体播放已经占用了较高的内存水位，多个 Weex/H5 叠加后加大了 Crash 风险。同时各组件间相互独立，资源重复加载，加载性能也较差

效能低下：前端组件由客户端挖坑位的方式加载 bundle ，开发、调试环境强依赖客户端，直播环境搭建、消息模拟、数据 Mock 、日志查看、代码调试等链路都非常复杂，开发效率极其低下

▶ 解法

前端的技术工作大部分都在解决两个「能」的问题：性能和效能。针对上述痛点，技术侧需要做两件事情：一是构建一个灵活、高效的直播容器，解决性能问题；二是提供一套直播间组件开发的工程体系，解决效能问题。在性能和效能都得到提升后，将这些能力通过 ALive 开放平台开放给二、三方业务接入，基于这些思考，我们升级了直播架构：

直播容器的核心区别，是由原来每个组件独立为一个Weex/H5容器，变成只保留一个Weex容器，通过这个直播容器来动态加载组件。

**
▶ 技术实现**

1、直播容器

我们设想的灵活、高效的直播容器，应该具有以下几个特征：

统一规范的组件消息协议：包括组件包名、组件行为、业务自定义字段等，统一由 PowerMessage 的固定消息下发
支持动态加载：直播间不同于其他详情页，互动的发送依赖主播操作，也依赖用户进入直播间的时机，每个用户参与到的互动可能都不一样，所以互动组件的动态加载对首屏性能很关键
缓存及依赖去重：同一个互动，主播可以多次推送，各个互动依赖的基础库（rax-xxx、universal-xxx）也存在较多重复，所以设计合理的缓存和依赖去重机制对性能提升也很重要
HOC高阶组件：直播间里的业务开发不同于其他独立的源码页面，比如直播间数据获取、消息和事件监听、横竖屏状态获取、带小窗跳转、直播观看时长等等都依赖直播间环境或者客户端API，业务组件都需要这些基础能力，需要通过HOC来增强业务组件

基于这些特征设定，我们设计的直播容器技术结构如下：

直播容器的核心工作流程包括以下几点：

消息和指令：容器初始化时从Native获取缓存里Mtop请求的组件列表，同时消息模块监听Native转发的固定消息。协议解析成标准化指令，交给渲染模块执行后续操作
渲染管理：渲染模块接收到创建、更新、销毁组件指令后，传递给组件HOC，如果是创建组件指令，则从加载引擎拉取组件bundle
加载引擎：rloader维护了组件缓存，当拉取的组件不在缓存内时，会解析依赖，优先从缓存的基础依赖里查找基础组件，如果没有则combo拼接，最后拉取最小量的组件bundle，并将拉取的bundle加入缓存
组件HOC：高阶组件除了上述的能力，还提供了API Bridge、全局变量注入、事件分发以及一些监控容错等机制

2、 ALive工程体系

笔者加入淘宝直播后接手的第一个项目，是由客户端同学开发的 H5 版本亲密度组件，直播间里的组件开发强依赖客户端环境，当时的开发调试手段只能通过 Charles代理本地静态资源，没有日志、没有断点、没有 Mock ，开发环境极其恶劣。

引入直播容器后，改善了性能，但是在直播间里开发组件，需要一个完整的直播间环境和直播容器才能开发调试，没有配套的工程体系，组件开发依然很低效。我们设想的ALive工程体系，应该包含以下几个部分：

ALive def 套件：直播间组件开发脚手架，增强调试能力，包括直播间模拟、调试代理、热更新、编译检测等功能
直播间 Debug 工具：基于直播容器开发一个Debug 组件，提供日志调试、容器化 API 调用、数据 Mock、消息 Mock 等功能
VS Code 插件：直播间 Debug 工具在 PC 端的同等方案，结合模拟器可以独立在 PC 端开发调试

基于这些诉求，我们设计的 ALive 工程体系技术结构如下：

效果演示：组件代码热更新

效果演示：VS Code插件Mock消息

效果演示：VS Code 插件 Mock 直播间数据

▶ 数据表现

业务数据上通过 ALive 开放带来的外部流量早已超过百万 DAU ，每一个对接方都蕴含着一个大的垂直市场。

技术数据上直播容器的稳定性较好，组件的渲染时长由于并发请求限制，还存在一定的优化空间。ALive工程体系建设带来的提效非常明显，通过团队日常排期表数据粗略统计，开发效能提升大约在30%左右。

ALive展望

**▶ 业务侧：ALive互动市场
**

今年猫晚直播间里所有的互动都由优酷侧同学通过ALive接入开发，我们看下猫晚同时在线观看人数的曲线图：

这张图里有个比较有意思的规律：猫晚同时在线人数的每一次峰值，都对应有互动的推送。这里有两点思考，第一是我们提供的直播容器其实是跑在刀尖上的，每一次峰值都是一次检验，所以对于直播容器除了前面提到的灵活、高效，还有一个更重要的要素，那就是稳定，这个稳定一方面依赖服务提供方，也就是淘宝直播技术团队的技术保障，另一方面依赖服务调用方严格遵循直播间互动接入SLA。第二个思考，优酷侧这次开发了这么多互动组件，能沉淀复用吗？

嗯，这个问题亚博科技的同学已经给出了答案。今年阿里88会员节演唱会里的互动由亚博科技同学通过ALive接入开发，Bingo幸运球玩法效果非常不错，晚会结束后亚博科技同学主动提出将Bingo玩法沉淀到日常，于是有了后面的连连看、招财猫。招财猫互动在今年的双11活动期间，为直播间促活停留数据带来了非常不错的增长：

基于这些实践经验，ALive后续会规划互动市场，将各方业务开发的互动玩法按照拉新、促活/停留、转粉、成交、回访等维度进行分类管理，其他业务可以通过玩法优势、使用范围、已接入业务效果等选择复用组件，也可以为互动团队提供更多的数据参考，集中精力生产、迭代更优效果的直播互动玩法。

▶ 技术侧：小程序直播开放

在我们讲开放的时候，经常提到的几个关键词是轻量、灵活，但我们发现手淘端外业务在直播接入过程中，需要接入播放器SDK和Weex SDK才能满足直播能力，接入成本依然较高。前端将视角瞄向了小程序体系，期望不依赖SDK来满足其他APP端内的直播诉求。目前我们已经实现了支付宝端小程序直播（支付宝搜索淘宝直播即可体验），目前还有两件事情需要突破：

提供类似于Rax直播容器的小程序直播容器，提供二、三方组件开发能力
和支付宝端对接过程中，我们大部分精力在处理播放的问题，比如iOS/Android端播放控制不一致、H.265播放黑屏等。如果换一个客户端，是否要重新再对接一遍？

针对第一个问题，已经有可行方案，区别于Rax体系下的组件动态加载，小程序体系下需要预定义好组件使用范围，通过Page生成服务产出对应的Page Bundle。针对第二个问题，鉴于我们团队之前自研了基于WebAssembly的Web端播放器，我们一直在探索将该前端方案的播放器迁入小程序体系，实现前端的播放方案，解决播放器SDK版本限制的束缚，这个突破会极大程度地降低直播接入成本。

另一方面我们团队在尝试通过H5接入ARTC低延时方案，实现H5端的低延时推拉流方案，如果该方案也能在小程序体系下跑通，意味着二、三方业务将能通过H5/小程序实现推流、拉流、播放，形成web和小程序侧的音视频闭环。技术上进一步降低接入成本、增强通投能力，更轻量、灵活、稳定的ALive开放体系，将给业务带来更强劲的推力。

最后

▶ 关联项目

媒体智能：直播、短视频从生产侧到消费侧的媒体智能方案。直播互动目前都是传统互动，互动和流内容是割裂的。直播间里的AR/AI玩法有机会给用户留存和观看时长带来较大提升，设想在直播间里抢的红包雨可能是由主播通过手势挥洒出来的、李佳琦喊出“Oh My God”的时候自动跳出字幕特效等等，除了玩法增强，媒体智能还能提供更智能化的服务，比如主播展示商品时智能识别，用户可在流画面内点击商品直接购买等等，场景非常丰富。团队自研的媒体智能编辑器 Media AI Studio已经产出原型版本，整体项目旨在通过媒体智能工具链和工程化体系建设，将智能玩法开发周期提效成“7+3+1”模式（7天算法开发、3天玩法编写、1天素材制作，即可上线一个全新玩法）