ReaderMX.
爱奇艺技术产品团队

爱奇艺私有云Serverless实践

爱尚刘炎约 9 分钟
4月10日下午，爱奇艺技术产品团队举办了“i技术会”线下技术沙龙，本次技术会的主题是“云原生落地探索与实践”，邀请快手、百度和字节跳动的技术专家，与爱奇艺技术产品团队共同分享与探讨云原生落地的实践经验。
其中，来自爱奇艺的技术专家尚刘炎为大家带来了爱奇艺私有云Serverless实践的分享，本场分享一共有三个关键词：Serverless、私有云和落地实践。
PS：关注公众号，在后台回复关键词“云原生”，就可以获得本次i技术会嘉宾分享PPT和录播视频。
以下为“爱奇艺私有云Serverless实践”干货分享，根据【i技术会】现场演讲整理而成。

爱奇艺私有云Serverless实践/

爱奇艺基础架构部 尚刘炎

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

01

什么是Serverless
在介绍什么是Serverless的时候，希望通过回答一些问题帮助大家了解什么是Serverless。一个最好的问题就是——Serverless是不是就是FaaS？
下面是维基百科对“Serverless”的中文和英文的解释：
Image
Image
中文解释为Serverless就是FaaS；英文解释就比较丰富了，它把Serverless分成Runtime和Databases，FaaS相当于是Runtime类别的产品，所以这方面的误解还是挺多的。
现在市面上的一些Serverless服务，比如AWS和阿里云:
AWS Serverless服务：
Image
Image
阿里云Serverless服务：
Image
阿里云目前官网上的展示还不是很全面，实际上它的服务还要更多一些，与AWS差不多，但AWS区分比较合理，把Serverless服务分计算、应用集成、数据分布，阿里也有一个划分，不过没有AWS的那么详细。
到这里就可以发现FaaS和Serverless有些区别了，整体来看FaaS服务，是Serverless计算服务的一部分。除此之外，亚马逊还提供了ECS、EKS，也是可以提供Serverless计算的服务。另外应用集成在这方面的成果就更丰富了，最常用的是SQS，不需要关注资源的一个消息中间件，数据存储也有Serverless的DB。
目前来讲，提供无需关注底层基础设施的服务可以称为Serverless，那么无需关注底层基础设施可以怎么理解呢？
首先是我们不去维护这下面的底层基础设施；其次是不关心它的资源的扩展情况，就像DB，我们知道它是可能运行在K8S集群上，也知道它有内存有CPU有磁盘，但我们并不需要关心这些资源的情况。
那么公司在做私有云时想去实施Serverless建设应该从哪儿开始做起？这也是一个问题。

02

私有云和公有云的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本身是持续扩展的，其优势是按调用次数计费，所以对于很多公司，尤其初创公司来说这是非常好的应用场景。
爱奇艺也有图片服务，我们也觉得这个案例很适合我们作为第一个可以落地的场景推广。但我们在和图片服务团队沟通的时候发生了一个比较戏剧化的场面👇
Image
这次对接后，我们意识到，公有云推广的方案在私有云不好使，主要原因有两个：
1）FaaS确实做不了复杂的功能(2018年)，而且容器编排服务已经很好用了（对后端工程师来说）；
2）按需付费这些功能，根本不在私有云的考虑范围之内。
那么，私有云真的需要Serverless吗？
如果需要，是什么形式的呢？
私有云真的需要Serverless吗？
首先，公有云的FaaS的作用是为了将其他公有云服务连接起来。它是云计算成熟到一定程度(云原生)的产物，而私有云一般达不到这种成熟度。并且，私有云推进基础架构达到公有云的程度也不现实，因为两者目的不同。
是不是我们提升私有云的基础架构体系的成熟度，就可以再做Serverless这个方案了？
其实这也不现实，因为从2015年到现在，公有云已经达到规模效应了。私有云做架构的时候有意的规避了这个问题，要和公有云做一些区别，更多的支撑我们自己的业务。所以，从这个角度来看，我们在做Serverless方案的时候如果参照公有云，其实是走不通的。
如果私有云真的需要一种Serverless服务，它应该是什么样的？
公有云用Serverless连接公有云的服务，那么私有云Serverless应该是连接私有云特有的服务、不能被公有云取代的服务，更多是应用级别的服务——私有云事件驱动的路线；
另外，对于后端工程师的技术栈来说，私有云的FaaS可能不那么便捷，但对于前端来说就不一样了，因为前端对服务端不那么了解。另外，我们可以看到阿里云的Serverless的最佳实践和案例上，都有很多的前端BaaS方向，这两年前端比较大的趋势也是这个方向；
最后，Serverless对于私有云的帮助，主要是生产力的提升，而不是公有云宣传的资源成本节约。

03

如何落地Serverless方案？
首先要因地制宜。
我们本身团队在基础架构部门，离前端比较远，应用事件驱动的方向比较适合我们团队推进。
公有云也有事件驱动方向的产品，比如AWS的EventBridge（下图），一种Serverless的事件总线服务。
Image
这个服务不仅可以通过事件触发服务，还可以做事件的组合。举个爱奇艺的实际例子，一个视频生产完成、人工审核通过且AI审核没有通过，当这三个事件都发生之后会触发人工再审核的操作。如果不用事件总线服务，这个流程其实很麻烦，要先缓存到这几个事件，另外中间可能会接收大量的消息，这时还要单独做一个组件去完成。使用Serverless的事件总线服务，可以节省我们很多维护成本，提升开发的效率，还能帮助架构做一些解耦。
2019年公司推进中台化，团队希望能在中台化的过程中落实这个技术方案。
分析中台的架构后，我们发现很多中台并不产生新的、更有效的服务，它只是把原有的服务组合起来。随着中台化演进，我们可以和负责中台的团队协作，让他们把事件接入事件总线。我们有这个想法，也找了团队去沟通，但还是有新的问题出现。中台业务团队的目的是为了解决中台化的问题，没有多余的精力帮助我们开放事件。于是我们又进一步分析了中台团队的主要问题。起先我们认为，做中台的架构无非是把原有的单体服务连接起来，但实际上，这些单体服务本身提供的服务的接口是异构的。另外，把这些服务组合起来看起来只是一个工作流，但可观测性、任务重试、超时、熔断等等一系列问题也要解决。
于是我们想是不是可以设计一个Serverless服务，它可以支持不同的服务的调度，无需运维的，同时它的可观测性是自动生成的。这样的服务可以帮助中台团队解决工作上的问题。在实际应用中，无论AWS还是阿里云也有这样的服务，比如AWS的做Step Function。我们解决这个问题做的服务，就是Airworkflow。
Image
图注：为中台而生的Serverless服务——Airworkflow
工作流通过一个状态机描述语言进行定义，私有云没有必要和公有云一样，只需尽量解决自己的问题，采用了CNCF开源的Workflow标准，选择其中应用比较广泛的状态优先实现；按照这个标准在底层用基于Knative Serving和Eventing基础上做的实现。
下面是观测性问题的改造。
在观测性问题方面，Airworkflow方案有特别大的便捷性，用户在描述状态机的时候，相当于直接将业务标签提前打好了，代码与状态机配置相关联，所以标签可以自动生成，真正实现了，写完代码以后，后续的可观测性内容是按照业务自动构建的。这对于中台来说是一个特别便捷的一个功能。
另外前文提到，我们团队想让中台团队把中间事件开放出来，所以其实在做workflow标准时，我们把这点也考虑进去了。如下图黄色标记的，中间有一个关键字可以把结果按照一定标准格式开放出来。
Image
那么什么是业务事件？
业务事件，是私有云、公有云最大的区别。公有云的事件是消息队列里面会多一条数据，而私有云事件，是一个服务级别的事件，是创建定单成功，支付成功等业务事件。如果开发的时候接收的都是这些事件，那么我们的很多应用将非常容易扩展。
Image
图注：业务事件
如上图所示，最右边紫色的块是log，是打好标签的，可以很清楚的定义出属于哪个步骤。
为了便于用户接入，我们也开发了一个Dashboard平台。
Image
图注：Airworkflow Dashboard
在对接Airworkflow的时候，团队发现大家对Serverless的接受程度还是不高。虽然也有业务方愿意接入，但都要我们做演示，把前因后果讲述一遍，拿技术文档一步步指引操作，整个对接周期一般要一周左右，换个人又得重新来一遍。
公有云在做推广的时候也遇到一样的问题，他们解决的方法就是频繁的布道，这个方法需要很多人力，不适合私有云。
上述问题不只我们面临过，比如滴滴，在业务推广初期面临过没有司机就没有用户，没有用户也没有司机的问题，这个问题的解决需要建立起正向的循环，我们也希望通过构建服务，完成我们的增长飞轮。
Image
图注:构建增长飞轮
现在Airworkflow已经有服务接入了，团队目前正在做事件总线Eventgateway。事件总线做完以后，可以推动我们FaaS迭代。
用户在用这些服务的同时，对Serverless接受程度会提高。接受度的提高会催使他使用别的服务，这样我们最左边的循环就能打通了。
但这个打通的成本是什么？是我们不遗余力的推广，甚至手把手的教用户改造。由于人力的限制，我们希望构建一个生态，让已经接入的用户，把他们的经验推广出去。
后续我们会做一个Dev App store，将一些事件和Function，以打包的形式作为内部开源的产品交付给用户。用户通过这种低门槛的方式，接触了解Serverless，进而提高对Serverless服务的接受程度，后续就更容易使用其他服务，这样互相促进，完成我们整个的服务的闭环。
Q&A
提问：目前Serverless平台都是支持无状态函数的，未来会不会支持有状态函数？
刘炎：有状态的服务相对无状态要复杂的多，如果你的服务是有状态的，应该先构建为单体的微服务，业务场景经常要把这些微服务连接起来，这个“连接起来”就是我们Airworkflow要做的，目前最佳实践是这样的。

KEEP THE THREAD GOING

更多来源文章