Serverless工程实践从入门到进阶

第0章从云计算到Serverless

表0-1　云计算面临的问题和机遇

图0-3　IaaS、PaaS、SaaS的区别

2018年，Serverless的发展速度要比想象中的更快。在这一年，Google发布了Knative，一个基于Kubernetes的开源Serverless框架，具备构建容器、流量调配、弹性伸缩、零实例、函数事件等能力。AWS发布了Firecracker，一个开源的虚拟化技术，面向基于函数的服务，创建和管控安全的、多租户的容器。Firecracker的目标是把传统虚拟机的安全性和隔离性与容器的诉求和资源效率结合起来。在这一年，CNCF也正式发布了Serverless领域的白皮书CNCFServerlessWhitepaperV1.0，阐明Serverless技术概况、生态系统状态，为CNCF的下一步动作做指导
Serverless将会在接下来的十年间被大量采用，将会得到飞速的发展

新的BaaS存储服务会被发明，以扩展在Serverless计算上能够运行更加适配的应用程序类型。这样的存储能够与本地块存储的性能相匹配，而且具有临时和持久两个选项
将出现比现有的x86微处理器更多的异构计算机
Serverless架构下的编程更安全、易用
Serverless将会接入更多的后台支撑服务，如OLTP数据库、消息队列服务等
Serverless将会成为云时代默认的计算范式

图0-4　Serverless发展历程

从IaaS、FaaS到SaaS，再到如今的Serverless，云计算在十余年中发生了翻天覆地的变化，从虚拟空间到云主机，从自建数据库等业务到云数据库等服务，云计算发展迅速，没人知道云计算的终态是什么

第一部分概念与产品

应用或服务来管理服务器端逻辑和状态的应用，这些应用通常是富客户端应用（单页应用或者移动端App），建立在云服务生态之上，包括数据库（Parse、Firebase）、账号系统（Auth0、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　函数预热常见方案

资源池化带来的效果可能不是热启动，可能是温启动。所谓的温启动是指实例所需要的相关资源已经提前准备了，但是并没有完全准备好的情况。所谓的池化就是在实例从零到一的过程中所进行的每一步准备工作，如图123所示

图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开源的一个容器编排引擎，支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署应用程序时，通常要部署该应用的多个实例，以便对应用请求进行负载均衡
阿里云函数计算处于“领导者梯队”，在2020年下半年率先推出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等
所谓的简单调试，就是在控制台进行调试。以阿里云函数计算为例，其可以在控制台通过“执行”按钮，进行基本的调试，如图44所示

图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还具有灰度发布能力