查看原文
其他

爱奇艺私有云Serverless实践

The following article is from 爱奇艺技术产品团队 Author 尚刘炎

4月10日下午,爱奇艺技术产品团队举办了“i技术会”线下技术沙龙,本次技术会的主题是“云原生落地探索与实践”,邀请快手、百度和字节跳动的技术专家,与爱奇艺技术产品团队共同分享与探讨云原生落地的实践经验。
其中,来自爱奇艺的技术专家尚刘炎为大家带来了爱奇艺私有云Serverless实践的分享,本场分享一共有三个关键词:Serverless、私有云和落地实践。
以下为“爱奇艺私有云Serverless实践”干货分享,根据【i技术会】现场演讲整理而成。


爱奇艺私有云Serverless实践/

爱奇艺基础架构部 尚刘炎


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


01

什么是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建设应该从哪儿开始做起?这也是一个问题。

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本身是持续扩展的,其优势是按调用次数计费,所以对于很多公司,尤其初创公司来说这是非常好的应用场景。
爱奇艺也有图片服务,我们也觉得这个案例很适合我们作为第一个可以落地的场景推广。但我们在和图片服务团队沟通的时候发生了一个比较戏剧化的场面👇

这次对接后,我们意识到,公有云推广的方案在私有云不好使,主要原因有两个:
1)FaaS确实做不了复杂的功能(2018年),而且容器编排服务已经很好用了(对后端工程师来说);
2)按需付费这些功能,根本不在私有云的考虑范围之内。
那么,私有云真的需要Serverless吗?
如果需要,是什么形式的呢?
私有云真的需要Serverless吗?
首先,公有云的FaaS的作用是为了将其他公有云服务连接起来。它是云计算成熟到一定程度(云原生)的产物,而私有云一般达不到这种成熟度。并且,私有云推进基础架构达到公有云的程度也不现实,因为两者目的不同。
是不是我们提升私有云的基础架构体系的成熟度,就可以再做Serverless这个方案了?
其实这也不现实,因为从2015年到现在,公有云已经达到规模效应了。私有云做架构的时候有意的规避了这个问题,要和公有云做一些区别,更多的支撑我们自己的业务。所以,从这个角度来看,我们在做Serverless方案的时候如果参照公有云,其实是走不通的。
如果私有云真的需要一种Serverless服务,它应该是什么样的?
公有云用Serverless连接公有云的服务,那么私有云Serverless应该是连接私有云特有的服务、不能被公有云取代的服务,更多是应用级别的服务——私有云事件驱动的路线;
另外,对于后端工程师的技术栈来说,私有云的FaaS可能不那么便捷,但对于前端来说就不一样了,因为前端对服务端不那么了解。另外,我们可以看到阿里云的Serverless的最佳实践和案例上,都有很多的前端BaaS方向,这两年前端比较大的趋势也是这个方向;
最后,Serverless对于私有云的帮助,主要是生产力的提升,而不是公有云宣传的资源成本节约。

03

如何落地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要做的,目前最佳实践是这样的。

参考阅读


原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。



高可用架构
改变互联网的构建方式

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存