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

✪ “疯狂的”淘宝直播间 ✪

今年直播又火了！

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 容器，通过这个直播容器来动态加载组件。

本文转载自淘系技术公众号。

原文链接：https://mp.weixin.qq.com/s/L5lggzXju1ajAjUfaaDGLw