特别专题|Topic

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

作者 舒超 策划 褚杏娟

Serverless是什么

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

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

Serverless发展历程

什么背景下诞生了Serverless

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

发展大事记

· 2006年，伦敦的一家公司发布了名为Zimki的平台，该平台提供了端到端的JavaS cript开发能力，并且最早提出了“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年推出了Az ure 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平台支持的语言编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、安全地运行代码。

AWS

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

用户可以将代码组织到Lambda函数。只有在需要时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。