备受云厂商们推崇的 Serverless，现在究竟发展到什么水平了？

Serverless 是什么

根据 CNCF 的定义，Serverless 的概念是指构建和运行不需要服务器管理的应用程序。它描述了一种更细粒度的部署模型，在该模型中，应用程序被捆绑为一个或多个功能，被上传到一个平台，然后根据当前所需的确切需求执行、扩展和计费。

所以首先需要明确的一点是，Serverless 并非指托管和运行我们的应用程序不再需要服务器，而是指从前耗费研发和运维人员无数精力和资源的 CI/CD、服务器配置维护更新、IT 资源容量的规划和伸缩等工作，被 Serverless 这个概念下包含的技术体系所封装了。研发专注于业务逻辑的编写，运维向 SRE 转型，负责技术 SLA 的制定和保障工作。这也是技术体系又一维度的分层体现（其它类比汇编语言和高级语言，OS 和应用软件）。

Serverless 发展历程

什么背景下诞生了 Serverless

Serverless 所指向的基础设施架构，历史上经历了多次的迭代：从早期的 MVC（模型-视图-控制器）为主的单体形式，到后来的 SOA，再到最近十年兴起的微服务架构和云原生。整个基础支撑功能是逐步在拆分解耦，以垂直提升研发和运维效率。横向分层上，虚拟化技术打通了物理资源的隔阂，减轻了用户管理基础架构的负担。容器/PaaS 平台则进一步抽象，提供了应用的依赖服务、运行环境和底层所需的计算资源。这使得应用的开发、部署和运维的整体效率再度提升。在这样的背景下，Serverless 其实代表了一种更彻底的屏蔽与分层，将应用架构堆栈中的各类资源的管理全部委托给平台，免去基础设施的运维，使用户能够聚焦高价值的业务领域，进一步提高软件应用和运营的生产力。

图 1：应用架构与计算抽象的演进示意图

发展大事记

• 2006 年，伦敦的一家公司发布了名为 Zimki 的平台，该平台提供了端到端的 JavaScript 开发能力，并且最早提出了“Pay as you go”的概念，但在商业上并未取得显著成功。

• 2008 年，谷歌发布 App Engine 服务，用户的开发方式得到了根本的变革，无须考虑预分配多少资源，也无须考虑操作系统的实现。

• 2012 年，Ken Fromm 在《软件和应用的未来是 Serverless》中率先提出了 Serverless 的概念。

• 2014 年，AWS 重磅发布函数计算产品 Lambda，开启了 Serverless 架构的新时代。 2016 年，Azure Function、GCP（Google Cloud Platform）以及 IBM Open Whisk 相继发布 Serverless 计算平台。

• 2017 年，腾讯云和阿里云先后发布了 Serverless 计算产品——云函数和函数计算；同年，谷歌 GCP 发布了 Firebase 产品，提供多端一体化开发的 Serverless 解决方案。

• 2018 年，谷歌开源 Knative，尝试将 Serverless 架构标准化。同年，全球知名 IT 咨询调研机构 Gartner 发布报告，将 Serverless 架构列为十大未来将影响基础设施和运维的技术趋势之一。

• 2019 年，腾讯云和 Serverless.com 达成战略合作，共同开发 Serverless Framework 产品，提供 Serverless 开发的一站式解决方案；Microsoft Azure 也于 2019 年推出了 Azure Functions。

• 2020 年，Google Cloud 推出 Cloud Run 服务，AWS Lambda 支持 Ruby 等更多语言。

• 2021 年，AWS Lambda 引入新的 Lambda Edge 服务，它可以将内容置于全球 CDN 网络上，从而提供快速和可靠的服务

• 2022 年，阿里云宣布核心产品全面 Serverless 化。

模型架构及原语

Serverless 是一种“全托管”的架构理念，包括两个核心特征：一是按实际使用量付费，类似“电网”模式，按请求调用次数或是实际数据存储量，用多少付多少；二是自适应弹性、免运维。根据使用情况，云产品对底层资源进行自动伸缩，客户不需要提前预购资源，用完即回收。

Serverless 将提供服务资源的基础设施抽象成各种服务，以 API 接口的方式供给用户按需调用，真正做到按需伸缩、按使用收费。这种架构体系结构消除了对传统的海量持续在线服务器组件的需求，降低了开发和运维的复杂性，降低运营成本并缩短了业务系统的交付周期，使得用户能够专注在价值密度更高的业务逻辑的开发上。

目前业界较为公认的 Serverless 架构主要包含两个方面，即提供计算资源的函数服务平台 FaaS 和提供托管云服务的后端服务 BaaS。

函数即服务 (Function as a Service)

函数即服务是一项基于事件驱动的函数托管计算服务。通过函数服务，开发者只需编写业务函数代码并设置运行的条件，无需配置和管理服务器等基础设施。函数代码运行在无状态的容器中，由事件触发且短暂易失，并完全由第三方管理，基础设施对应用开发者完全透明。函数以弹性、高可靠的方式运行，并且按实际执行资源计费，如不执行则不产生费用。典型代表有 AWS Lambda、Azure Functions、Google Cloud Functions 和 OpenFaaS。

但现阶段函数即服务的局限性也较为明显。首先，代码调试较为复杂。FaaS 平台的代码调试大多需要下载到本地，调试成功后上传至函数，在线调试工具功能尚不完善，调试的复杂度较高。其次，低延时业务暂不适用。FaaS 中的代码通过事件触发，如果执行结束一段时间没有再次触发，执行函数的容器会销毁，再次启动会有启动的开销，增加启动延迟，所以目前不适用低延迟的业务，如金融交易等。

后端即服务 (Backend as a Service)

BaaS 的概念涵盖范围较广，覆盖了应用有可能依赖的所有第三方服务，如云数据库、身份验证 (如 Auth0、AWS Cognito)、对象存储等服务，开发人员通过 API 和由 BaaS 服务商提供的 SDK，能够集成所需的所有后端功能，而无需构建后端应用，更不必管理虚拟机或容器等基础设施，就能保证应用的正常运行。 典型产品有 APICloud、Bmob、友盟等。

目前常见的 BaaS 服务包括数据库管理、云存储、用户认证、推送通知、远程更新、消息队列。

Serverless 行业生态现状

目前 Serverless 的技术生态主要活跃在公有云的云函数服务领域，国内外主要云服务商都具备云函数产品。这主要是因为公有云的云函数服务拥有一系列完善的云计算资源，这使得 Serverless 能够更快地开发和部署应用程序。而且，公有云还提供了完整的安全体系，可以确保 Serverless 技术的安全性。此外，公有云的云函数服务也能够提供便捷的数据存储和管理，从而使 Serverless 应用更便捷、更高效。公有云服务基本可满足用户 Serverless 应用的搭建需求。私有云的解决方案领域仍旧以国外开源技术为主。

工具层来看，独立 BaaS 服务（开源、商业产品）主要由国外服务商提供，国内服务商提供的相关工具主要供给各自产品使用，普适多云平台的工具产品多集中在开发框架层面。

平台层

平台层提供全托管的运行环境，提供函数单元所需的计算环境并自行维护服务器资源、网络资源、消息分发和负载均衡等功能，是整个 Serverless 架构的基础。

国内主要公有云服务商均已推出云函数产品，开源的 Serverless 架构框架也层出不穷，下文将选取较为典型的几个平台进行介绍。

公有云函数计算服务

阿里云函数计算

事件驱动的全托管计算服务。通过函数计算，无需管理服务器等基础设施，只需编写代码并上传。函数计算会准备好计算资源，以弹性、可靠的方式运行代码，并提供日志查询、性能监控、报警等功能。

阿里云函数计算工作流程示意图

阿里云函数计算在视频解码场景中的流程架构

华为云函数工作流 (FunctionGraph)

华为云提供的一款无服务器 (Serverless) 计算服务，无服务器计算是一种托管服务，服务提供商会实时为你分配充足的资源，而不需要预留专用的服务器或容量，真正按实际使用付费。

华为云函数工作流在实时数据流处理中的流程架构

腾讯云

腾讯云云函数（Serverless Cloud Function，SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮助用户在无需购买和管理服务器的情况下运行代码，是实时文件处理和数据处理等场景下理想的计算平台。 用户只需使用 SCF 平台支持的语言编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、安全地运行代码。

腾讯云云函数在移动及 Web 应用后端中的流程架构

AWS

AWS Lambda 是一项计算服务，帮助用户无需预配置或管理服务器即可运行代码。Lambda 在可用性高的计算基础设施上运行代码，执行计算资源的所有管理工作，其中包括服务器和操作系统维护、容量调配和弹性伸缩和记录。借助 Lambda，用户可以为几乎任何类型的应用程序或后端服务运行代码，用户只需要以 Lambda 支持的一种语言提供自己的代码。

用户可以将代码组织到 Lambda 函数。只有在需要时 Lambda 才运行用户的函数，并且能自动扩展，从每天几个请求扩展到每秒数千个请求。用户只需为消耗的计算时间付费，代码未运行时不产生费用。

AWS Lambda 在文件处理中的流程架构

开源无服务器框架

Knative

Kubernetes 已经成为容器编排的事实标准。但是 Kubernetes 的定位是一个容器平台而不是代码平台。作为运行和管理容器的平台，Kubernetes 功能强大，但是这些容器是如何构建、运行、扩展和路由，很大程度上是由用户自己决定。Knative 基于 Kubernetes 平台，是用来构建、部署和管理现代无服务器架构的工作负载的框架，它将云原生应用开发的三个领域的最佳实践结合起来，即构建容器（和函数）、为工作负载提供服务（和动态扩展）以及事件。Knative 是由谷歌与 Pivotal、IBM、Cisco、Red Hat 等云原生技术厂商紧密协作开发的。

Knative 扩展了 Kubernetes，提供了一组中间件组件，它们对于构建现代、源码中心化以及基于容器的应用至关重要，这些应用可以运行在企业内部、云端或第三方数据中心中。

Knative 构建在 Kubernetes 的基础上，为构建和部署 Serverless 架构和基于事件驱动的应用程序提供了一致的标准模式。Knative 减少了这种全新的软件开发方法所产生的开销，同时还把路由和事件的复杂性抽象出来。

Apache OpenWhisk

Apache OpenWhisk 是一个开源的分布式无服务器平台，可以执行函数以响应任何规模的事件。OpenWhisk 使用 Docker 容器管理基础架构、服务器和扩展，因此用户可以专注于构建出色且高效的应用程序。

OpenWhisk 平台支持一种编程模型，在该模型中，开发人员可以使用任何支持的编程语言编写功能逻辑（称为 Actions），这些逻辑可以动态调度和运行以响应来自外部源（Feeds）或 HTTP 请求的关联事件（通过触发器）。该项目包括一个基于 REST API 的命令行界面 (CLI) 以及其他工具来支持打包、目录服务和许多流行的容器部署选项。

Riff Project

Riff 是与 Knative 紧密相关的一个项目，主要贡献者为 Pivotal 和 Google 公司。Riff CLI 帮助开发人员使用 Knative 构建和运行函数。Riff 包括在 Kubernetes 集群中安装 Knative 以及管理函数、服务、通道和订阅的命令。Riff 允许开发人员编写响应事件的函数。函数被部署为 Kubernetes pods，其中包含自定义函数的特定语言调用程序，以及用于在函数范围内外获取数据的 I/O bound Sidecar。SideCar 负责读/写消息主题，并使用参数分派调用程序。

Riff 使用自定义资源定义来枚举 Kubernetes 中的函数和主题。此外，它还部署了一对控制器盒来管理这些资源——主题和功能控制器。主题控制器使用基础事件代理处理主题状态更改。功能控制器监听主题事件并管理功能部署、销毁和扩展需求，包括：Riff CLI 安装 Knative 和使用 Knative serving 基于 Kaniko-based 集群的 builds、developer workflow 等等。

生态工具链

应用框架

蚂蚁金服 SOFAStack

SOFAStack 是蚂蚁金服自主研发的分布式中间件，为用户提供安全、稳定、可靠、高效、敏捷的基础架构能力，用于打造大规模高可用的分布式系统架构。SOFAStack 以轻量级服务框架为基础，兼容 Spring Boot、Spring Cloud、Dubbo 工程，提供应用中心、微服 务、消息队列、数据访问代理、分布式链路跟踪、分布式事务、Serverless 等服务。

蚂蚁金服的 Serverless 服务配备文件储存、数据储存、服务托管和函数计算等诸多能力。文件储存方面，Serverless 平台为开发者提供了基于 CDN 的文件 BaaS 服务，开发者只需将文件通过接口上传，即可直接享受到 CDN 的能力，为文件带来最佳的访问性能以及海量的访问量。数据储存方面，用户可以通过客户端的 SDK 操作数据库里的数据，无需服务端参与，即可完成数据的存取操作。通过服务托管，开发者无需再关心底层环境、后端运维的各种细节。开发者只需将业务代码提交到云端即可。通过函数计算，开发者可以将原有的复杂计算逻辑拆分为多个计算函数，然后通过事件或者 HTTP 方式串接起计算业务，在实现对业务解耦的同时，减少对后端资源成本的依赖。

腾讯云 Serverless 框架

TCSAM 是用于在腾讯云上定义 Serverless 应用的模型。基于 TCSAM，腾讯云提供了 TCF 命令行工具，用于云函数的管理和部署。

TCF 全称为 Tencent Cloud Function，是腾讯云 Serverless 云函数 SCF (Serverless Cloud Function) 产品的命令行工具。通过 TCF 命令行工具，用户可以方便地实现函数打包、部署、本地调试，也可以方便地生成云函数的项目并基于 demo 项目进行进一步开发。

TCF 通过 TCSAM 规范的模板配置文件，完成函数及相关周边资源的描述，并基于配置文件实现本地代码及配置部署到云端的过程。同时，TCF 命令行工具提供本地事件模拟、本地调试等用于调试的相关功能，方便用户进行本地调试及测试。TCF 还提供了通过使用命令行工具将函数的管理、测试、部署、发布对接到持续集成及持续发布流程中的能力。

可视化

无服务架构的应用通常会部署成百上千个函数，访问调用的复杂性急剧上升。通过监控/可视化工具，可帮助用户或运维人员监测链路状态，掌握函数运行状态，快速定位问题源头。

Grafana

Grafana 是一个跨平台的开源的度量分析和可视化工具，可以通过将采集的数据查询然后可视化展示，并对监测指标做告警通知，常用于对基础设施和应用程序分析的时间序列数据进行可视化。Grafana 搭载后端的 Prometheus 数据源，可以为多种开源 Serverless 框架构建函数计算监测平台。

测试

由于公有云的函数服务没有开发环境，开发人员必须运行函数查看它们真实的运行情况，因此创建模拟测试环境并用于代码调试的工具变得非常必要。

华为云函数服务 Serverless Sandbox (HSS)

用户开发的函数在部署到华为云之前，可以使用华为云 Serverless Sandbox (HSS) 在本地开发和测试 Serverless 应用。该工具可以用来在本地测试函数功能，验证华为 Serverless 应用模型 (HSAM)，并为各种事件源本地生成样本有效载荷；提供了丰富的 cloud event 命令，可以将来自华为云服务的事件直接路由到本地环境来调试本地函数功能。

百度云 CFC BSAM 工具

BSAM CLI 是一个基于 BCE SAM 规范的命令行工具，它提供了本地开发环境，帮助用户在把函数上传到百度云 CFC 之前，在本地进行函数的开发、分析和执行。

CI/CD

函数应用跨区域移植部署的配置非常繁琐，极易出问题。能够将应用的配置描述分离，复用给多个应用可以大大简化移植部署的难度。

阿里云 Fun 2.0

阿里云 Fun 2.0 是一款 Serverless 应用开发的工具，可以帮助用户定义函数计算、API 网关、日志服务等资源。Fun 2.0 引入了全新设计的 Serverless Application Model (SAM) 规范。

SAM 作为一种基础设施即代码 (Infrastructure as Code)，允许用户描述函数计算及其相关云资源。用户可以使用同一份模板文件，跨 region 或者账户部署云应用。描述云资源的模板文件，也会成为项目代码的一部分，在不同开发者之间共享。这极大地降低了 Serverless 应用的交付难度、管理难度、移植难度。除了 1.0 版本支持的函数、API 网关的配置，2.0 还有以下功能更新：

• 增强了对函数的描述能力：环境变量、日志服务、角色属性、VPC 属性等。

• 支持配置新的应用资源，比如 Table Store、日志服务等。

• 代码上传可以指定文件、目录、压缩包以及 OSS 路径。

• 更多的 API 网关参数配置。

Serverless 的适用场景

当前阶段，结合 Serverless 架构的基于事件驱动、应用代码动态部署、完全动态地进行大规模资源扩缩等特点，可以把 Serverless 架构的适用场景分为下面几类：

基于时间的内容处理应用

实时文件处理

有些应用会根据不同的应用需求将图片裁剪成不同尺寸，或添加不同的标签水印。视频类的应用会将视频流转码成不同的清晰度推送给不同服务。当图片或者视频流通过对象存储上传时便会触发相应的函数计算，根据计算规则自动按需处理，整个过程无需再搭建额外服务器，也无需人工干预。

定制事件触发

以用户注册时发邮件验证邮箱地址的场景举例，可以通过定制的事件来触发后续的注册流程，而无需再配置额外的应用 Serverless 来处理后续的请求。

大规模数据处理和计算类

人工智能推理预测

人工智能推理预测的调用需求会随着业务的起伏而变化，具有一定的波动性，这和人工智能训练时的较固定计算周期和运行时长有所不同。同时 AI 推理一般会使用 GPU 加速，这种明显的峰值变化会导致大量的资源浪费。使用 Serverless 架构技术可以有效解决上述问题。高业务请求到来时，云函数的执行实例自动扩容，满足业务需求；而在请求低谷或无请求到来时，云函数自动缩容甚至完全停止，节省资源使用。

批处理或计划任务

每天只需短期运行就能以异步计算的方式进行强大的并行计算能力，I/O 或网络访问的任务非常适合 Serverless 架构。这些任务可以以弹性方式运行时消费所需的资源，并且，在不被使用的当天剩余时间内，不消耗资源成本。典型场景有定期的数据备份等。

轻后端服务

通过将 Serverless 云函数和其他云服务紧密结合，开发者能够构建可弹性扩展的移动或 Web 应用程序，轻松创建丰富的 Serverless 后端，而且这些程序可在多个数据中心高可用运行，无需在可扩展性、备份冗余方面执行任何管理工作。

移动应用

使用 Serverless 架构技术构建移动后端服务是非常常用的场景。开发人员可基于云平台的后端服务来构建应用，这使得开发人员可以更加专注在移动应用的优化上，只要按需选择云服务商提供的丰富的后端服务即可。典型案例有微信小程序的开发等。

IoT

物联网的应用场景中，设备传输数据量小，且往往是以固定时间间隔进行数据传输，数据传输存在明显的波峰波谷特征。数据传输的波峰时段触发后端函数服务集中处理，处理结束后快速释放，提升资源的利用效率。

Serverless 典型落地案例

高德出行

高德是中国领先的数字地图内容、导航和位置服务解决方案提供商。自主出行是高德地图的核心业务，涉及到用户出行相关的功能诉求，承载了高德地图 APP 内最大的用户流量。自主出行核心业务中应用 Node FaaS 的部分场景包括主图场景页、路线规划页和导航结束页等。

此场景类型属于无状态服务，基于阿里云 Serverless 成熟的生态，高德最终选择接入 Node FaaS（阿里云函数计算）服务能力，出行前端搭建了场景推荐卡片服务。卡片的 UI 模版获取、数据请求聚合 &逻辑处理、拼接生成 Schema 的能力均在 FaaS 层得到实现，客户端根据服务下发的 Schema 直接渲染展示，达到更加轻便灵活的目标。在“十一出行节”峰值场景中，Serverless 整体服务成功率均大于 99.99% ，总计 100W+ 次触发/分钟，数十万 QPS，各场景的服务平均响应时间均在 60ms 以下，服务稳定性超出预期。

支付宝小程序

传统模式下，小程序开发遭遇挑战。在传统模式中，程序员开发一个小程序的时候，依旧需要采用像开发传统 APP 一样的方式进行业务开发。在整体业务开发中，需要前端开发、后台开发、运维人员、安全人员等多个角色的协同，导致人力成本和资源成本高昂，不利于小程序的开发。

蚂蚁金服采用 Serverless 模式这种更高效的研发方式来实现小程序的快速布局。基于蚂蚁的 Serverless 产品 Basement，可以用更高效、简单的方式快速实现稳定、可靠的小程序后台服务。Basement 的技术架构如下图所示：

蚂蚁金融云 Serverless 应用服务 (SAS) 和函数计算共同组成了小程序 Serverless 的后端解决方案。SAS 提供的关键后端能力包括：

1) 稳定的 Serverless 服务引擎：提供了服务所在集群的运行状态和日志等基本信息。

2) 丰富的应用服务能力：支持从镜像、代码包等方式多维部署应用。

3) 灵活的触发器配置：提供基于事件、定时任务和网络访问等方式的触发器配置以及弹性伸缩策略。

支付宝小程序 Serverless 模式带来的优势显而易见：

1) 研发效率提升：实现了复杂底层逻辑的托管，用户只需完成自己业务逻辑的开发即可，开发时间大大缩短，研发效率大大提升。

2) 高可用的服务能力：支持了同城多机房的容灾能力，所有服务的数据都会进行多机房的互备，同时在应用层提供动态切换能力，可以保障服务高可靠性和业务高稳定性。

3) 专业的安全管控：为用户的服务提供了全方位的安全管控，包括流量防护、防火墙防护等接入层控制；涉黄、涉政、暴力等内容安全控制，保障数据不发生非法访问以及泄漏的访问控制。

4) 低成本：Serverless 模式下，人力投入成本低，资源成本低，收益高。

总体而言，Serverless 模式帮助支付宝提供可靠、稳定、安全的小程序服务，为开发者提供简单、高效的小程序开发方式。

美团 Serverless 前端体系

美团早期业务快速发展，各业务在 Node 应用上各取所长，但在可用性和运维上需要付出额外的维护成本。随着美团建设了 Serverless 平台，前端也紧随其后，将 Node 应用由传统架构向 Serverless 架构演进，通过 Serverless 方式升级 Node 基础设施。

Serverless 前端主要包括研发套件、PaaS 平台、技术组件，以及业务层的解决方案。美团通过研发套件的建设和技术组件的建设来提升业务的开发效率，通过 PaaS 平台的建设来为业务提供服务的架构和稳定保障能力，同时 PaaS 的弹性特点可以很好地解决原来系统与部署的问题。Serverless 前端全景如下图所示：

对于云函数平台，美团大体上将其分为运行态和管理态。运行态要负责事件流转的过程。首先由触发源来产生事件，经过事件网关分发到具体业务实例当中的函数里去处理，业务函数会对事件做出处理和响应。事件网关除了分发流量之外，还会做一些限流降级、流量统计等相关的工作。实例这一层提供了函数沙箱，里面运行的是业务函数，对业务函数起隔离的作用。管理系统里提供函数的管理、发布以及监控等运维能力。

Serverless 的问题及发展趋势

供应商锁定

从一个供应商使用的任何无服务器功能将由另一个供应商以不同的方式实现。如果想更换供应商，几乎肯定用户需要更新操作工具（部署、监控等），可能需要更改代码（例如，以满足不同的 FaaS 接口），甚至如果竞争供应商实现的行为方式存在差异，则需要更改设计或架构。

即使设法轻松迁移了生态系统的一部分，也可能会受到另一个架构组件的更大影响。例如，假设正在使用 AWS Lambda 响应 AWS Kinesis 消息总线上的事件，虽然 AWS Lambda、 Google Cloud Functions 和 Microsoft Azure Functions 之间的差异可能相对较小，但仍然无法将后两个供应商实现直接连接到用户的 AWS Kinesis 流。这意味着如果不移动基础设施的其他部分，就不可能将代码从一个解决方案移动或移植到另一个解决方案。

为解决该问题，跨厂商的标准和模型互通成为未来趋势之一，即要向上标准化，屏蔽各个 Serverless 供应商的底层实现差异。

比如，AWS SAM (Serverless Application Model) 就是一个用于构建无服务器应用程序的开源框架。它提供简写语法来表达函数、API、数据库和事件源映射。每个资源只需几行就可以定义所需的应用程序并使用 YAML 对其建模。在部署期间，SAM 将 SAM 语法转换并扩展为 AWS CloudFormation 语法，使用者能够更快地构建无服务器应用程序。

冷启动延时

在 Serverless 架构中，当一个函数没有被调用一段时间后，其资源被系统释放；等再次调用时，系统需要重新初始化资源，从而导致首次请求响应时间变长。同理，对于新到达的并发请求，会产生并发的冷启动问题。这是 Serverless 最被诟病的地方之一。

常规解决思路是热点函数预热，用类似 LRU 的方式保证大部分热点函数始终不会被驱离，资源不会被销毁，这其中体现的是性能和成本的折中和妥协。

一些前沿企业比如 Amazon，引入 KVM 虚拟化技术，以 microVM 的思路，将容器启动速度及占用资源大大降低，并且针对主力语言比如 Java 的函数冷启动加载时间进行优化（最高可达 90%的优化效果），从根本上解决冷启动问题，但是需要关注其可扩展性及平台绑定问题。

函数生命周期有限，已加载状态无法复用

当前主流的 Serverless 平台对于函数的生命周期都有时间限制，函数不能长时间运行，只能在有限的时间执行，如 900s (15min)。当函数没有新的请求时，函数所在的执行环境被销毁，函数执行的中间状态、缓存等会被删除。当新的函数调用发起时，不能直接利用上次计算的缓存状态。

针对以上问题，有状态函数编程模型提供了方便的函数定义方式，以及语言无关的状态定义方式。由于不需要频繁地和外部存储进行交互，该模型减少了网络访问的次数，从而能够获得更低的时延。数据不需要分发到外部存储中，也不需要缓存到其它节点上，在可用性和一致性方面得到提升。由于用户请求与节点存在粘性连接，用户只需和一个函数实例发生交互，存取状态数据更为容易，通常只需要对函数中的一个简单结构体进行操作即可。

另外，由于 FunctionGraph 服务接管了状态的管理，可以为用户提供多种数据一致性模型，以及处理并发场景下死锁的问题，从而使得编程模型更加容易理解、用户程序更加简洁。

展望

随着技术发展，云计算技术已经成为现代计算领域的新兴技术，而 Serverless 架构正是云计算技术的最新应用。根据 Gartner 的预测，全球 Serverless 架构市场的规模将在 2024 年达到 1000 亿美元。在技术发展方面，Serverless 架构也将发展出新的功能和特性，从而更好地服务于开发者和企业。

作者介绍

舒超，前美团基础研发负责人，存储中心总架构师，负责美团公司级云原生服务治理系统的开发及演进；前腾讯微博微群及消息流广告负责人。目前任职星汉未来 CTO。星汉未来是一家拥有先进云原生和 Serverless 能力的基础软件服务商，坚定相信 Serverless 是云计算的下一个型态，并将现有产品矩阵全面转向 Serverless。

延伸阅读：

15 年了，我们到底怎样才能用好 Serverless

从公有云方案转向谷歌开源 Knative，网易云音乐的 Severless 演进实践

落地 4 年，工商银行如何进行 Serverless 架构迭代