爱奇艺 App 中台技术实践

关注我们,设为星标,每天7:30不见不散,架构路上与您共享 
回复"架构师"获取资源

大家好，我是架构君，一个会写代码吟诗的架构师。

本文整理自爱奇艺研究员谢国在 ArchSummit 全球架构师峰会上的演讲。

提到中台的话，不得不提阿里了。2015 年，阿里的 CEO 张勇发了封内部信说，要全面启动阿里的中台战略，构建符合时代的“大中台、小前台”的组织机构和业务机制。

从左边的单项目、单平台变成右边的联合中台模式。提出这个战略的背景，主要是因为当时经过一个跑马圈地的时代，留下了一个标志物，就是“烟囱式开发”：淘宝技术团队当时支撑的是淘宝和天猫，然后 1688 技术团队支撑 1688，这种开发模式有 3 个弊端：

1. 重复功能建设

2. 烟囱相互之间没有任何沟通和交流

3. 不利于业务的沉淀和持续发展

所以阿里就成立了共享事业部，将通用的业务抽象出来，沉淀在中台，包括用户中心、商品中心、交易中心等。

看一下中台的定义，其实中台来源于前台，它更多的是为前台的创新，还有快速迭代服务。所以说中台是位于前台和后台之间的一层。相对于前台来讲，它比前台要更稳定；相对于后台来讲，它比后台要更加灵活。中台的意义在于企业级能力复用平台：

• “企业级”定义了中台的边界跟范围

• “能力”定义了中台的主要承载对象

• “复用”的话，定义了中台的核心价值

• “平台“是我们中台的主要表现形式

除了爱奇 App，可能很少人熟悉爱奇艺其他的 App。爱奇艺的 CEO 龚宇提出了一个苹果树的概念，在爱奇艺的内容上面，希望通过爱奇艺内容孵化出一些其他的产品。比如像爱奇艺的二次元小说、漫画、知识付费等。

既然有了这么多的产品，那么就有了建立爱奇艺 App 中台的必要性。从三方面考虑，专业深度、人力资源、用户体验。

这个是爱奇艺中台演进历程。在 2018 年以前，当时爱奇艺的四大 App 基本上就是一套代码，同一个工程。后来每一个 App 都成立了一个单独的团队，我们把代码还有开发资源完全的隔离开，并且在这个过程中，将通用的组件给拆分出来。这个时候开始做大量的解耦工作。然后在 2019 年，一边做解耦，一边在搭建爱奇艺 App 中台。

在未来，除了要服务好公司内部的各种业务，还有对外提供 SaaS 服务，特别是爱奇艺的一些合资的子公司，也要为他们做好支撑。

谈到解耦，就不得不提一个迭代效率的问题。一个团队规模基本上决定了一个迭代效率的瓶颈。

1. 对于一个 10 人以下的小型团队来讲，这时候更多讲究的是团队成员的独当一面，基本上就奉行“拿来主义”。

2. 然后到了一个中型团队，一个人英雄主义承担不了这么大规模的东西。所以这时候就强调一种组件化解耦模块化，让大家专注在自己能做的事情上面。这个时候强调的是边界弱耦合的组件化。

3. 接下来到了一个大型团队，这时候除了组件化之外，还强调业务之间的并行迭代能力。但是随着工程规模的成长，组件化拆分的改造成本会呈指数性增长。

爱奇艺在 2018 年开始就投入了大量的人力和物力去做各种解耦的事情。所以特别提个经验教训，小团队的时候，能够解耦的尽早解耦。

爱奇艺 APP 中台效果，跟中台合作最紧密的极速版和国际版就有这样的反馈，“从人力资本上是巨大节约，参考基线 100 开发 + 规模，极速版和国际版同等功能只有 20 开发规模；同时中台也能将技术做深做细；开发经验和流程也能共享”。

这个是中台的架构图，底层是中台门户。因为所谓的中台化就是企业级能力复用平台，所以中台化就是通过平台化去发现、沉淀跟复用企业级能力。所以最重要的首先是打造一个中台门户，提供统一接入、统一门户、统一账号、权限和文档的事情。上面是移动开发基础框架，提供从开发、测试到运营的一站式解决方案，包括一些框架组件、业务组件、基础组件，还有后台的一些组件服务；还有高可用高性能的平台，发布运营平台，研发支撑平台等。最上层就是支撑各个业务 App。

首先就是最底层的中台门户 QMAS，它的全称叫 QIYI Mobile Application Studio。当时做这个平台之前，收集了各种反馈，特别是新 App 的反馈。对于新 App 来讲，首先反应就是开发一个新的 App，冷启动的时间特别长，公司到底有哪些后台服务？有哪些 SDK？文档在什么地方？通通都不知道，遇到了很多问题。

1. 曾经有团队反馈，他们一个 App 从立项到正式上线花了大概三个月时间，大量的时间花在寻找各种文档上，以及找各岗位帮忙对接的事情上。

2. 爱奇艺 App 里面 APM 日活数据，竟然连公司的前台都有权限看。

3. 每次搭建一个新系统，都要搭建一套自己的权限管理管控，甚至每一个系统之间定义的产品线都是不一样的。繁冗的事情很多，根本没时间做数据沉淀。

针对上面提到的情况，开发了我们自己的中台叫 QMAS。平台整合有三方面优势，第一：一站式服务接入，提供一些工单权限申请。第二：统一的决策管控，各平台不会存在角色之间互相不一致的情况。第三：一站式浏览体验，尽量抹平各个平台存量差异，然后直接在 QMAS 上进行增量平台开发。

举一个例子，以前一个推送平台的申请，大概要两周左右。创建一个申请，然后给各个公司的商务做审批，再发给爱奇艺的推送，爱奇艺的消息系统再确认。这些都需要邮件来往，非常麻烦。现在直接在 QMAS 上一键申请就好了，接入效率大幅提升，且信息得到沉淀，还能复用 QMAS 的权限申请。

关于发布运营，这里着重介绍两个平台，一个是互动平台，一个是用户行为平台。以互动剧《他的微笑》为例。这里面提到一个分支剧情，你可以进行选择，像游戏一样。爱奇艺已经有好几部这种互动剧了。跟传统的一条故事线相比，我们提供一些分支剧情。甚至有些综艺频道，能够进行一些视角切换，比如说不同的导师的视角来看舞台。还可以提供一些竖屏的小视频互动。

IVOS 应用场景，第 1 个平台主要是给运营平台做一些配置策略和场景。还提供一些非剧情类的互动、气泡广告，这些都能做互动。第 2 个是互动制作平台。

另外搭建了一个叫做用户行为分析的平台，可以看到每一个场景，每个页面的流量是从哪里过来的，这个主要是给产品同学用，能看到用户行为路径大数据的可视化分析，能够知道用户的转换留存的原因，辅助实现业务的快速增长。

看一下研发支撑部分。这是最近刚成立的 10 人的虚拟小团队，在打造爱奇艺 CI/CD 研发中台，主要囊括项目管理平台，打包平台上线，还有版本管理以及渠道管理和运维管理运维平台。这是面向整个公司做的，另外也会监控整个流水线，还有各个后台的平台稳定性，服务器日志等。

SDK 对于移动中台来说是非常重要的，所以在 QMAS 搭建了一个 SDK 管理平台，就是为提供方和接入方搭建了一个桥梁：

• 对提供方来讲，可以非常方便的去创建发布，以及做一些成员管理。甚至测试可以针对 SDK 做一些预发布的测试。

• 对接入方来讲，可以非常方便的看到移动中台到底有哪些 SDK，哪个 SDK 具体什么作用。并且可以通过内部 IM 系统，直接找到对应的功能。

其次是搭建了一个移动 App 脚手架，将常用的一些功能、业务组件、基础组建、后台服务都陈列在脚手架上。脚手架有三大好处：提升开发效率，避免踩过的一些典型坑，以及为 App 建立一个一致的基础设施，方便做跨 App 的功能性升级。在新 App 已实验过，大幅提升了开发效率。

脚手架使用姿势也比较简单，首先是把代码拉下来，在 QMAS 上把各种后台申请下来之后，保存在基层配置里，之后基本上就能跑起一个可运行的 App 了，然后在上面再进行自己的业务开发。我们测出来一个新 App 的创建，大概从两个月左右缩短到两周，因为以前的很多繁冗的操作都不需要了。

接下来讲一下框架组件，大家知道移动应用的一个技术跃迁，从传统的 Web 开发，到开发独立 App，可以看到各种各样跨平台框架都出来了，所以大家希望一套代码实现在多个平台上，这时候就是所谓的分久必合的时代。特别是 5G、IoT 时代的到来，这个时候甚至可能要提供跨终端开发，这就叫分分合合时代。

当然我们现在处于跨平台时代，所以爱奇艺中台也沉淀了非常多的动态化框架，其他 App 想用都是比较方便的。H5、小程序、小游戏，还有最近的 Facebook RN，还有自己开发的一些插件化热修复框架，以及 Flutter。

这里重点介绍一下 Qigsaw 框架。Google 开源 Google APP bundles 之后，我们看到一丝曙光，就是可以复用 APP Bundles。Google 将他的一些组件插件放在 Google Play Store 上面，然后底层的 runtime 负责合并和加载。

而我们要做的事情，就将它的 runtime 替换成 Fake 的一套，保证 runtime 接口是完全一样的，用爱奇艺的 CDN 替换 Google Player。原理就是基于 Google 一些原生的 App Bundles 工具链，山寨 Play Core Library，直接复用到原生的一些开发工具类和文档，开发体验非常好，稳定性非常高，我们只有一处 Hook，从 4.0 开始就支持了。另外就是国内国际双轨制可以做无缝切换，对于国内的开发来讲，它只用 Qigsaw 开发框架就好了，而对于国外的用户来讲，直接用 App 的开发环境就好了。

目前已经在非常多的 App 落地了，崩溃率在爱奇艺上几乎为 0，启动成功率在 99.5% 左右。

讲完了框架组件的话，接下来看一下高可用高性能。提到高可用高性能、高稳定性，首先想到的可能就是 APM。APM 现在提供了这么多功能，从崩溃异常和用户交互，网络热修复，用户调试，以及帧率、ANR 等。APM 对后台提供实时性、大数据、全覆盖，还有很多维度的支撑。

通过对一些设备进行数据采集，经过 CDN 和 QLB 的 Balance，然后再到 Nginx，最后收集到 HBase 和 ES 里面。经过符号解析，到前端展示。一旦报警，通过内部 IM 或者邮件进行通知。

除了 APM，我们成立了一个虚拟团队，在打造一个全链路的监控平台，主要作用就是通过统一的投递规范，然后收集整个端到端的日志、链路数据，实现链路可视化。可以非常方便的看到链路瓶颈，进而做一些可优化的事情。另外可以做监控报警，实现故障快速定位。目标是线上定位问题的效率能够缩短至 20 分钟。

除了全链路监控，我们打造了一个移动日志平台，实时记录一些重要的日志，当触发一些异常场景，会自动把它上传。

最后再讲一下无线网络基础组件，包括网关和 HTTPDNS。从有线网络进入到无线网络之后，因为有些网络相对于无线网络，他的拓朴结构变得复杂了很多，多了无线基站，核心网络等。所以这个时候会出现很多问题，比如用户说网络太卡了，页面打不开，然后又有各种植入广告。然后 DNS 信息的话，各种运营商的 DNS 又不靠谱，他们 TTL 甚至一个月之后才生效。还有用户可能被调度错误，武汉用户可能被调度到北京的机房去。

针对这些问题，我们提供了一些 HTTPDNS 的网关方案。当然还有一些小的像客户端的一些复合连接等。然后 DNS 主要是起到一个防劫持，另外一个是做容灾的作用。特别是后台出了问题，我们可以及时的做一些更新调度，由于离用户侧比较近，所以调度会比较及时。

还有就是提供了一个网关方案，是一个自定义的 Protobuf 协议，好处有 4 点：

• 没有 SSL 消耗，像 iOS 必须使用 HTTPS，有网关自定协议的话，可以绕开限制；

• 劫持成本比较高，因为是自定义的协议；

• 提供一个比较稳定的长连接系统；

• 节省建连时间，因为是一个稳定的长连，所以 TCP 的三次握手基本上不需要，可以作为一个域名的收敛方案。

大家所有的网络连接，从原来的连接各种各样的业务后台，到现在直接连一个通用网关代理，帮你做域名转发的事情。