Oh My God，揭秘淘宝直播流畅买买买的背后_语言 & 开发_淘系技术

9折倒计时一周！ QCon 全球软件开发大会·上海站讲师上线95% >>> 了解详情 



 写点什么

本文知识点提炼：
1、淘宝直播简介
2、四大保障手段
3、整体质量策略

淘宝直播简介

▐ 疯狂的淘宝直播

2019 年的双十一，淘宝直播又疯狂了一把！

双十一当天，淘宝直播成交近 200 亿！超过 50% 的品牌商家通过直播获得增长，直播成为了天猫双十一商家的标配。

▐ 增长背后的挑战

淘宝直播始于 2015 年，短短四年间打造了一个年成交千亿的行业，走出了一条与众不同的道路。在高速增长的背后是整个系统持续的稳定可靠，但是快速的业务迭代、复杂的系统设计和苛刻的成本控制给系统稳定性带来了不小的挑战。

电商直播是音视频、实时互动和电商交易的技术结晶，相比于传统的电商媒介（图文、视频）它的技术复杂度更高。整个技术框架由音视频流链路和电商/互动逻辑链路构成。音视频流主要涉及推流节点、中心流服务和播放节点；电商/互动逻辑核心是主播中控台、实时消息通道和互动播放。这些系统涉及到不同的技术架构，它们相互复杂地交织在一起，其中任何一个系统的变更都可能影响整个业务链路和逻辑。

随着 4G 移动网络普及，互联网内容从文字逐步演进到了视频、直播，直播形态的各种产品遍布互联网行业。移动时代直播本身就是一种新的产品形态，当它和电商交织在一起的时候就衍生出更多的可能。业务方往往要从这千万种的可能性中摸索出行之有效的业态和模式，而这种摸索意味着高强度的迭代和尝试。淘宝直播的客户端几乎以每周一个版本的速度前进，服务端更是以日在变化，我们同时维护着 8 个端；除此之外还要承接源源不断的合作诉求和大促职责。不停的迭代和变化确实能够带来产品的进化，但是过于频繁的变更也将系统的稳定性逼到了墙角。

除开前述的两点之外，直播的内容形式与曾经的图文是截然不同的。更加强调实时的互动、强烈的氛围和流畅的观看，而这些特点本身又对消息通道、网络和 CDN 等软硬件资源提出了更加苛刻的要求。

技术上必然追求最低的成本带给用户最好的体验，包括最小的带宽消耗、最大的机型覆盖、最清晰和流畅的观看体验。这就意味着，必须有一套有效的度量手段来评价我们的成本和产出让 ROI 最大化。

四大保障手段

淘宝直播的质量保障体系主要围绕着如何解决上述三大挑战来进行建设。限于文章的篇幅，会从最核心的四个方面来介绍如何有效地保障淘宝直播以及电商媒体的质量。

▐ 工具建设

俗话说“工欲善其事，必先利其器”。前文说过直播是一个迭代频繁的业务，测试人员在频繁的迭代下不得不面临一次次的测试和反复的业务回归。当业务高度复杂功能繁多的时候，这样的测试和回归简直就是噩梦。

以下图为例，图中展示了部分淘宝直播的互动玩法，通过主播中控台配置具体的互动玩法就能实时地投放到直播间与用户形成互动。但是不同的互动配置和不同的前端展现组合出大量的业务场景，仅靠传统的测试手段或者自动化是无法支撑的。

有什么更好的办法呢？回到业务逻辑实现，在拥有良好的编程规范的前提下，无论是客户端还是服务端，核心的业务逻辑实现是由各种内部或外部的接口组合而成。通过解构业务逻辑，再将接口组合成测试逻辑。仍旧以互动玩法为例，互动功能可以解构为互动服务、消息通道、主播服务和客户端渲染，将互动服务、消息通道和客户端渲染剥离再按照内置互动配置、调用消息通道接口触发客户端渲染的方式重新构建出新的功能，通过复用业务接口重新构建逻辑的方式可以将业务逻辑上不相关的能力关联起来形成一系列的测试工具。

对整个直播系统进行抽象解构，下图“业务域”内“的主播服务”通过消息通道和服务网关利用互动服务和直播基础服务与客户端进行交互，客户端自身具备通过服务端指令进行动态或者静态渲染的能力。在“测试域”内，可以将业务域解构的各个逻辑重新进行组合。

这种重组可以分为两个方面，客户端侧和服务端侧；在服务端侧不同的接口组合后可以重构出多维信息查询、互动模拟、开放验收等各种业务保障工具；在客户端侧基于动态、静态层和 native 的接口进行二次开发，将服务端信息和客户端本地能力聚合到测试专用的“调试浮层”便于快速能力验证、组件配置和信息透出等。

通过以上的思路，我们构建了成系列的直播（媒体）专用测试工具、打造了端侧媒体框架，全面提升了测试工作的效率，并以此为基础反复打磨形成一个完整的质量技术架构（见“整体质量策略-技术架构“）。

▐ 链路排查

仅仅通过测试工具提升效率是不够的，在快速迭代中会发生各种线上/线下的问题，问题的快速排查准确定位至关重要。淘宝直播的系统纷繁复杂，涉及到音视频流链路和电商/互动逻辑链路，横跨服务端、CDN、移动端和 PC 端。通常需要使用不同的工具、平台和手段进行问题排查，而且大多数时候平台之间数据无法关联互通。

因此需要为复杂的直播体系构建一套全链路的排查系统。工具建设是在接口层面进行业务解构和重新组合，那么链路排查也可以复用这种思想。不同的是要进行链路抽象和简化、业务流程划分、业务数据重组和排查流程构建。更直白的说，就是将不同的业务阶段和不同的技术平台进行抽象和划分；将同一技术平台的数据按照唯一的 ID 进行聚合，再将不同的阶段同一 ID 数据进行聚合；对于聚合在同一 ID 下的数据进行诊断，利用规则匹配、智能算法和人工经验；同时结合线下的测试工具，协助快速调试和复现。

▐ 数据分析

通过工具建设和链路排查再结合自动化手段，建立了高效的线上线下的质量保障能力；然而链路排查仅解决了具体的问题，对于系统和业务全局层面需要了解更多，例如线上整体质量状况、潜在问题的发现和预防、业务/技术效果评价等等。

在链路排查中，已经将不同业务阶段和技术阶段的数据进行了聚合和分析，在这些数据的基础上进行再加工，包括清洗、计算、聚合和分析，就能够将这些数据更有效地组织起来进行利用。

基于这样的想法，我们设计了一套数据分析的方法将数据划分为“大盘数据”、“纬度数据”、“详情分析”三个层次。

大盘数据主要针对线上的某个横向层面的整体分析和监控，一般划分为“业务”、“技术”、“舆情”、“异常”四个方面，大盘数据的波动意味着某个环节发生了问题。

在大盘的基础上按照不同的业务域和技术域进行拆分，每个域代表一个纬度的变化，每个纬度由多组该域内的指标构成；一般我们按照不同的端来划分技术域，按照不同的业务场景来划分业务域（图中仅为示意）。

当大盘、纬度划分清楚后，每个细节的数据指标都会归属到相应的“大盘”-“纬度”之下，再对这些细节的指标提供对比、趋势分析、多维度聚合等分析工具从而实现从全局到细节的分析和监控，针对特定的指标结合监控系统就能进行有效的告警。

这一整套数据分析的方法都建立在实时和离线的大数据分析平台之上。首先通过各端的上报工具采集原始数据形成实时数据流和转储的离线数据表；实时数据流通过实时计算平台(阿里云实时计算)对数据流进行清洗和计算；计算完成后将数据转储到搜索引擎，由引擎负责索引、排序和聚合；最后通过引擎接口返回给服务端，服务端可以对引擎提供的数据进行二次加工。

在整个过程中如果实时计算任务出现异常或者丢失，可以通过转储到离线表的数据进行补偿计算再流入到搜索引擎。