目录
一、 Serverless基础
1.1 Serverless产生的背景
1.2 什么是Serverless
1.3 Serverless架构优势
1.3.1 按需使用的资源管理
1.3.2 简化业务运维复杂度
1.4 Serverless和Service Mesh相同点
1.5 Serverless基础架构
1.5.1 函数管理
1.5.2 事件触发器
1.5.3 函数的路由和伸缩管理
二、Serverless的发展历程和当前现状
2.1 发展历程
2.1.1 Serverless启蒙阶段
2.1.2 Serverless概念产生
2.1.3 开启Serverless 架构时代
2.1.4 国外Serverless架构发展
2.1.5 国内Serverless架构发展
2.2 行业发展现状
2.2.1 国外平台
2.2.1.1 AWS
2.2.1.2 Knative
2.2.1.3 Apache OpenWhisk
2.2.2 国内平台
2.2.2.1 阿里云函数计算
2.2.2.2 华为云函数工作流
2.2.2.3 腾讯云云函数
三、Serverless 的使用场景
3.1 基于时间的内容处理应用
3.1.1 实时的文件处理
3.1.2 定制事件触发
3.2 大规模数据处理和计算类
3.2.1 人工智能推理预测
3.2.2 批处理或计划任务
3.3 轻后端服务
3.3.1 移动应用
3.3.2 IoT
四、Serverless 典型落地案例
4.1 高德出行
4.2 支付宝小程序
4.3 美团 Serverless 前端体系
五、Serverless 的问题及发展趋势
5.1 供应商锁定
5.2 冷启动延时
5.3 函数生命周期有限，已加载状态无法复用
六、Serverless技术展望
一、 Serverless基础
1.1 Serverless产生的背景
Serverless 所指向的基础设施架构，历史上经历了多次的迭代：从早期的 MVC（模型 - 试图 - 控制器）为主的单体形式，到后来的 SOA，再到最近十年兴起的微服务架构和云原生。整个基础支撑功能是逐步在拆分解耦，以垂直提升研发和运维效率。横向分层上，虚拟化技术打通了物理资源的隔阂，减轻了用户管理基础架构的负担。容器 /PaaS 平台则进一步抽象，提供了应用的依赖服务、运行环境和底层所需的计算资源。这使得应用的开发、部署和运维的整体效率再度提升。在这样的背景下，Serverless 其实代表了一种更彻底的屏蔽与分层，将应用架构堆栈中的各类资源的管理全部委托给平台，免去基础设施的运维，使用户能够聚焦高价值的业务领域，进一步提高软件应用和运营的生产力。
云计算技术的发展，使得用户只需要关注当前需要的底层资源，通过云基础设施可以自动完成资源的供给和伸缩；通过Kubernetes、Mesos等资源调度和编排平台对业务屏蔽了集群和机器资源管理的复杂度，不仅提高了资源的利用率，也通过为用户提供完善的环境管理和资源管理平台，提高了业务效率。但在这种使用场景下，用户仍然需要预估需要的资源，并在云平台上预先进行分配，而不管这些资源是否会被充分利用。因此对用户的容量预估和资源预估提出了很高的要求，如果预估和实际有很大偏差，就会导致很大的资源浪费，或者出现资源不足而影响业务使用，为了解决这个问题，Serverless应运而生。
1.2 什么是Serverless
根据 CNCF 的定义，Serverless 的概念是指构建和运行不需要服务器管理的应用程序。它描述了一种更细粒度的部署模型，在该模型中，应用程序被捆绑为一个或多个功能，被上传到一个平台，然后根据当前所需的确切需求执行、扩展和计费。
所以首先需要明确的一点是，Serverless 并非指托管和运行我们的应用程序不再需要服务器，而是指从前耗费研发和运维人员无数精力和资源的 CI/CD、服务器配置维护更新、IT 资源容量的规划和伸缩等工作，被 Serverless 这个概念下包含的技术体系所封装了。研发专注于业务逻辑的编写，运维向 SRE 转型，负责技术 SLA 的制定和保障工作。这也是技术体系又一维度的分层体现（其它类比汇编语言和高级语言，OS 和应用软件）。
在Serverless下，业务不再需要固定的服务器资源，而是按需分配相应的服务资源。当业务请求比较多时，会多分配相应的服务实例；当业务请求比较少甚至为零时，可以不分配任何服务器资源。
1.3 Serverless架构优势
Serverless架构和之前的架构相比，最大的差异是：业务服务不再是固定的常驻进程，而是真正按需启动和关闭的服务实例。因此Serverless架构可以提供如下两点优势。
1.3.1 按需使用的资源管理
Serverless架构下，容量规划成为历史，对一个业务进行准确的容量规划通常来说是特别有挑战性的事情，需要考虑的因素很多，通过Serverless的即需即用，不再需要容量规划，减少了业务架构和运维的复杂度。同时对于按需使用的资源管理，业务只需要为真正使用的部分付费，从而减少了不必要的资源浪费。
1.3.2 简化业务运维复杂度
在微服务架构下，微服务由各个功能模块，以及功能模块之间的通信组成，微服务开发者不仅需要关注业务功能，还要花费很多精力在完成不同微服务的交互和通信管理上。在Serverless架构下，你只需要实现具体的功能函数并提交给Serverless，各功能函数之间的交互由Serverless接管，开发者不再需要关注功能函数交互的细节。
1.4 Serverless和Service Mesh相同点
在简化微服务管理复杂度上，Serverless和Service Mesh的目标是一致的，都是将微服务通信和服务治理相关的非功能需求从业务中剥离，对于Serverless是交给Serverless框架负责处理，对于ServiceMesh是下沉到底层，成为通信基础设施的一部分。
1.5 Serverless基础架构
在Serverless中，按需执行的代码片断称为“函数”，它是Serverless资源管理和调度的基本单位，因此Serverless有时也被称为FaaS（Function As A Service，函数即服务）。Serverless架构大体由如下几个部分组成。
1.5.1 函数管理
Serverless需要对用户编写的函数进行管理，通过一定的方式将用户函数变成可调度、可运行的实例。为了支持多个语言的Serverless函数，函数管理需要针对每种语言定义函数规范和标准，提供相应的实现机制。
1.5.2 事件触发器
事件驱动是Serverless非常重要的组成部分，Serverless一般会定义一组关注的事件类型，并提供相应的事件触发和订阅框架，函数需要实现注册好关注的事件类型，事件触发时，Serverless框架查找关注这个事件的函数，触发函数的具体执行。
1.5.3 函数的路由和伸缩管理
在很多Serverless实现中，函数的访问和路由一般由API网关来负责，API网关根据相应的路由规则，找到相应的服务实例进行访问。
在伸缩管理方面，监控函数当前的请求和资源。如果资源过多，则进行相应的资源回收；若资源不够，则增加相应的资源实例。
在Serverless中，函数实例按需创建运行，按需伸缩调整，函数实例必须特别轻量，能够快速启动，快速关停，Serverless也需要提供完善的机制，支持函数实例的快速启动。当前Serverless在快速启动方面还没有很好的解决方案，快速启动的程度决定了Serverless的应用范围和应用场景，在很多场景下，如果没有快速启动的支撑，Serverless很难应用起来。
二、Serverless的发展历程和当前现状
2.1 发展历程
2.1.1 Serverless启蒙阶段
2006 年，伦敦的一家公司发布了名为 Zimki 的平台，该平台提供了端到端的 Java 开发能力，并且最早提出了“Pay as you go”的概念，但在商业上并未取得显著成功。
2008 年，谷歌发布 App Engine 服务，用户的开发方式得到了根本的变革，无须考虑预分配多少资源，也无须考虑操作系统的实现。
2.1.2 Serverless概念产生
2012 年，Ken Fromm 在《软件和应用的未来是 Serverless》中率先提出了 Serverless 的概念。
2.1.3 开启Serverless 架构时代
2014 年，AWS 重磅发布函数计算产品 Lambda，开启了 Serverless 架构的新时代。按照当时的描述，Lambda是一种计算服务，它按需运行用户的代码，用户无须关注底层的计算资源。借助AWS Lambda几乎可以在任何类型的应用程序或后端服务中运行代码，并且不必进行任何管理。AWS Lambda在可用性高的计算基础设施上运行代码，执行计算资源的所有管理工作，其中包括服务器和操作系统维护、容量预置和自动扩展、代码监控和记录，用户只需要提供AWS Lambda支持的语言代码即可。
2.1.4 国外Serverless架构发展
2016 年，Azure Function、GCP（Google Cloud Platform）以及 IBM Open Whisk 相继发布 Serverless 计算平台。
2017年，谷歌 GCP 发布了 Firebase 产品，提供多端一体化开发的 Serverless 解决方案。
2018 年，谷歌开源 Knative，尝试将 Serverless 架构标准化。同年，全球知名 IT 咨询调研机构 Gartner 发布报告，将 Serverless 架构列为十大未来将影响基础设施和运维的技术趋势之一。
2019年，Microsoft Azure 也推出了 Azure Functions。
2020 年，Google Cloud 推出 Cloud Run 服务，AWS Lambda 支持 Ruby 等更多语言。
2021 年，AWS Lambda 引入新的 Lambda Edge 服务，它可以将内容置于全球 CDN 网络上，从而提供快速和可靠的服务
2.1.5 国内Serverless架构发展
2017 年，腾讯云和阿里云先后发布了 Serverless 计算产品——云函数和函数计算；
2019 年，腾讯云和 Serverless.com 达成战略合作，共同开发 Serverless Framework 产品，提供 Serverless 开发的一站式解决方案。
2022 年，阿里云宣布核心产品全面 Serverless 化。
2.2 行业发展现状
目前 Serverless 的技术生态主要活跃在公有云的云函数服务领域，国内外主要云服务商都具备云函数产品。这主要是因为公有云的云函数服务拥有一系列完善的云计算资源，这使得 Serverless 能够更快地开发和部署应用程序。而且，公有云还提供了完整的安全体系，可以确保 Serverless 技术的安全性。此外，公有云的云函数服务也能够提供便捷的数据存储和管理，从而使 Serverless 应用更便捷、更高效。公有云服务基本可满足用户 Serverless 应用的搭建需求。私有云的解决方案领域仍旧以国外开源技术为主。
工具层来看，独立 BaaS 服务（开源、商业产品）主要由国外服务商提供，国内服务商提供的相关工具主要供给各自产品使用，普适多云平台的工具产品多集中在开发框架层面。
平台层提供全托管的运行环境，提供函数单元所需的计算环境并自行维护服务器资源、网络资源、消息分发和负载均衡等功能，是整个 Serverless 架构的基础。国内主要公有云服务商均已推出云函数产品，开源的 Serverless 架构框架也层出不穷，下文将选取较为典型的几个平台进行介绍。
2.2.1 国外平台
2.2.1.1 AWS
AWS Lambda 是一项计算服务，帮助用户无需预配置或管理服务器即可运行代码。Lambda 在可用性高的计算基础设施上运行代码，执行计算资源的所有管理工作，其中包括服务器和操作系统维护、容量调配和弹性伸缩和记录。借助 Lambda，用户可以为几乎任何类型的应用程序或后端服务运行代码，用户只需要以 Lambda 支持的一种语言提供自己的代码。
用户可以将代码组织到 Lambda 函数。只有在需要时 Lambda 才运行用户的函数，并且能自动扩展，从每天几个请求扩展到每秒数千个请求。用户只需为消耗的计算时间付费，代码未运行时不产生费用。
官网：[AWS Lambda云计算服务介绍_如何使用AWS Lambda-AWS云服务 (amazon.com)]
2.2.1.2 Knative
Kubernetes 已经成为容器编排的事实标准。但是 Kubernetes 的定位是一个容器平台而不是代码平台。作为运行和管理容器的平台，Kubernetes 功能强大，但是这些容器是如何构建、运行、扩展和路由，很大程度上是由用户自己决定。
Knative 基于 Kubernetes 平台，是用来构建、部署和管理现代无服务器架构的工作负载的框架，它将云原生应用开发的三个领域的最佳实践结合起来，即构建容器（和函数）、为工作负载提供服务（和动态扩展）以及事件。Knative 是由谷歌与 Pivotal、IBM、Cisco、Red Hat 等云原生技术厂商紧密协作开发的。
Knative 扩展了 Kubernetes，提供了一组中间件组件，它们对于构建现代、源码中心化以及基于容器的应用至关重要，这些应用可以运行在企业内部、云端或第三方数据中心中。
Knative 构建在 Kubernetes 的基础上，为构建和部署 Serverless 架构和基于事件驱动的应用程序提供了一致的标准模式。Knative 减少了这种全新的软件开发方法所产生的开销，同时还把路由和事件的复杂性抽象出来。
下面重点讨论Knative的Serving系统。Serving系统基于Kubernetes和Istio进行开发，利用Kubernetes强大的容器调度和生命周期管理能力以及Istio的通信和通信链路治理能力。另外，为了屏蔽Kubernetes和Istio的复杂度，Knative Serving自身有更高一层的抽象能力，提供一组用来对应用和通信进行管理的抽象概念（可使用Kubernetes CRD对这些抽象概念进行管理）。Knative Serving的主要概念如下。
1）Route：工作负载的路由规则，对应Istio的VirtualService。
2）Configuration：应用的最新配置，对应Kubernetes的Deployment。
3）Revison：每次对工作负载进行修改的快照，对应Istio的Subset。
4）Service：对工作负载的整个生命周期进行管理。
Knative的Serving系统做的事情和Kubernetes、Istio大体相同，但通过提供更高的抽象，屏蔽了Kubernetes、Istio的细节，自动帮应用管理好Deployment、VirtualService以及auto scaling之间的关系。
auto scaling是Knative Serving实现工作负载自动伸缩的关键组件，当前还处于发展早期，有不少性能问题，很不成熟，Knative后续计划将auto scaling下沉，直接复用Kubernetes原生的auto scaling能力。
基于Kubernetes的Serverless产品和解决方案市场上已经有不少，比如Fission、Funktion、Kubeless等，但同时依赖Kubernetes和Istio这两个重量级的项目，Knative还是第一个。Kubernetes和Istio的复杂度都很高，同时基于Kubernetes和Istio，再加上Serverless自身的复杂度，会导致整个Serverless解决方案的复杂度非常高，学习曲线上也非常陡峭，因此很多人都有如下疑问和质疑：Knative中为什么采用Kubernetes和Istio这么重的通信解决方案？
- 从架构和通信功能实现来看
确实没有必要，为了对上层用户屏蔽底层Kubernetes和Istio的实现细节，Knative又引入了一层抽象概念，对Kubernetes的容器和通信功能进行封装。如果通信直接放在Knative层面上做，只聚焦Kubernetes平台对Serverless的通信支持，不需要平台扩展性和场景扩展性支持，架构设计上会特别简单，同时灵活性也会比现在好。
- 从短期和静态的角度看
Knative引入Istio，确实没有那么大的必要，因为增加了复杂度，减少了灵活性。但从云计算基础设施的大趋势来看，Kubernetes已经成为容器调度和生命周期管理的事实标准，可以看成云原生时代的Linux操作系统；Istio虽然产生时间不长，但已经显现出强大的发展势头，当前在Service Mesh和Kubernetes生态中的地位已经不可撼动，可以看成云原生时代的TCP/IP协议。
因此，如果从云计算的发展趋势上看，通信功能会被Istio完全接管，并下沉为基础设施的一部分。在通信层面，Istio肯定更聚焦、更专业，Knative从大趋势出发，直接复用Istio的通信层功能，避免后续架构上的修改和返工，可以将自身聚焦到Serverless层面的功能和生态打造上。从架构的角度看，这也是Unix设计哲学的体现——整个系统采用模块化设计，每个模块只聚焦一件事情，并且做好做到极致。
2.2.1.3 Apache OpenWhisk
Apache OpenWhisk 是一个开源的分布式无服务器平台，可以执行函数以响应任何规模的事件。OpenWhisk 使用 Docker 容器管理基础架构、服务器和扩展，因此用户可以专注于构建出色且高效的应用程序。
OpenWhisk 平台支持一种编程模型，在该模型中，开发人员可以使用任何支持的编程语言编写功能逻辑（称为 Actions），这些逻辑可以动态调度和运行以响应来自外部源（Feeds）或 HTTP 请求的关联事件（通过触发器）。该项目包括一个基于 REST API 的命令行界面 (CLI) 以及其他工具来支持打包、目录服务和许多流行的容器部署选项。
官网地址：[Apache OpenWhisk is a serverless, open source cloud platform]
2.2.2 国内平台
2.2.2.1 阿里云函数计算
事件驱动的全托管计算服务。通过函数计算，无需管理服务器等基础设施，只需编写代码并上传。函数计算会准备好计算资源，以弹性、可靠的方式运行代码，并提供日志查询、性能监控、报警等功能。
官网：[函数计算FC_无服务器计算_Serverless_容器与中间件-阿里云 (aliyun.com)]
2.2.2.2 华为云函数工作流
华为云提供的一款无服务器 (Serverless) 计算服务，无服务器计算是一种托管服务，服务提供商会实时为你分配充足的资源，而不需要预留专用的服务器或容量，真正按实际使用付费。
官网：[函数工作流_FunctionGraph_事件驱动_函数托管_serverless-华为云 (huaweicloud.com)]
2.2.2.3 腾讯云云函数
腾讯云云函数（Serverless Cloud Function，SCF）是腾讯云为企业和开发者们提供的无服务器执行环境，帮助用户在无需购买和管理服务器的情况下运行代码，是实时文件处理和数据处理等场景下理想的计算平台。用户只需使用 SCF 平台支持的语言编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、安全地运行代码。
通过 TCF 命令行工具，用户可以方便地实现函数打包、部署、本地调试，也可以方便地生成云函数的项目并基于 demo 项目进行进一步开发。
TCF 通过 TCSAM 规范的模板配置文件，完成函数及相关周边资源的描述，并基于配置文件实现本地代码及配置部署到云端的过程。同时，TCF 命令行工具提供本地事件模拟、本地调试等用于调试的相关功能，方便用户进行本地调试及测试。TCF 还提供了通过使用命令行工具将函数的管理、测试、部署、发布对接到持续集成及持续发布流程中的能力。
官网地址：[云函数_无服务器 _无服务器函数计算 (tencent.com)]
三、Serverless 的使用场景
当前阶段，结合 Serverless 架构的基于事件驱动、应用代码动态部署、完全动态地进行大规模资源扩缩等特点，可以把 Serverless 架构的适用场景分为下面几类：
3.1 基于时间的内容处理应用
3.1.1 实时的文件处理
有些应用会根据不同的应用需求将图片裁剪成不同尺寸，或添加不同的标签水印。视频类的应用会将视频流转码成不同的清晰度推送给不同服务。当图片或者视频流通过对象存储上传时便会触发相应的函数计算，根据计算规则自动按需处理，整个过程无需再搭建额外服务器，也无需人工干预。
3.1.2 定制事件触发
以用户注册时发邮件验证邮箱地址的场景举例，可以通过定制的事件来触发后续的注册流程，而无需再配置额外的应用 Serverless 来处理后续的请求。
3.2 大规模数据处理和计算类
3.2.1 人工智能推理预测
人工智能推理预测的调用需求会随着业务的起伏而变化，具有一定的波动性，这和人工智能训练时的较固定计算周期和运行时长有所不同。同时 AI 推理一般会使用 GPU 加速，这种明显的峰值变化会导致大量的资源浪费。使用 Serverless 架构技术可以有效解决上述问题。高业务请求到来时，云函数的执行实例自动扩容，满足业务需求；而在请求低谷或无请求到来时，云函数自动缩容甚至完全停止，节省资源使用。
3.2.2 批处理或计划任务
每天只需短期运行就能以异步计算的方式进行强大的并行计算能力，I/O 或网络访问的任务非常适合 Serverless 架构。这些任务可以以弹性方式运行时消费所需的资源，并且，在不被使用的当天剩余时间内，不消耗资源成本。典型场景有定期的数据备份等。
3.3 轻后端服务
通过将 Serverless 云函数和其他云服务紧密结合，开发者能够构建可弹性扩展的移动或 Web 应用程序，轻松创建丰富的 Serverless 后端，而且这些程序可在多个数据中心高可用运行，无需在可扩展性、备份冗余方面执行任何管理工作。
3.3.1 移动应用
使用 Serverless 架构技术构建移动后端服务是非常常用的场景。开发人员可基于云平台的后端服务来构建应用，这使得开发人员可以更加专注在移动应用的优化上，只要按需选择云服务商提供的丰富的后端服务即可。典型案例有微信小程序的开发等。
3.3.2 IoT
物联网的应用场景中，设备传输数据量小，且往往是以固定时间间隔进行数据传输，数据传输存在明显的波峰波谷特征。数据传输的波峰时段触发后端函数服务集中处理，处理结束后快速释放，提升资源的利用效率。
四、Serverless 典型落地案例
4.1 高德出行
高德是中国领先的数字地图内容、导航和位置服务解决方案提供商。自主出行是高德地图的核心业务，涉及到用户出行相关的功能诉求，承载了高德地图 APP 内最大的用户流量。自主出行核心业务中应用 Node FaaS 的部分场景包括主图场景页、路线规划页和导航结束页等。
此场景类型属于无状态服务，基于阿里云 Serverless 成熟的生态，高德最终选择接入 Node FaaS（阿里云函数计算）服务能力，出行前端搭建了场景推荐卡片服务。卡片的 UI 模版获取、数据请求聚合 & 逻辑处理、拼接生成 Schema 的能力均在 FaaS 层得到实现，客户端根据服务下发的 Schema 直接渲染展示，达到更加轻便灵活的目标。在“十一出行节”峰值场景中，Serverless 整体服务成功率均大于 99.99% ，总计 100W+ 次触发 / 分钟，数十万 QPS，各场景的服务平均响应时间均在 60ms 以下，服务稳定性超出预期。
4.2 支付宝小程序
传统模式下，小程序开发遭遇挑战。在传统模式中，程序员开发一个小程序的时候，依旧需要采用像开发传统 APP 一样的方式进行业务开发。在整体业务开发中，需要前端开发、后台开发、运维人员、安全人员等多个角色的协同，导致人力成本和资源成本高昂，不利于小程序的开发。蚂蚁金服采用 Serverless 模式这种更高效的研发方式来实现小程序的快速布局。基于蚂蚁的 Serverless 产品 Basement，可以用更高效、简单的方式快速实现稳定、可靠的小程序后台服务。Basement 的技术架构如下图所示：
蚂蚁金融云 Serverless 应用服务 (SAS) 和函数计算共同组成了小程序 Serverless 的后端解决方案。SAS 提供的关键后端能力包括：
1) 稳定的 Serverless 服务引擎：提供了服务所在集群的运行状态和日志等基本信息。
2) 丰富的应用服务能力：支持从镜像、代码包等方式多维部署应用。
3) 灵活的触发器配置：提供基于事件、定时任务和网络访问等方式的触发器配置以及弹性伸缩策略。
支付宝小程序 Serverless 模式带来的优势显而易见：
1) 研发效率提升：实现了复杂底层逻辑的托管，用户只需完成自己业务逻辑的开发即可，开发时间大大缩短，研发效率大大提升。
2) 高可用的服务能力：支持了同城多机房的容灾能力，所有服务的数据都会进行多机房的互备，同时在应用层提供动态切换能力，可以保障服务高可靠性和业务高稳定性。
3) 专业的安全管控：为用户的服务提供了全方位的安全管控，包括流量防护、防火墙防护等接入层控制；涉黄、涉政、暴力等内容安全控制，保障数据不发生非法访问以及泄漏的访问控制。
4) 低成本：Serverless 模式下，人力投入成本低，资源成本低，收益高。总体而言，Serverless 模式帮助支付宝提供可靠、稳定、安全的小程序服务，为开发者提供简单、高效的小程序开发方式。
4.3 美团 Serverless 前端体系
美团早期业务快速发展，各业务在 Node 应用上各取所长，但在可用性和运维上需要付出额外的维护成本。随着美团建设了 Serverless 平台，前端也紧随其后，将 Node 应用由传统架构向 Serverless 架构演进，通过 Serverless 方式升级 Node 基础设施。
Serverless 前端主要包括研发套件、PaaS 平台、技术组件，以及业务层的解决方案。美团通过研发套件的建设和技术组件的建设来提升业务的开发效率，通过 PaaS 平台的建设来为业务提供服务的架构和稳定保障能力，同时 PaaS 的弹性特点可以很好地解决原来系统与部署的问题。Serverless 前端全景如下图所示：
对于云函数平台，美团大体上将其分为运行态和管理态。运行态要负责事件流转的过程。首先由触发源来产生事件，经过事件网关分发到具体业务实例当中的函数里去处理，业务函数会对事件做出处理和响应。事件网关除了分发流量之外，还会做一些限流降级、流量统计等相关的工作。实例这一层提供了函数沙箱，里面运行的是业务函数，对业务函数起隔离的作用。管理系统里提供函数的管理、发布以及监控等运维能力。
五、Serverless 的问题及发展趋势
5.1 供应商锁定
从一个供应商使用的任何无服务器功能将由另一个供应商以不同的方式实现。如果想更换供应商，几乎肯定用户需要更新操作工具（部署、监控等），可能需要更改代码（例如，以满足不同的 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 语法，使用者能够更快地构建无服务器应用程序。
5.2 冷启动延时
在 Serverless 架构中，当一个函数没有被调用一段时间后，其资源被系统释放；等再次调用时，系统需要重新初始化资源，从而导致首次请求响应时间变长。同理，对于新到达的并发请求，会产生并发的冷启动问题。这是 Serverless 最被诟病的地方之一。
常规解决思路是热点函数预热，用类似 LRU 的方式保证大部分热点函数始终不会被驱离，资源不会被销毁，这其中体现的是性能和成本的折中和妥协。
一些前沿企业比如 Amazon，引入 KVM 虚拟化技术，以 microVM 的思路，将容器启动速度及占用资源大大降低，并且针对主力语言比如 Java 的函数冷启动加载时间进行优化（最高可达 90% 的优化效果），从根本上解决冷启动问题，但是需要关注其可扩展性及平台绑定问题。
5.3 函数生命周期有限，已加载状态无法复用
当前主流的 Serverless 平台对于函数的生命周期都有时间限制，函数不能长时间运行，只能在有限的时间执行，如 900s (15min)。当函数没有新的请求时，函数所在的执行环境被销毁，函数执行的中间状态、缓存等会被删除。当新的函数调用发起时，不能直接利用上次计算的缓存状态。
针对以上问题，有状态函数编程模型提供了方便的函数定义方式，以及语言无关的状态定义方式。由于不需要频繁地和外部存储进行交互，该模型减少了网络访问的次数，从而能够获得更低的时延。数据不需要分发到外部存储中，也不需要缓存到其它节点上，在可用性和一致性方面得到提升。由于用户请求与节点存在粘性连接，用户只需和一个函数实例发生交互，存取状态数据更为容易，通常只需要对函数中的一个简单结构体进行操作即可。
另外，由于 FunctionGraph 服务接管了状态的管理，可以为用户提供多种数据一致性模型，以及处理并发场景下死锁的问题，从而使得编程模型更加容易理解、用户程序更加简洁。
六、Serverless技术展望
随着技术发展，云计算技术已经成为现代计算领域的新兴技术，而 Serverless 架构正是云计算技术的最新应用。根据 Gartner 的预测，全球 Serverless 架构市场的规模将在 2024 年达到 1000 亿美元。在技术发展方面，Serverless 架构也将发展出新的功能和特性，从而更好地服务于开发者和企业。
好了，本次内容就分享到这，欢迎大家关注《微服务架构》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！