本文从内容中台角度出发,以图片生产服务为切入点,结合对Serverless的理解,讨论其应用场景落地与实践。
01
什么是Serverless
Serverless,顾名思义,就是无服务器,是一种按需提供后端服务的方法。Serverless提供程序允许用户编写和部署代码,而不必关心底层基础结构。尽管称为无服务器,但仍使用物理服务器,只是开发人员无需了解它们。总结下来,评判一个服务是否是Serverless的,最关键的一点是是否需要关心服务器。下面我们举个例子找找感觉。
比如CDN,我们把静态资源发布到 CDN 之后,就不需要关心 CDN 有多少个节点、节点如何分布,也不需要关心它如何做负载均衡、如何实现网络加速。那它就是一个Serverless的服务。
我们似乎对Serverless找到了一些感觉,FaaS,BaaS又是什么?他们和Serverless有什么关系呢?
FaaS(Function as a service),函数即服务。FaaS显然是Serverless的,但不能狭隘地认为Serverless=FaaS。举个经典的例子,我们写一段hello world代码并部署到FaaS平台,不依赖任何后端服务。这种自嗨式的服务就是FaaS本尊。
BaaS(Backend as a service),后端即服务,代表了一些后端的云服务,比如云数据库、对象存储、消息队列等。我们在使用他们的时候,不需要关心他们是如何部署的,能抗住多大的并发。因此BaaS也是Serverless的实际的业务开发中,我们很少遇到单纯的FaaS应用场景,通常需要依赖一些后端的服务,比如日志服务、数据库、缓存、存储等等。因此从技术角度讲,Serverless=FaaS+BaaS。
02
内容中台为什么使用Serverless
开发人员的基本诉求
节约服务器资源,实现降本增效。
快速迭代、极速部署,作为服务开发者,都希望可以把精力放到业务之上,减少CI/CD的投入。
HA、动态扩缩容,现在是微服务开发,服务拆分得越来越多,越来越细,如果每个服务都考虑HA、扩容的问题,意味着投入更多精力。
内容中台属性
从内容中台角度讲,通用服务可以更好地服务于业务,这也是中台的战略方向。通用服务建设的好坏,直接影响中台建设质量。图片生产服务目前在爱奇艺服务100多个业务方,因此服务的稳定性、HA、动态伸缩能力至关重要。这种前提下,减少定制化开发、部署,就能节约不少工作量。
图片生产服务属性
图片生产的特点使得服务的拆分粒度更细,除了微服务之外,还需要提供上面提到的自嗨式FaaS服务,比如图片的裁剪、缩放、打水印、生成二维码服务。服务多且杂,亟需降低对服务的各种成本。
因此对内容中台来讲,这种细粒度的服务越多,使用Serverless带来的收益就越大。
03
图片生产应用案例
自嗨型FaaS
这种服务只提供图片处理的相关操作,主要服务于内部编辑,目的是提供同步的图片制作工具。例如图片合成、裁剪缩放、二维码生成、视频抽帧等等,目前总共提供了12+FaaS服务,应用于20+个业务场景。这些FaaS服务为编辑的线上工作提供了方便,将编辑线下的制作(如使用PS)迁移到线上。
对于图片生产开发人员来说,Serverless可以说最大程度降低了其工作成本,开发人员只需把精力专注在图片的生产逻辑上面,之后只需简单填写一些服务名称、资源配额、扩缩容策略,即可完成服务的部署。
此外,Serverless为我们提供了一种更加精细化拆分服务及功能再组合的理念,此前我们为了部署方便,将这些图片处理服务打包在一起部署一个大服务,每个子服务的变更都需要一次完整的部署,并且在资源控制方面也无法做到精细化,毕竟每种图片FaaS服务对资源的消耗还是不同的。
同步FaaS+BaaS
在自嗨型FaaS的基础上,增加了BaaS服务的依赖。例如图片同步生产服务,这个服务将处理完的图片,上传至云存储,并调用第三方API分发至CDN。分发至CDN的图片,需要统一规格(格式、质量因子等)进行处理,以减少带宽使用,提升端加载图片的速度。服务虽然经过了三个步骤,但总体还算轻量,非常适合CMS图片上传这种需要快速生产的应用场景。
异步事件驱动
前两种应用,依赖使用方的调用。但有些业务场景可能会带来不便,比如有很多用户上传图片的场景。按照传统流程来看,业务除了将图片上传至云存储,还需要额外触发一次生产任务。如下图:
可以看到,上传与生产严重脱节,虽然这样可以走得通,但图片生产与业务方耦合过于紧密。Serverless出现之后,其经典的事件驱动模型,给应用的形态提供了丰富的可能性。图片服务除了业务主动的同步http、异步消息触发之外,还有很多其他有趣的应用场景。例如上例,可以将业务主动的触发,改为自动的云存储异步事件触发,这样一来业务不需再主动触发图片生产,实现了解耦。其次,虽然Serverless可以不需要考虑资源的动态伸缩情况,但同步的处理能力还是会有上限。这样即使在高并发下,也可能会因为资源过度消耗产生问题。下面是爱奇艺某业务的图片异步事件驱动案例:
当图片上传至云存储后,触发一个异步事件,驱动图片处理函数进行压缩、加水印,然后再进行持久化的“一条龙”服务。图片的处理逻辑完全与业务解耦,业务只需进行云存储的上传,而不必再调用一次进行图片处理。如此也可轻松应对高峰流量,实现削峰填谷。
Serverless工作流
除了上面的例子,爱奇艺还有不少其他图片生产业务。这些业务各有各的生产需求,比如A业务需要经过AI智能识别,B业务需要先从视频中抽图,C业务需要对图片进行增强。难点在于如何用一个抽象的流程,对现有Serverless服务进行复用组合,统一支持不同业务的生产需求。
此前我们使用第三方工作流系统进行流程的编排,驱动生产流程,后来引入了serverless工作流。
现有工作流系统虽然能满足我们的需求,但是存在不少问题。
维护成本极高。为了满足业务运行需求,我们使用了几十台虚机部署工作流实例,无论是扩容或是虚机下线,都给我们带来了极大的维护工作量。
资源部署复杂。为了避免业务之间相互影响,无论是工作流实例或依赖的中间件,都需要划分生产线,进行资源的隔离。
与业务系统耦合。在工作流与业务系统解耦方面,虽然我们做了不少工作,但还是无法做到100%,还是时常会产生修改工作流代码满足业务需求。
配置复杂。对流程编排的配置,需要大篇幅的配置文件才能完成,且学习成本高。
基于以上问题,我们引入了Serverless工作流,替代传统工作流系统进行流程的编排。下面以动图的生产为例,做进一步说明。
可以看到这个相对复杂的流程,不需要外部工作流引擎驱动,全部依靠Serverless事件驱动自动触发。开始通过输入的参数进行分支选择判断,当输入分别是原始视频、mp4片段、动图时,选择不同的函数进行处理。随后通过串行及并行的图片处理函数,完成动图的生产。
工作流下沉到云端之后,业务开发完全不需要关心工作流的维护、部署、耦合等,且配置也可以做到灵活、简单。
维护成本低。不再需要考虑虚机扩容下线等问题,对虚机的维护成本降低为零。
部署架构简单。无需关心依赖中间件,生产线等资源隔离问题。并且资源利用率提升将近60%。
完全解耦。只需专注于业务逻辑,不再需要维护工作流系统代码。
配置灵活简单。配置这样一个流程,仅需不到100行配置文件,配置工作量节省了90%。
04
总结与展望
总结几个关键词,解耦、异步、工作流、函数拆分及再组合。
图片生产服务后续会进一步推动Serverless的落地。在事件驱动方面,将与云存储深度合作,替代传统HTTP或消息触发,全面推广云存储变更事件的触发,实现图片生产与业务的全解耦。在工作流方面,目前对于Serverless工作流的使用还没有大面积铺开,绝大多数业务的图片生产还是依赖工作流系统,后续会加大落地力度,最终覆盖爱奇艺全业务的图片生产。
内容中台目前对于Serverless的应用仍处于初步阶段,无论是业务场景的覆盖度,还是数据规模都还不高。但通过上述实际的应用案例,可以看到我们在图片生产服务上,已经进行了比较全面的探索及实验,后续会在更多中台服务上实现落地。
也许你还想看
关注我们,更多精彩内容陪伴你!