表0-1 云计算面临的问题和机遇
图0-3
IaaS
、PaaS
、SaaS
的区别
Serverless
的发展速度要比想象中的更快。在这一年,Google
发布了Knative
,一个基于Kubernetes
的开源Serverless
框架,具备构建容器、流量调配、弹性伸缩、零实例、函数事件等能力。AWS
发布了Firecracker
,一个开源的虚拟化技术,面向基于函数的服务,创建和管控安全的、多租户的容器。Firecracker
的目标是把传统虚拟机的安全性和隔离性与容器的诉求和资源效率结合起来。在这一年,CNCF
也正式发布了Serverless
领域的白皮书CNCFServerlessWhitepaperV
1.0,阐明Serverless
技术概况、生态系统状态,为CNCF
的下一步动作做指导Serverless
将会在接下来的十年间被大量采用,将会得到飞速的发展BaaS
存储服务会被发明,以扩展在Serverless
计算上能够运行更加适配的应用程序类型。这样的存储能够与本地块存储的性能相匹配,而且具有临时和持久两个选项x
86微处理器更多的异构计算机Serverless
架构下的编程更安全、易用Serverless
将会接入更多的后台支撑服务,如OLTP
数据库、消息队列服务等Serverless
将会成为云时代默认的计算范式图0-4
Serverless
发展历程
IaaS
、FaaS
到SaaS
,再到如今的Serverless
,云计算在十余年中发生了翻天覆地的变化,从虚拟空间到云主机,从自建数据库等业务到云数据库等服务,云计算发展迅速,没人知道云计算的终态是什么App
),建立在云服务生态之上,包括数据库(Parse
、Firebase
)、账号系统(Auth
0、AWSCognito
)等。这些服务最早被称为Baas
(BackendasaService
,后端即服务)FaaS
(Functionsasaservice
,函数即服务)。AWSLambda
是目前的热门FaaS
实现之一MartinFowler
的描述可以总结出FaaS
、BaaS
以及Serverless
之间的关系,如图11所示图1-1
Serverless
架构的组成
Serverless
所谓的“无服务器”并不是“没有服务器”,而是说Serverless
的用户不再需要在服务器配置、维护、更新、扩展和容量规划上花费时间和资源,可以将更多的精力放到业务逻辑本身,至于服务器,则“把更专业的事情交给更专业的人”去做,即由云厂商来提供统一的运维图12 不同角度上的
Serverless
的定义
图16
FaaS
解决方案组成
EventSources
:将Event
触发或流式传输到一个或多个函数实例中FunctionInstance
:可以根据需要扩展单个函数/微服务FaaSController
:部署、控制和监视函数实例及其来源FaaS
解决方案使用云厂商提供的其他云服务,例如云数据库、身份校验等图1-7 函数部署流水线示意图
图1-9 函数调用类型
图1-14 虚拟机、容器、
Serverless
架构演进简图
图1-15 传统项目上线和
Serverless
下项目上线对比图
Serverless
的缺点也逐渐地暴露了出来,例如函数的冷启动问题,就是如今颇为严峻且备受关注的问题图1-16 函数计算根据流量进行函数扩缩示意图
图1-17 函数冷启动产生示意图
图1-18 本地与
FaaS
的函数调用区别示意图
图1-20 函数启动的四个部分
图1-21 函数冷启动常见解决方案
图1-22 函数预热常见方案
图1-23 函数池化程度示意图
Serverless
架构还存在着厂商锁定等比较严重的问题。厂商锁定问题是很多人非常在意的表1-1 不同云厂商/产品所提供的典型场景表
图1-25 数据
ETL
处理示例
AI
模型完成训练后,在对外提供推理服务时,可以使用Serverless
架构将数据模型包装在调用函数中,在实际用户请求到达时再运行代码。相对于传统的推理预测,这样做的好处是,无论是函数模块、后端的GPU
服务器,还是对接的其他相关的机器学习服务,都可以按量付费以及自动伸缩,从而在保证性能的同时确保服务的稳定,如图127所示图1-27
AI
推理预测处理示例
IoT
、5G
、区块链等技术的快速发展,对去中心化、轻量虚拟化、细粒度计算等技术的需求也愈发强烈,Serverless
必将借势迅速发展图2-1
CNCF
列出的FaaS
平台
AWSLambda
的函数管理页面有一个比较有特色的设计,即Designer
(函数概览)。Designer
可以直观地显示用户的函数及其上游和下游资源。用户可以使用它跳转到触发器、目标和层配置GoogleCloudFunction
采用运行时机制,支持Node.js
、Java
以及Python
等语言。用户可以通过直接上传代码、对象存储、云代码库、CLI
等方法对代码进行部署、发布以及更新。函数超时时间最长为540秒,具有自动调节能力。开发者工具包括CLI
命令行工具以及WebIDE
等图2-4
GoogleCloudPlatform
的Functions
产品页面
Kubernetes
(简称K8S
)是Google
开源的一个容器编排引擎,支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署应用程序时,通常要部署该应用的多个实例,以便对应用请求进行负载均衡CustomContainerRuntime
。众所周知,在云原生时代,容器镜像已经逐渐变成软件部署和开发的标准工具,阿里云函数计算为了简化开发者体验、提升开发和交付效率,特别提供了CustomContainerRuntime
。开发者将容器镜像作为函数的交付物,通过HTTP
协议和函数计算系统交互CustomContainerRuntime
的加持,绝大部分的传统Web
应用都可以以极低的改造成本体验到Serverless
架构带来的优势,甚至可以做到0改造上云。为了协助更多用户快速迁移传统Web
应用,阿里云函数计算开发了应用中心,可以实现快速在线迁移,如图27所示SCF
是实时文件处理和数据处理等场景下理想的计算平台Serverless
项目。包括OpenWhisk
、Fission
、Knative
以及Kubeless
等在内的众多优秀的开源FaaS
平台都已得到CNCF
认可图213 开源
FaaS
平台
表2-1 常见开源
FaaS
平台基本信息
Serverless
开源项目中,Knative
的优势也是较为明显的Knative
以Kubernetes
为底层框架,与Kubernetes
生态结合得更紧密。无论是云上Kubernetes
服务还是自建Kubernetes
集群,都能通过安装Knative
插件快速地搭建Serverless
平台Knative
联合CNCF
,把所有事件标准化为CloudEvent
,提供事件的跨平台运行,同时让函数和具体的调用方法解耦。在弹性层面,Knative
可以监控应用的请求,并自动扩缩容,借助于Istio
(Ambassador
、Gloo
等)支持蓝绿发布、回滚的功能,方便应用发布。同时,Knative
支持日志的收集、查找和分析,并支持VAmetrics
数据展示、调用关系跟踪等
Knative
工作原理如图2-14所示
Serverless
还有一些特性,所以要转变开发观念API
网关触发器会将二进制文件转换成字符串,不便直接获取和存储;API
网关与FaaS
平台之间传递的数据包有大小限制,很多平台限制数据包大小为6MB
以内;FaaS
平台大多是无状态的,即使存储到当前实例中,也会随着实例释放而使文件丢失图4-1 在
Serverless
架构下文件上传文件示例
FaaS
平台是无状态的,并且用过之后会被销毁,因此文件并不能直接持久化在实例中,但可以持久化到其他的服务中,例如对象存储、NAS
等图4-4 函数在线简单调试页面
Event
来模拟一些事件,如图45所示图4-5 通过设置
Event
模拟事件
图4-6 函数在线断点调试页面(一)
FaaS
平台都会为用户提供相对完备的命令行工具,包括AWS
的SAMCLI
、阿里云的Funcraft
,同时也有一些开源项目例如ServerlessFramework
、ServerlessDevs
等对多云厂商的支持Knative
是一款基于Kubernetes
的Serverless
框架。其目标是制定云原生、跨平台的Serverless
编排标准。Knative
通过整合容器构建(或者函数)、工作负载管理(动态扩缩)以及事件模型这三者实现其Serverless
标准图5-1 在
Knative
体系架构下各角色的协作关系
Serverless
框架,Knative
由3个核心组件组成Tekton
:提供从源码到镜像的通用构建能力。Tekton
组件主要负责从代码仓库获取源码并编译成镜像,推送到镜像仓库。所有这些操作都是在KubernetesPod
中进行的Eventing
:提供事件的接入、触发等一整套事件管理能力。Eventing
组件针对Serverless
事件驱动模式做了一套完整的设计,包括外部事件源的接入、事件注册、订阅以及事件过滤等功能。事件模型可以有效地解耦生产者和消费者的依赖关系。生产者可以在消费者启动之前生成事件,消费者也可以在生产者启动之前监听事件Serving
:管理Serverless
工作负载,可以和事件很好地结合,并且提供了基于请求驱动的自动伸缩能力,而且在没有服务需要处理的时候可以缩容到零。Serving
组件的职责是管理工作负载以对外提供服务。Serving
组件最重要的特性就是自动伸缩的能力。目前,其伸缩边界无限制。Serving
还具有灰度发布能力Serverless
架构的音视频处理会具备更高的效能,但是在进行大视频处理的时候,往往比较慢,此时还需要进一步优化业务代码。以视频转码为例,当有一个比较大的视频需要转码时,为了提升整体的效能,可先对视频进行切片,然后分别转码之后再进行合并,如图712所示图7-12 并行视频转码案例流程简图
图8-4 基于
Serverless
架构的图像识别功能流程简图
图9-1 前端技术发展简史
SSR
技术为例,在Serverless
架构下,前端团队不需要关注SSR
服务器的部署、运维和扩容,可以极大地减少部署运维成本,从而更好地聚焦于业务开发,提高开发效率。此外,前端团队也不必担心SSR
服务器的性能问题,从生产力的释放到性能的提升,更为明显地降本提效