爱奇艺私有云 Serverless 实践

近日，爱奇艺技术产品团队举办了“i 技术会”线下技术沙龙，本次技术会的主题是“云原生落地探索与实践”，邀请快手、百度和字节跳动的技术专家，与爱奇艺技术产品团队共同分享与探讨云原生落地的实践经验。

其中，来自爱奇艺的技术专家尚刘炎为大家带来了爱奇艺私有云 Serverless 实践的分享，本场分享一共有三个关键词：Serverless、私有云和落地实践。

本次分享的第一部分内容是带大家了解 Serverless 这个概念。第二部分说明下公有云和私有云下 Serverless 服务的区别。第三部分是爱奇艺具体落地的一些策略和方案，及其经验分享。

什么是 Serverless

在介绍什么是 Serverless 的时候，希望通过回答一些问题帮助大家了解什么是 Serverless。一个最好的问题就是——Serverless 是不是就是 FaaS？

下面是维基百科对“Serverless”的中文和英文的解释：

中文解释为 Serverless 就是 FaaS；英文解释就比较丰富了，它把 Serverless 分成 Runtime 和 Databases，FaaS 相当于是 Runtime 类别的产品，所以这方面的误解还是挺多的。

现在市面上的一些 Serverless 服务，比如 AWS 和阿里云:

AWS Serverless 服务：

阿里云 Serverless 服务：

阿里云目前官网上的展示还不是很全面，实际上它的服务还要更多一些，与 AWS 差不多，但 AWS 区分比较合理，把 Serverless 服务分计算、应用集成、数据分布，阿里也有一个划分，不过没有 AWS 的那么详细。

到这里就可以发现 FaaS 和 Serverless 有些区别了，整体来看 FaaS 服务，是 Serverless 计算服务的一部分。除此之外，亚马逊还提供了 ECS、EKS，也是可以提供 Serverless 计算的服务。另外应用集成在这方面的成果就更丰富了，最常用的是 SQS，不需要关注资源的一个消息中间件，数据存储也有 Serverless 的 DB。

目前来讲，提供无需关注底层基础设施的服务可以称为 Serverless，那么无需关注底层基础设施可以怎么理解呢？

首先是我们不去维护这下面的底层基础设施；其次是不关心它的资源的扩展情况，就像 DB，我们知道它是可能运行在 K8S 集群上，也知道它有内存有 CPU 有磁盘，但我们并不需要关心这些资源的情况。

那么公司在做私有云时想去实施 Serverless 建设应该从哪儿开始做起？这也是一个问题。

私有云和公有云的 Serverless 服务的区别

现在有这么多 Serverless 服务，但在 2018 年的时候是没有这么多选择的，而且我们看到维基百科(中文)从 2019 年没有再更新，这不是偶然，因为在这之前我们认为 Serverless 就是 FaaS。所以 2018 年，爱奇艺开始实施 Serverless，第一件事儿就是把 FaaS 搭建起来。

在 2018 年，开源社区可参考的内容也是很少的。现在比较成熟的 Serverless 有两个方案，Knative 和 OpenFaaS，Knative 在 2018 年 1 月 31 号才开源发布出来，OpenFaaS 当初是个人项目，后来才成立了公司。

技术选型的时候我们也比较纠结，因为没有好的方案。作为内部创新的项目，公司投入的人力非常少，我们当时特别希望社区能够提供一些支持，但当时整个社区并没有成熟的方案，也不确定未来哪个方案会成为主流。后来我们选择了 Fn 这个项目，现在已经 16 个月都没有更新了，项目已经确定停更了。当时选择这个项目，主要有以下几点考量：

第一，Fn 项目是 Oracle 开源的 Serverless 项目，我们觉得 Oracle 是一家 ToB 端比较领先的公司，应该比较擅长做这类服务，项目发展应该会很顺利；

第二，当时公司容器编排用 Mesos，Fn 在 Mesos 上的支持比较多。

综上所述，Fn 项目对当时的爱奇艺来说是最合适的选择。

我们在 Fn 上面做了一些公司内部服务的集成，完成 MVP 版本后，想找一些业务作为抓手驱动后续开发。当时参考了 AWS 的一个经典案例，弹性的图片 resize 服务。这个案例非常贴切 FaaS 应用场景：FaaS 的优势是无需管理服务器,图片 resize 也是比较简单的函数操作，不需要很多的代码去完成；另外 FaaS 本身是持续扩展的，其优势是按调用次数计费，所以对于很多公司，尤其初创公司来说这是非常好的应用场景。

爱奇艺也有图片服务，我们也觉得这个案例很适合我们作为第一个可以落地的场景推广。但我们在和图片服务团队沟通的时候发生了一个比较戏剧化的场面。

这次对接后，我们意识到，公有云推广的方案在私有云不好使，主要原因有两个：

1）FaaS 确实做不了复杂的功能(2018 年)，而且容器编排服务已经很好用了（对后端工程师来说）；

2）按需付费这些功能，根本不在私有云的考虑范围之内。

那么，私有云真的需要 Serverless 吗？

如果需要，是什么形式的呢？

私有云真的需要 Serverless 吗？

首先，公有云的 FaaS 的作用是为了将其他公有云服务连接起来。它是云计算成熟到一定程度(云原生)的产物，而私有云一般达不到这种成熟度。并且，私有云推进基础架构达到公有云的程度也不现实，因为两者目的不同。

是不是我们提升私有云的基础架构体系的成熟度，就可以再做 Serverless 这个方案了？

其实这也不现实，因为从 2015 年到现在，公有云已经达到规模效应了。私有云做架构的时候有意的规避了这个问题，要和公有云做一些区别，更多的支撑我们自己的业务。所以，从这个角度来看，我们在做 Serverless 方案的时候如果参照公有云，其实是走不通的。

如果私有云真的需要一种 Serverless 服务，它应该是什么样的？

公有云用 Serverless 连接公有云的服务，那么私有云 Serverless 应该是连接私有云特有的服务、不能被公有云取代的服务，更多是应用级别的服务——私有云事件驱动的路线；

另外，对于后端工程师的技术栈来说，私有云的 FaaS 可能不那么便捷，但对于前端来说就不一样了，因为前端对服务端不那么了解。另外，我们可以看到阿里云的 Serverless 的最佳实践和案例上，都有很多的前端 BaaS 方向，这两年前端比较大的趋势也是这个方向；

最后，Serverless 对于私有云的帮助，主要是生产力的提升，而不是公有云宣传的资源成本节约。

如何落地 Serverless 方案？

首先要因地制宜。

我们本身团队在基础架构部门，离前端比较远，应用事件驱动的方向比较适合我们团队推进。

公有云也有事件驱动方向的产品，比如 AWS 的 EventBridge（下图），一种 Serverless 的事件总线服务。

这个服务不仅可以通过事件触发服务，还可以做事件的组合。举个爱奇艺的实际例子，一个视频生产完成、人工审核通过且 AI 审核没有通过，当这三个事件都发生之后会触发人工再审核的操作。如果不用事件总线服务，这个流程其实很麻烦，要先缓存到这几个事件，另外中间可能会接收大量的消息，这时还要单独做一个组件去完成。使用 Serverless 的事件总线服务，可以节省我们很多维护成本，提升开发的效率，还能帮助架构做一些解耦。

2019 年公司推进中台化，团队希望能在中台化的过程中落实这个技术方案。

分析中台的架构后，我们发现很多中台并不产生新的、更有效的服务，它只是把原有的服务组合起来。随着中台化演进，我们可以和负责中台的团队协作，让他们把事件接入事件总线。我们有这个想法，也找了团队去沟通，但还是有新的问题出现。中台业务团队的目的是为了解决中台化的问题，没有多余的精力帮助我们开放事件。于是我们又进一步分析了中台团队的主要问题。起先我们认为，做中台的架构无非是把原有的单体服务连接起来，但实际上，这些单体服务本身提供的服务的接口是异构的。另外，把这些服务组合起来看起来只是一个工作流，但可观测性、任务重试、超时、熔断等等一系列问题也要解决。

于是我们想是不是可以设计一个 Serverless 服务，它可以支持不同的服务的调度，无需运维的，同时它的可观测性是自动生成的。这样的服务可以帮助中台团队解决工作上的问题。在实际应用中，无论 AWS 还是阿里云也有这样的服务，比如 AWS 的做 Step Function。我们解决这个问题做的服务，就是 Airworkflow。

图注：为中台而生的 Serverless 服务——Airworkflow

工作流通过一个状态机描述语言进行定义，私有云没有必要和公有云一样，只需尽量解决自己的问题，采用了 CNCF 开源的 Workflow 标准，选择其中应用比较广泛的状态优先实现；按照这个标准在底层用基于 Knative Serving 和 Eventing 基础上做的实现。

下面是观测性问题的改造。

在观测性问题方面，Airworkflow 方案有特别大的便捷性，用户在描述状态机的时候，相当于直接将业务标签提前打好了，代码与状态机配置相关联，所以标签可以自动生成，真正实现了，写完代码以后，后续的可观测性内容是按照业务自动构建的。这对于中台来说是一个特别便捷的一个功能。

另外前文提到，我们团队想让中台团队把中间事件开放出来，所以其实在做 workflow 标准时，我们把这点也考虑进去了。如下图黄色标记的，中间有一个关键字可以把结果按照一定标准格式开放出来。

那么什么是业务事件？

业务事件，是私有云、公有云最大的区别。公有云的事件是消息队列里面会多一条数据，而私有云事件，是一个服务级别的事件，是创建定单成功，支付成功等业务事件。如果开发的时候接收的都是这些事件，那么我们的很多应用将非常容易扩展。

图注：业务事件

如上图所示，最右边紫色的块是 log，是打好标签的，可以很清楚的定义出属于哪个步骤。

为了便于用户接入，我们也开发了一个 Dashboard 平台。

图注：Airworkflow Dashboard

在对接 Airworkflow 的时候，团队发现大家对 Serverless 的接受程度还是不高。虽然也有业务方愿意接入，但都要我们做演示，把前因后果讲述一遍，拿技术文档一步步指引操作，整个对接周期一般要一周左右，换个人又得重新来一遍。

公有云在做推广的时候也遇到一样的问题，他们解决的方法就是频繁的布道，这个方法需要很多人力，不适合私有云。

上述问题不只我们面临过，比如滴滴，在业务推广初期面临过没有司机就没有用户，没有用户也没有司机的问题，这个问题的解决需要建立起正向的循环，我们也希望通过构建服务，完成我们的增长飞轮。

图注:构建增长飞轮

现在 Airworkflow 已经有服务接入了，团队目前正在做事件总线 Eventgateway。事件总线做完以后，可以推动我们 FaaS 迭代。

用户在用这些服务的同时，对 Serverless 接受程度会提高。接受度的提高会催使他使用别的服务，这样我们最左边的循环就能打通了。

但这个打通的成本是什么？是我们不遗余力的推广，甚至手把手的教用户改造。由于人力的限制，我们希望构建一个生态，让已经接入的用户，把他们的经验推广出去。

后续我们会做一个 Dev App store，将一些事件和 Function，以打包的形式作为内部开源的产品交付给用户。用户通过这种低门槛的方式，接触了解 Serverless，进而提高对 Serverless 服务的接受程度，后续就更容易使用其他服务，这样互相促进，完成我们整个的服务的闭环。

Q&A

提问：目前 Serverless 平台都是支持无状态函数的，未来会不会支持有状态函数？

刘炎：有状态的服务相对无状态要复杂的多，如果你的服务是有状态的，应该先构建为单体的微服务，业务场景经常要把这些微服务连接起来，这个“连接起来”就是我们 Airworkflow 要做的，目前最佳实践是这样的。

本文转载自：爱奇艺技术产品团队（ID：iQIYI-TP）

原文链接：爱奇艺私有云Serverless实践