tubi Tubi 为什么？

旅途结束，回顾是最好的离别礼物。Tubi是一家独特的创业公司。站在外人的角度，很难想象这样一个工程师不到30人的公司同时维护5大产品线:20多种客户端软件(而且还在增加)；50多种自主开发或第三方后端服务(甚至第三方也需要部署升级记录度量等维护工作)；完整的广告系统；复杂的数据管道和个性化引擎；；此外，新开发的下一代转码系统可与网飞媲美。做同样的事情，葫芦岛有数百(甚至数千)名工程师，而网飞有数千名工程师。所以，在我引以为豪的同时，我也常常在想，到底我们做对了什么，才导致了这个结果？毛在《实践论》中说:认识始于实践，实践之后，我们得到理论上的认识，需要回到实践中去。本文希望对理论认识进行探索和总结，以指导我接下来的实践。

先从这五条产品线面临的挑战说起，来看看吐比的研发。为了避免太长的文字，我主要讲1)客户端软件2)后端服务3)转码系统。

客户端软件

对于像Tubi这样的流媒体服务，它的客户端越多，它可以接触到的用户就越多。当用户在某个时间打开某个设备，使用我们服务的概率就越大。所以我们需要支持尽可能多的主流客户(就北美市场而言)。而为了最好的体验，自然可以是原生的，只是原生的。所以iOS/android/roku这样的战略平台，我们都是用原生代码来完成的(这些平台就不说了)。Over The Top/smart TV(以下简称OTT)有很多类别，虽然单个的每一个都不在一个位置上，但是综合起来的统计数字是巨大的。从R&D的角度来看，我们不能单独实现它们，所以我们选择html5应用程序或混合来统一实现它们。

即使html5应用统一使用，也有两个棘手的问题:

每个厂商都有各自的 SDK 或者 API。所以要支持数量众多的 OTT 产品线，到具体的执行细节，还有很多很多要单独处理的部分，尤其是 video player。由于使用 html5 app，每种客户端我们都需要部署其对应的 server 端，和 client 端的代码一同完成 app 的功能。十多个 app，每做一个功能，除了功能本身的 UT 外，这么多平台的 end-to-end testing，就是件让人头疼的事情；部署更是如此。

要迎接这样的挑战，一个解决办法就是跳到人身上，每个人(每几个人)对一个产品负责；另一种方法是拥抱技术，尽可能将重复的工作外包给设计良好的架构，并将脚本或软件自动化。如果人手不够，还要救更多的人，加工程师的目的是为了加强自动化，让架构更好，而不是在执行层面上搞蛮力。

Tubi选择了后者。我们的目标很明确:写一次，到处跑。

对于第一个挑战，我们设计了一个通用层来处理网络、指标、分析和非视频播放器功能；；对于视频播放器，构建了一个抽象的播放器层来处理广告回放、广告跟踪等。最后，在这个通用层上，我们构建每个特定平台的视频播放器。

对于第二个挑战，我们已经构建了一套完整的基础架构和部署流程。这意味着如果我们构建一个新的平台，只要遵循一套既定的接口，就可以快速生产出相应的OTT产品，然后通过一个部署命令将产品上线。在这个命令之后，有一个巨大的工作——服务器应该被部署，度量应该被收集，并且诸如consul、invite和datadog之类的工具应该执行它们的职责；代码要适当打包——不同的OTT也要考虑不同的打包方案:有些智能电视只有50M的内存，运行时react很容易崩溃，所以我们根据需要选择react的替代品，把死代码消除到极致。

这是从技术角度减少丰富的产品线对人的依赖。在今年三月之前，我们的网络/ott团队只有五个人(只有两个高级工程师)。我们不搞996，两个Sr. eng日常管理任务很多，但是十几个平台的产品线处理的井井有条。

拥抱优秀的架构、拥抱自动化和简化复杂性是我们在客户(以及整个R&D)方面的成功。

后端服务

对于视频点播服务，后端服务主要是高效稳定地提供客户端可访问的视频列表。这个很好说，不是提供一系列API从DB读取数据，然后做一些业务逻辑处理，然后返回数据吗？就是这么回事，但是做好其实很难。我在一篇文章中写道:

电影的窗口期有时候比较复杂，可能同时有多个窗口，组成一个栗子:

美国用户一季度可以在 roku，xbox 上访问美国用户三季度可以在 web，iphone，ipad，android 上访问加拿大用户 3-4 月可以在 appletv 上访问英国用户 12/1 - 12/15 日可以在 firetv 上访问

当这些规则需要根据访问者的上下文(当前日期、地点、播放平台)每一个API请求来计算时，效率很低，即使缓存使用很多，对于95%的瓦片响应时间来说也不会有太大的提升。我们用nodejs和jison开发了一个规则解析器(参见我的关于如何使用jison的文章)，性能不错，但是本质上没有特别的飞跃，所以我们发现了一些新的东西，开发了一个策略引擎来解决这个问题。在策略引擎的研发过程中，我们发现虽然以数据为代码的方式一次性计算出当前上下文中是否可以播放大量视频的速度极快，但随之而来的重新编译时间却是一个瓶颈。如果这个瓶颈得不到解决，我们可能会有一个窗口期来提供不该提供给用户的视频，这将是一个非常严重的问题。

摆在我们面前的方法有两种——一种是回到之前规则解析器的中庸之道，不出错；另一个是将重新编译时间优化到可接受的范围。

我们选择了正确但极其艰难的道路。经过不断的打磨，我们终于把重新编译的时间从10分钟缩短到了20秒。在这里，我们发现了酏剂在极端情况下的一些问题(如反复编译，atom会耗尽)并反馈给社区；出于这个原因，我们开发了一个自动编译器服务来处理酏服务中这种可能的、通用的动态重新编译情况。

策略引擎已经将我们的服务性能提高了一个或多个数量级，因此各种API可以随意构建它们想要的功能。通过政策引擎，我们学到了一个关键的认知——量变真的能导致质变:当业绩提高一到几个数量级，整个世界都会不一样。之后在Tubi，我们尽量优化这个量级，让产品和R&D的潜力得到极大的释放，从而把“没有意义”的问题变成“为什么没有意义”的问题。

当我们在做后端服务的时候，尤其是在早期的API系统中，一个主要的挑战就是如何让平庸的程序员产生相对高质量的API接口和代码。所以我们除了有一个好的架构之外，还提供了一套简单的定义API的DSL，让很多正确的事情可以自动发生，这是我的系列文章中提到的，就不赘述了。此外，我们还提供方便非工程师使用的DSL、方便工程师调用的引擎和SDK，如策略引擎、物化引擎、邀请/数据平面SDK和A/B测试SDK。这些DSL、引擎、SDK在简单的API下隐藏了很多细节，让整个团队受益。

多说DSL。大约一年半以前，我定义了一个feed DSL来描述来自内容合作伙伴的feed的元数据如何对应于Tubi内部的系统。提要的类型是xml/json，每个域的位置和名称都不一样，甚至数据类型也不一样，但是都有标题、时长、deion、主演、图片、视频url等信息。我们之前的做法是一个类处理一个feed，大致相同，但是处理细节差别很大，最后形成了一个冗长混乱的几十个文件的代码库。从其中抽象出feed DSL后，我们只需要编写一个解析器，根据DSL中的描述进行相应的转换。以前每次添加新的feed都要工程师半天到一天(Copy & amp；paste & amp；修改)；当核心feed逻辑出现bug时，工程师需要修复好几天，确保同样的问题不会在几十个feed的源代码中再次出现。我们在一年半前重写了这部分逻辑之后，feed解析器几乎没有什么变化，添加一个新的feed，非工程师也能快速编写，不容易出错。关于这方面的细节，你可以看看。

转码系统

转码(video转码)是VOD业务的亮点之一，将原始视频文件转换成各种客户端都能流畅播放的格式和大小。在Tubi，我们的一个原始视频需要转码为十多个不同的码率和大小，我们的合作伙伴往往会批量给我们视频资源，所以我们的转码队列中往往会有上百个视频等待转码。

一个两个小时的视频，转换成十多个不同的结果，在c 4.4x大型机器上需要十多个小时。如果你的整个视频库很小，每天都有几个或者几十个视频要传输，这不是问题。在托比，2017年，北美观众可以播放的视频将超过网飞。同时，由于我们业务的特殊性(视频有多个可播放窗口)，我们整个媒体库比我们能播放的视频高一个数量级。所以我们每天都有很多视频等待转码。网飞的转码技术在世界上是独一无二的，尤其是它的并行转码能力，可以在几分钟内完成别人能完成的事情。在Tubi，我们学习了网飞的思路(网飞有一个关于其管道的简单博客)，然后三个半工程师经过几个月的努力，用酏剂构建并发布了一个高度可扩展的转码引擎，以及从内容合作伙伴上传到我们转码完成的一整套解决方案。这个引擎可以把一个大的视频文件切割成上千个块，每个块(或者几个块)被分配到一个有几百个核的集群中的一个核上单独转码，然后做后续处理。如上所述，当性能提升一到几个数量级时，整个世界将以前所未有的方式呈现在你面前。在这种强大的转码能力的支持下，我们的整个内容管道已经跳出了传统视频点播制造商的视野，瞄准了新的领域(我们还不能说)。

摘要

很多问题往往大到一定规模，真正的难度就浮出水面了。流媒体业务不是什么难事。从表面上看，托比似乎和她的竞争对手没有什么不同。但是，在竞争对手(如Crackle)投入大量资金进行营销和用户获取的同时，Tubi却把钱花在了研发上。在2月份的纳帕年度非现场高管会议上，首席执行官法尔哈德向我们讲述了他在营销和研发:D愿景方面的经验——他说，他希望在未来三年内，我们在技术(尤其是机器学习)方面积累的技能可以使Tubi在用户获取方面的支出接近零，这样我们就可以将节省下来的所有资金分散到研发:D，以进一步扩大与R&D竞争对手在能力方面的差距。所以，回答为什么Tubi最重要的答案是我们的原则:

把赚来的钱投入研发。

这听起来很平常，大家都知道真相；但是，很难知道什么是容易做到的——坚持，全心全意的坚持，太难了:20多年过去了，伟大的中国就是最好的注脚。荀子说:“小水滴汇成大海，龙就诞生了。”四年来，Tubi一直在做菜，一点点放进去，直到今天。

正因为如此，在这次AVOD(Ads支持VOD)马拉松比赛中，Tubi逐渐超越，成为第一组的领跑者。当Tubi将其R&D功能定位于能够处理世界上最大的高级内容时，竞争对手仍对MAU着迷；堆满了钱；虽然Tubi正在将一个又一个关键的研发能力建设得更好，但其竞争对手仍对金钱堆积的市场意识着迷。AVOD割据如战国七雄，吐蕃竞争对手如昏庸失望的楚国，或只知空的齐国。

在“不断把研发赚来的钱投入进去”的基础上，Tubi逐渐形成了自己的研发方式——我总结的几个原则是:

Build things that a magnitude better.Build architecture, interfaces, engines, SDKs, DSLs and processes that makes average brains capable to produce outstanding results.Put money on building (or acquire) tools to solve the problems, rather than putting money on people to repeatedly deal with the problems.Build the invisible competitive advantages that take time.

话说到这份上，你一定有个疑问: