这是你所了解的FaaS 么？——无服务计算的10个思考

如今，云计算特别是基础设施即服务(Infrastructure-as-a-Service，IaaS)已经成为广泛采用的系统架构，并且可以根据需要提供虚拟机。企业越来越多地采用云计算的一个主要因素是其现收现付模式，客户只需为从云计算提供商那里租用的资源支付费用，并且有能力在没有预先成本的情况下获得所需的尽可能多的资源。

不尽如人意的是，系统扩展负担留给了开发人员和系统设计人员，他们通常使用超量供应技术来处理突然增加的服务请求，因而，云客户分配和支付的资源(租赁虚拟机)与实际资源利用率(CPU、内存等)之间存在着较大的差距。

无服务计算(Serverless Computing)的引人注目是由于企业应用架构向向容器和微服务的转变。无服务计算即付即用，无需启动和停止服务器的额外工作，并且更接近于将云计算视为一种实用工具的初衷。

1. 什么是无服务计算？

无服务计算，顾名思义，开发人员不必担心服务器管理和扩展的底层细节，只需在处理请求或事件时支付费用。

无服务计算是一个向开发人员隐藏服务器使用情况的平台，它可以根据代码的运行时间自动按需缩放和计费代码。

这个“自以为是”的定义体现了无服务计算的两个关键特征。

1.1 现收现付

由于服务器及其使用不是无服务计算模型的一部分，因此只有在代码运行时才支付费用，而不是为空闲服务器支付费用。由于执行时间可能很短，所以应该以细粒度的时间单位(比如几百毫秒)来计算，开发人员不需要支付服务器创建或销毁的开销(比如 VM 启动时间)。

这种成本模型对于必须偶尔运行的工作负载非常有吸引力，开发人员避免了为空闲服务器支付费用。云供应商面临的最大挑战是需要调度和优化云资源。

1.2 弹性从零到无穷大

由于开发人员无法控制运行服务器，也不知道他们的代码运行在多少台服务器上，导致扩展的决定权留给了云服务的提供者。开发人员不需要编写自动伸缩策略，也不需要定义机器级别的使用(CPU、内存等等)如何转换为应用程序的使用。

相反，他们依赖于云供应商，在需求增加时自动启动更多的运行实例。开发者还可以假设云供应商将负责服务器的维护、安全更新、可用性和可靠性监控。

无服务计算通常倾向于小型的、自包含的计算单元，以使其更容易在云中管理和伸缩。可中断或重新启动的计算不能依赖于云平台来维护其状态，这本质上影响了无服务器计算编程模型。但是，在状态方面，没有等价的伸缩到零的概念，因为需要持久存储层。

然而，即使有状态服务的实现需要持久存储，云服务商也可以提供一个现收现付的定价模型。云服务商正在发布拓展无服务计算的服务，例如，Amazon Aurora 是一个“无服务计算”的数据库服务，它支持强大的自动缩放功能。但是，仍然需要最小的内存和 CPU 分配，因此不能缩放到零，而且成本也在持续增加。

1.3 FaaS

使用无服务计算的最自然的方式是提供一段代码(函数)供无服务计算平台执行。它导致了FaaS(Function-as-a-service)平台的兴起，这些平台专注于允许代表为函数的小段代码在有限的时间内(最多几分钟)运行，由事件或 HTTP 请求(或其他触发器)触发执行，并且不允许保持持久状态(因为函数可以在任何时候重启)。

通过限制执行时间和不允许函数保持持久状态的 FaaS 平台，可以轻松地维护和扩展。云提供商可以按需分配服务器来运行代码，并且可以在函数执行完停止服务器，因为它们运行的时间是有限的。如果函数必须维护状态，那么它们可以使用外部服务来保持其状态。

因此，FaaS 是无服务计算的一种具体实现:

FaaS是一个无服务计算平台，其计算单元是一个响应触发器(如事件或 HTTP 请求)而执行的函数。

Cloud Native Computing Foundation (CNCF)将无服务计算定义为“构建和运行不需要服务器管理的应用程序的概念”。它描述了一种更细粒度的部署模型，将应用程序捆绑成一个或多个功能，上传到平台，然后根据当时的确切需求执行、扩展和开展业务。虽然FaaS的定义接近 CNCF 定义，但是区分了无服务计算和作为计算单元提供的函数。

无服务计算可能会扩展到包括一些额外的方面，这些方面超越了目前相对限制性的无状态函数，可能会扩展到大型计算单元的长时间运行和有状态的执行。

1.4 无服务计算的其他定义

Paul Johnston将无服务计算定义如下: “如果没有人使用它，那么无服务计算解决方案不需要运行任何成本(不包括数据存储)。”这个定义强调了无服务器计算的最重要特征——即时支付。它假定无服务器计算是云计算的一个子集，因此包含了自动伸缩。CNCF的定义不仅强调现收现付或“从规模到零”的方面，还强调不需要管理服务器。

另一种定义无服务计算的方法是通过它所支持的功能。这种方法强调“无服务计算实际上是一种服务托管”，而 FaaS 可以被视为云胶水，它是连接由云服务组成的应用程序的粘合剂。

实际上，“无服务计算”这个名称并不意味着不使用服务器，而只是说开发人员可以把管理服务器和其他资源的大部分操作留给云服务提供商，包括供应、监视、维护、可伸缩性和容错性。

2. 无服务计算与X-aaS 的辨析

追溯“无服务”这个术语的最初含义，即不使用服务器，通常指的是对等(P2P)软件或者只针对客户端的解决方案。在云环境中，无服务计算是AWS在 2014年引入的。无服务计算似乎是随着最近的进步和 VM 和容器技术的采用而自然发展起来的，在这些技术中，每一步抽象层都会导致在资源消耗、成本、开发和部署速度方面更轻量级的计算单元。

此外，无服务计算建立在分布式系统、发布-订阅系统和事件驱动程式设计/服务模型的长期趋势和进步之上的。

2.1 Serverless vs. IaaS

从 IaaS 来看，无服务计算的范式转换既带来了机遇，也带来了风险。一方面，它为开发人员提供了一个简化的编程模型，用于创建云应用程序，从而抽象出大部分操作的关注点。他们不再需要担心可用性、可伸缩性、容错性、虚拟机资源的过度/不足供应、服务器管理和其他基础设施问题。这种模式还通过向执行时间收费而不是资源分配来降低部署云代码的成本。

另一方面，在无服务平台上部署这样的应用程序具有挑战性，需要将设计决策交给平台提供者，这些平台提供者关心服务质量(quality-of-service，QoS)监控、伸缩性和容错性等属性，存在应用程序的需求可能演变为与平台功能冲突的风险。

2.2 Serverless vs. PaaS

我们可以将无服务计算视为平台即服务(Platform-as-a-Service，PaaS)的演变。一般地， PaaS 被描述为：

向消费者提供的能力是将消费者创建的或获得的应用程序部署到云基础设施上，这些应用程序是消费者使用提供者支持的编程语言和工具创建的。使用者不管理或控制基础云基础设施，包括网络、服务器、操作系统或存储，但控制已部署的应用程序以及可能的应用程序托管环境配置。

在此定义中，用户需要管理应用程序的部署，并控制宿主环境配置。

与 PaaS 的定义相比，无服务器 FaaS 正在取消用户对托管的控制，以提供更简单、更有吸引力的计费模型: 云服务提供商控制托管环境的配置，只在调用时运行用户提供的代码，只运行实际使用的代码，同时隐藏扩展的复杂性(实际上在 PaaS 中实现自动扩展并不容易，而且很难扩展到零)。与上一代平台服务协定(可被视为第一代平台服务协定)相比，这是一个重大变化，对于不需要为闲置资源付费和避免管理自动调整规则的平台服务用户来说，这非常具有吸引力。

无服务器平台的主要区别在于，只有在代码运行时，才会进行透明的自动缩放和细粒度的资源收费。这不应与免费使用配额混淆，后者每月可用的资源配额有限，但即使没有使用该应用程序，也会被计算在内。例如，GAE Standard 以“ instance hours”f 定价，即使没有使用应用程序，也会保持实例运行。后来，GAE 添加了具有更细粒度计费单元的 Flexible 版本，但即使没有使用服务器，开发人员仍将收到账单。这可能会导致意想不到的结果，当账单在月底到来的时候，忘记了测试服务

2.3 serverless vs MBaaS

移动后端即服务(Mobile Backend as-a-Service，MBaaS)或更广义的后端即服务(Backend as-a-Service，BaaS)与无服务计算非常相似。其中一些服务甚至提供了“云功能”。然而，这样的代码通常仅限于移动互联网的应用场景。

2.4 serverless vs SaaS

软件即服务(Software-as-a-Service，SaaS)可能支持服务器端执行用户提供的功能，但它们是在应用程序的上下文中执行的，因此仅限于应用自身的领域。有些 SaaS 供应商允许集成托管在其他地方的任意代码，并通过 API 调用进行调用。

无服务计算的边界与 PaaS 和 SaaS 有所重叠。对无服务计算进行分类的一种方法是考虑开发人员对基础结构的不同控制级别。在 IaaS 模型中，开发人员对资源有更多的控制权，但是同时负责管理应用程序代码并操作基础设施。这使得开发者有很大的灵活性，并且能够定制应用程序和基础设施的各个方面，例如管理虚拟机、管理容量和利用率、分级工作负载、实现容错和高可用性。PaaS 抽象出虚拟机，负责管理底层操作系统和容量，但是开发人员负责平台部署和运行的代码的整个生命周期。SaaS 代表了另一个极端，开发人员无法控制基础设施，只能访问预先打包的组件。开发人员可以在那里托管代码，但这些代码可能与平台紧密耦合。BaaS 与 SaaS 类似，其功能针对特定的用例和组件。

3. 无服务计算的系统架构——FaaS

FaaS 框架的核心功能仅仅是事件处理系统的核心功能。该服务管理一组用户定义的函数(又称为操作)。一旦从事件数据源(又名触发器)通过 HTTP 接收到请求，系统将确定哪些操作应该处理事件，从而创建一个新容器实例，并将事件发送到函数实例，等待响应，收集日志，让用户可可以接收到响应，并在不再需要时停止函数的运行。

3.1 架构特点

FaaS 提供的抽象层是独一无二的: 一个短期运行的无状态函数。事实证明，这既可以构建应用程序，又可以让平台以与应用程序无关的方式进行自动伸缩。

虽然架构相对简单，但是在实现这些功能的同时考虑诸如成本、可伸缩性、延迟和容错性等指标是一个挑战。为了在多租户环境中隔离不同用户的函数执行，经常使用容器技术，比如 Docker。

事件到达后，FaaS平台需要验证事件，确保其具有适当的身份验证和授权以执行。它还检查该特定事件的资源限制。一旦事件通过了验证，事件的平台就会排队等待处理。工作线程获取请求，分配合适的容器，从存储器中复制函数/使用代码到容器中，并执行事件。该平台还管理空闲函数实例的停止和释放资源。

3.2 架构约束

为每个函数调用创建、实例化和销毁一个新容器可能是代价高昂的，并且会引入总体延迟，这就是冷启动问题。冷启动问题可以通过一些技术得到缓解，比如维护一个未实例化容器池，这些容器是以前已经实例化但没有分配给特定用户的容器，或者重用以前为同一用户调用的容器。为了减少云函数的启动时间，可以在节点工作者之间适当地缓存最重要的包，从而减少启动时间。

在典型的无服务云产品中，客户只允许配置分配给函数的主内存大小。系统将根据主存大小按比例分配其他计算资源(例如 CPU)。内存越大，CPU 分配越高。资源使用是以较小的增量(例如，100毫秒)进行度量和计费，用户只需为其函数运行时使用的时间和资源付费。

业界可以使用一些开源的无服务器计算框架(例如 Kubeless、 OpenLambda、 OpenWhisk、 OpenFaaS等等)。此外，主流的云供应商已经为消费者提供了公开的商业无服务计算框架。虽然这些平台的一般属性(例如，内存、并发调用、请求的最大执行持续时间)相对相同，但每个云服务商设置的限制是不同的。需要注意的是，这些属性的限制随着云服务商采用新的特性和优化而不断变化。

4.无服务计算的编程模型——FaaS

典型的 FaaS 编程模型由两个主要原语组成: Action 和 Trigger。

Action 是一个执行任意代码的无状态函数，可以在调用者/请求不期望响应的情况下异步调用操作，或者在调用者期望作为操作执行结果的响应的情况下同步调用操作。

Trigger 是来自不同来源的一类事件。可以通过 Rest API 直接调用操作，也可以基于触发器执行操作。事件还可以触发多个函数(并行调用) ，或者动作的结果也可以是另一个函数的触发器(连续调用)。一些无服务框架为开发人员提供了更高层次的编程抽象，比如函数打包、排序和组合，这可能使构建更复杂的无服务应用变得更容易。

4.1 编程模型的约束

目前，无服务器框架执行一个单独的 main 函数，该函数以字典(例如 JSON 对象)作为输入，并生成一个字典作为输出。它们的表现力有限，因为它们是按比例构建的。为了最大限度地扩展，无服务器函数不会在执行之间维护状态。相反，开发人员可以在函数中编写代码来检索和更新任何需要的状态。该函数还能够访问表示函数运行环境的上下文对象(例如安全上下文)。

4.2 编程语言的支持

目前云提供商的无服务产品支持多种编程语言，包括 Java、 Python、 Swift、 c # 和 Node.js等。有些平台还支持用任何语言编写的代码的扩展机制，只要这些代码打包在支持定义良好的 API 的 Docker 映像中。

由于无服务计算功能的局限性和无状态性，以及它对API组合的适应性，云服务商正在提供一个增值服务的生态系统，支持开发者可能需要的必备功能。例如，一个函数可能需要从持久存储中检索状态，另一个函数可能使用机器学习服务来执行一些文本分析或图像识别。虽然无服务计算保证了功能本身可以扩展，但底层存储系统本身必须提供可靠性和服务质量保证，才能确保平稳运行。

5.无服务计算的工具和框架

普及无服务计算的主要阻碍是缺乏工具和框架。目前可用的工具和框架可以分为以下几类: 开发、测试、调试和部署。

几乎所有的云服务商都为流行的 IDE 提供了基于云的 IDE，或者扩展/插件，允许开发人员编写和部署无服务计算的函数。另外，一般还提供了一个带有 SDK 的本地容器化环境，允许开发人员在将本地无服务器功能部署到云环境之前进行开发和测试。

为了支持调试，开发人员可以使用运行日志，例如， AWS 就有公交允许开发人员检测问题的潜在原因。

最后，还有一些开源的框架，允许开发人员定义函数所需的无服务函数、触发器和服务，这些框架将处理相关的部署。

6.无服务计算的典型用例

无服务计算已经被广泛的采用。从基础设施的角度来看，无服务计算和更传统的体系结构可以互换使用，也可以结合使用。

从成本的角度来看，无服务器架构对突发的工作负载表现良好，因为开发人员将功能的弹性转移到了平台侧，同样重要的是，可以缩放到零，所以当系统空闲时没有任何成本。

从编程模型的角度来看，无服务器函数的无状态性质使它们适用于类似于函数式反应型编程中的应用程序结构。这包括展示事件驱动和类似流程的处理模式的应用程序。

确定何时使用无服务计算可能会受到其他非功能性需求的影响，例如对所需操作的控制程度、成本以及工作负载特性。

6.1 事件处理

在虚拟机的环境中，即使应用程序中的处理逻辑相对简单，用户仍然要必须管理 vm，包括监视流量负载、自动缩放应用程序和管理故障。为了响应突发的工作负载，虚拟机的添加速度受到限制，这迫使用户预测工作负载的模式，并为预先分配的资源付费。其结果是总会有闲置资源，而且虚拟机数量不可能缩小到零。

Netflix 使用无服务计算来处理视频文件。这些视频被上传到 Amazon S3,会发出事件触发 Lambda 函数，将视频解码，并以不同的格式并行转码。该Lambda 函数是完全无状态和幂等的，它的优点是在出现故障时(例如S3上文件的网络访问问题) ，可以在没有副作用的情况下再次执行该函数。

这个例子相对简单，通过将无服务计算与云服务商的其他服务相结合，可以开发更复杂的应用程序，例如，流处理、动态过滤和转换数据、聊天机器人以及 Web 应用程序。

6.2 API 组合

第2类典型的应用是 API 的组合，控制两个服务之间的数据流，或者简化通过聚合 API 调用进行交互的客户端代码。

举个例子，一个移动应用程序，它依次调用地理位置、天气和语言翻译 API来为用户当前位置提供天气预报。可以使用一个简洁的无服务计算函数来调用这些API。因此，移动应用程序避免了在一个资源受限的移动网络连接上调用多个API，并将过滤和聚合逻辑转移到后端。

需要注意的是，main 函数是一个调度器，它在调用另一个函数之前等待来自一个函数的响应，因此在函数在等待 i/o 时会产生执行成本。这种称为无服务计算的反模式。

无服务计算的编程方法是每个 API 调用封装为一个函数，并按顺序调用这些函数。这个序列本身就是一个复合函数，相当于一种编排服务。更复杂的编排可以使用 类似AWS 提供的其他服务来防止无服务计算的反模式，但是可能会因为其他服务而产生额外的成本。

6.3 密集计算

无服务计算对密集计算是非常有用的，能够运行函数，不用担心缩放且按需付费。性能接近于专门的优化解决方案，并且可以在科学计算的普遍环境中完成，比如 Python。

例如，利用FaaS框架来帮助用户避免运行 MapReduce 作业的开发和管理开销。它可以从 AWS Lambda 获得高达40TFLOPS 的峰值性能，使用 AWS S3进行存储和缓存，具体可以参考 https://github.com/awslabs/lambda-refarch-mapreduce。

如果不能轻松地将工作负载划分为更小的单元(如 Python 函数) ，那么面向批处理的系统(如 MapReduce 集群)才是更好的选择。

6.4 多租户云服务

另一个典型的应用场景是利用无服务计算构建一个多租户、安全、高可用性和可伸缩的解决方案，这极大地简化了多租户解决方案的架构。典型的流程开始于用户从前端应用程序(Web 浏览器)发出请求。通过使用外部服务对请求进行身份验证 ，然后将请求发送到云服务(比如提供视频文件的对象存储)或发送到无服务计算的函数。该函数进行必要的定制，并通常可以调用其他函数或(云服务。

许多公司的服务都充分利用了云服务。只要有可能，他们就使用现有的云服务，并使用无服务计算构建其功能。在无服务计算之前，他们需要使用虚拟机并创建自动伸缩策略。无服务计算具有几乎无限的按需可伸缩性，允许它们专注于将业务功能，而不是成为云基础设施和服务器管理方面的专家。

7. 无服务计算的云经济学

无服务计算采用与否要考虑商业的影响，以及技术进步的影响。云计算的客户选择无服务计算，是因为他们可以专注于解决自己领域或业务中的独特问题，而不是服务器管理或分布式系统中的问题。这种价值主张的优势是对未来采用无服务计算持乐观态度的主要原因。

7.1 成本与机会

由于资源的单位价格较高 ，无服务计算可能显得更加昂贵，但客户只为他们正在使用的资源付费，而云服务商承担空闲资源的成本。实际上，当把应用程序移植到无服务计算平台时，客户可以节省大量的成本。虽然这种成本降低可能会威胁到云服务商的收入，但低价可以激发消费增长，从而导致收入增长。

云服务商还通过帮助客户满足可变和不可预测的资源需求来获得盈利机会，他们可以从共享资源池中比客户使用自己的专用资源更有效地利用资源。这种机会也存在于无服务计算中，但随着资源在更细粒度的基础上共享而增长，无服务计算可以为云供应商提供提高利润率的机会。

7.2 收益与管控

无服务计算的现收现付模式对于云供应商的创新动机有着重要的积极意义。在无服务计算之前，自动缩放的云服务会自动提供虚拟机，也就是预留资源，但是客户将为这种能力付费，即使它仍然空闲的。使用无服务计算，云提供商为闲置资源支付费用，从而创建了自动缩放的外衣，并提供激励措施以确保有效的资源分配。类似地，云服务承担了对更多应用程序堆栈的直接控制，包括操作系统和运行时，无服务计算模型鼓励在各个层次上对效率进行投资。

更高效的程序员、更低的客户成本、更高的利润、更好的创新都为无服务计算的采用创造了有利条件。然而，一些云客户对供应商锁定提出了担忧，担心在与云供应商谈价格时议价能力下降。服务虚拟机抽象是标准化的，主要是因为 Linux 操作系统和 x86指令集，但是每个供应商的无服务计算和 BaaS API 有着显而易见的区别。由此产生的替代成本使最大和最成熟的云供应商受益，并激励他们推广对事实上的标准化有抵触的复杂API。

简单和标准化的抽象，也许是由小型的云提供商、开源社区或者学术界引入的，将会消除无服务应用中最突出的经济障碍。

8. 无服务计算可能是云计算的一个新阶段

也许，理解无服务计算代表着云计算的趋势是关注一个基本特性 : 提供一个隐藏服务器的抽象，从而简化了编程和操作模型。从一开始，无服务计算就提供了一个简化的操作模型，简化的编程来自于隐藏的服务器。云计算的未来发展，将受到提供简化云编程这种抽象的指导。

8.1 云计算的一般认知

令人吃惊的是，迄今为止，云计算几乎没怎么改变程序员的工作方式。云端运行的大部分软件与传统数据中心运行的软件完全相同。比较一下现在最需要的编程技能和10年前需要的编程技能，就会发现，即使特定的技术来来去去，核心技能的变化也很小。

相比之下，运维人员的工作发生了巨大的变化。安装和维护服务器、存储和网络基本上已成为过去，取而代之的是通过云服务商的API 管理虚拟化基础设施，以及强调变更管理的 DevOps。

是什么让云编程变得困难？虽然只能在一个服务器上使用云，但这既不提供容错性，也不提供可伸缩性，也不提供现收现付，因此大多数云编程很快就变成了分布式系统编程。在编写分布式系统时，程序员必须对数据中心的空间范围、各种局部故障模式以及所有安全威胁进行推理。这些问题代表了“偶然复杂度”，它起源于实现环境，与应用程序提供的功能所固有的“本质复杂性”形成了对比。正如高级语言隐藏了 CPU 运行方式的许多细节一样，无服务计算隐藏了构建一个可靠、可伸缩和安全的分布式系统所需的许多细节。

8.2 进一步的通用抽象

特定于应用程序的抽象解决了一个特定的用例，通用抽象必须在各种各样的用途中很好地工作。

来看一个大数据处理的例子。考虑一个可能在电子商务环境中出现的简单查询: 使用来自一百万个类别的权重计算超过100亿条记录的平均值，此工作负载具有大量并行性的潜力。要做到这一点，一般地，需要编写一个简单的 mapreduce 程序，例如，使用 Java 或 Python，有两个函数: 一个是为某些数据块计算一个加权平均数，另一个是为它们的合并结合不同块的加权平均值。框架负责数据在这些函数中的输入和输出，以及自动扩展、可靠性和其他分布式系统关注点。与基于SQL的工具相比，这种抽象可以运行任意的代码，这使得它适用于更广泛的分析问题。

我们有可能将它们转化为通用的无服务计算抽象，通过自动优化来消除低效率。在某些情况下，也可以根据程序的分析静态地做出这样的推论，人们可能会认为这种形式的无服务器计算是对分布式系统的支持扩展。

在通用情况下，云提供者公开了一些基本的构建块，例如，增强版的云服务和某种类型的无服务存储。可以在这些基础之上构建各种特定于应用程序的用例。通过使用特定于应用程序的无服务器，云提供商反而提供了大量的 BaaS，以满足越来越多的应用程序的需求。

8.3 会成为云计算的明确方向么？

如今，无服务器计算仍然完全是特定于应用程序的多样性。即使是可以执行任意代码的云函数，也主要用于无状态 API 服务和事件驱动的数据处理。特定于应用程序的无服务器计算将会增长，但令人兴奋的是，可能出现通用的无服务器抽象，它可以托管满足各种需求的软件生态系统。只有通用的方法才能最终取代服务器成为云编程的默认形式。

虽然无服务器计算可以成长为云编程的默认模式，但服务器计算仍可能占据主导地位。

首先，有效的计算是一个不断变化不断改进的目标。曾经按小时计费的云虚拟机现在的最小计费增量为一分钟。容器和 VM 编排工具(例如K8S)简化了复杂的部署，并且越来越多地自动化管理任务(例如备份)。在构建应用程序时，程序员可以依赖成熟的软件生态系统，公司也已经拥有了熟练的云部署团队。服务器硬件越来越强大，在一个紧密耦合的环境中将 CPU、内存和加速器能力结合在一起，这对某些应用程序是有益的。

其次，今天成功的无服务计算产品属于特定于应用程序的类别，目标范围很窄，而通用的无服务计算抽象更有可能有服务的计算取代(这也是通用的)。然而，通用的无服务计算面临着障碍，对于云提供商来说，这可能是一个不那么有利可图的业务。

最后，“无服务计算”的品牌也可能无法生存。将旧产品贴上新产品标签的诱惑很强烈，可能会在市场上造成混乱。连Google App Engine 这样的产品都打上了无服务计算的标签，这个术语被冲淡了，那么也许，通用的无服务计算将以另一个名称出现。

9. 无服务计算局限与潜在风险

无服务计算是向前迈出的一大步，正受到业界的广泛关注，并开始获得学术界的支持。虽然无服务计算有许多直接的创新需求，但仍然有许多局限和潜在风险，无法实现无服务计算的全部潜力。

9.1 编程模型和工具

由于无服务计算函数的运行时间较短，因此将有多个数量级函数组成的应用程序 ，一个视频流服务运行超过150个无服务计算函数。然而，这将使调试和识别瓶颈更加困难。传统的工具假定可以访问服务器来监视和调试应用程序，但这些工具不适用于无服应用，因此需要新的方法。尽管其中一些工具已经开始可用，但是高级别的开发 IDE 以及用于编排和组合应用程序的工具将非常关键。

此外，平台可能需要使用不同的语义进行扩展，例如至少一次或最多一次，或者使用更复杂的并发语义，例如函数执行被序列化的原子性问题。此外，无服务平台必须完全支持重构函数(例如，拆分和合并它们)以及版本恢复。虽然这些问题已经得到了业界的广泛关注，但是仍然没有根本解决。

9.2 缺乏标准和供应商锁定

无服务计算是崭新且快速变化的，目前没有标准。随着这一领域的成熟，可能出现一些标准。与此同时，开发人员还不能使用允许不同的无服务计算提供程序互换使用的工具和框架。

9.3 冷启动问题

无服务器的一个关键区别在于能够收缩到零，并且不向客户收取空闲时间费用。然而，缩放到零会导致冷启动问题，特别是对于具有定制库需求的函数。在仍然缩放到零的情况下最小化冷启动问题是关键的。目前一个更基本的问题是，容器是否是运行无服务应用程序的正确抽象，以及具有较小占用空间的抽象，比如单核，是否更适合。

9.4 代码兼容问题

无服务计算的应用程序设计与典型的应用程序有着根本的不同。现有代码的经济价值代表了开发人员花费无数小时编码和调试软件的巨大投资。最重要的问题之一可能是现有遗留代码在多大程度上可以自动或半自动地分解成更小粒度的片段，才能利用无服务计算。

9.5 持久化问题

目前的无服务平台大部分是无状态的，如果将来会有支持持久化的无状态服务，那么应用程序具有不同程度的 QoS，同时又不牺牲可伸缩性和容错性，这是一个悬而未决的问题。

10. 无服务计算的趋势与挑战

无服务计算在迅速发展，并提供了各种挑战，其中许多挑战是特定应用程序和通用无服务的共同点。

10.1 状态管理

分布式云应用程序通常需要在其组件任务之间交换短暂的或临时的状态。例如，应用程序范围的缓存、索引和其他查找表，或大数据分析的中间结果。当前的无服务计算允许应用程序在每个函数本地存储临时状态，这对于缓存和作为程序的工作内存非常有用。

无服务计算的共享状态可以保存在对象存储或键值存储中，但这些不能同时提供低延迟、低成本、高吞吐量和细粒度访问，而服务器可以做到这一点。解决这些挑战的方法可能是为分析器提供临时数据存储，以及提供一致性保证的有状态无服务计算函数。

10.2 网络

无服务计算将调度工作的责任从用户转移到云服务商，这会产生一些有趣的结果。由于用户放弃了对函数何时运行的控制，在无服务计算函数之间传递状态需要通过共享存储进行访问; 之间的网络通信没有什么意义，云服务商会阻止它。访问共享存储会增加显著的延迟，有时可能达到几百毫秒。

用户还放弃了对无服务计算函数运行位置的控制，从而排除了服务器常见的优化，包括在任务之间的共享公共输入，并在通过网络发送输出之前合并输出。克服这些挑战的尝试将凸显给予程序员更多的控制权和允许云服务商自动优化之间的矛盾。

10.3 可预测的性能

FaaS 和 BaaS 都可以表现出可变的性能，这就妨碍了它们在必须满足性能保证的应用程序中的使用。部分原因是基本的: 无服务计算提供者依赖于统计上的多路复用来创建无限资源的假象，同时拒绝用户对资源超额订阅的控制。总是有一些机会会造成排队延迟。

将资源从一个客户重新分配给另一个客户也会产生延迟成本，冷启动延迟有多个组成部分，其中最重要的是初始化函数的软件环境所需的时间。可以加快应用程序级别的初始化，比如加载库。这些方面可能仍然有很大的挑战，尽管性能优化和安全性隔离在根本上是不一致的。AWS Lambda 的客户还可以通过购买“有准备的并发性”来避免冷启动延迟，这种方式有争议地重新引入了一种资源预留形式到无服务模型里。基于统计保证或服务水平目标(SLO)的定价，在当今的无服务计算环境中是不存在的。

10.4 安全性

无服务计算导致细粒度的资源共享，因此增加了通道攻击的风险，攻击者可以利用真实硬件的微妙行为，这些行为与程序员的假设不同。威胁范围从 Rowhammer 对 DRAM的攻击到那些利用微架构漏洞的攻击。

由于无服务计算可能采用随机调度，使攻击者难以锁定特定的受害者。由于应用程序的细粒度分解和各个部分的物理分布，无服务计算还可能导致通过网络通信产生更大的信息泄露。攻击者观察网络流量的大小和时间，即使它是加密的，也可能对私有数据做出推论。

10.5 编程语言

简化编程是无服务计算的一个核心好处，无服务计算的设置需要一个新的视角，并增加了紧迫性。传统的挑战包括容错性、一致性、并发性以及局部性带来的性能和效率。新的挑战包括对自动扩展、按需付费和细粒度多路复用的支持。

尝试将无服务计算扩展到无状态云函数之外，会提高容错能力。Azure 持久功能使用 C# 语言特性来提供透明的检查点，这使得编写有状态和可恢复的无服务器任务更加容易。微软实现了一个 actor 模型，同样向程序员隐藏了容错问题。参与者还提供了局部性的概念，并且可以作为有状态无服务器计算的云函数副本。一致性的方法包括语言集成的事务。然而，事务充满了性能和可伸缩性的挑战，自动伸缩的无服务环境可能会加剧这些挑战。另一种方法存在于像 Bloom 这样的语言中，它允许自动分析来确定程序的哪些部分可以独立运行，不需要协调，因此是可伸缩的。

现收现付应该鼓励语言开发人员重新考虑资源管理，例如，自动垃圾收集可能适用于计量内存定价。云编程的语言方法解决了分布式系统编程的复杂性，可能是简化云编程最直接的方法。

10.6 服务级别(Service-level agreement，SLA)

无服务计算将使开发服务更加容易，但是提供 QoS 保证仍然很困难。虽然无服务平台需要提供一些可伸缩性、性能和可用性的保证，但是如果应用程序依赖于整个服务生态系统，比如身份提供者、消息队列和数据持久性，这些都不在无服务平台的控制范围之内，那么这种保证就变得用处不大。

为了提供一定的 QoS 保证，无服务平台必须将所需的 QoS 需求传递给相关组件。此外，可能需要通过仔细衡量这些服务 ，在API 之间进行强制执行，以确定瓶颈。

10.7 边缘的无服务计算

随着物联网和其他移动设备的增加，在无服务计算和边缘计算之间有一种自然的联系，因为事件通常是在边缘产生的。例如，AWS将其无服务计算能力扩展到了基于边缘的云环境。netflex 使用 AWS Lambda 进行图像识别就是一个例子。

因此，运行在边缘和云端的代码不仅可以嵌入，而且可以虚拟化，允许设备和云端之间的移动。这可能导致重新定义成本，例如，资源使用可能比速度更重要。

10.8 机器学习

自动优化与机器学习将发挥重要作用。它可以帮助决定在哪里运行代码，在哪里保持状态，何时启动新的执行环境，以及如何在满足性能目标的同时保持高利用率和低成本。

机器学习还可以帮助识别威胁安全的恶意活动，或者自动将大型程序切割成可以在单独的无服务计算函数中执行的片段。机器学习也可以帮助优化大量的计算，无服务的抽象赋予了云服务商更多的控制按钮，以及模型训练的可见性。

10.9 硬件

目前的硬件趋势可能是无服务器计算的补充。主导云计算的 x86微处理器的性能几乎没有提高，这一趋势如果继续下去，性能在20年内不会翻番。同样，摩尔定律的终结也减缓了每芯片 DRAM 容量的增长。

可能的方案是引入特定领域架构(Domain Specific architecture，DSA) ，这种架构针对特定类型的问题进行了定制，提供了显著的性能和效率提升，但在其他应用程序中表现不佳。GPU长期以来一直被用于图形加速处理，目前已经是用于机器学习的 DSA了，使用 DSA增强的通用处理器可能会成为标准。

无服务器计算可以为集成不同的体系结构提供一个有用的编程模型，比如说在独立的加速器上运行独立的云功能。它还有助于通过提高抽象级别为创新创造空间，例如，允许云供应商在识别可能受益的工作负载时用 DSA 替代 CPU。

结束语

无服务计算是云应用程序开发的一种演变，FaaS模型已经在许多应用场景中被证明是有用的，从具有突发调用模式的事件处理，到计算密集型的大数据分析。无服务计算降低了开发人员的门槛，将大部分监控和扩容的操作复杂性委托给了平台提供者。然而，开发人员现在需要解决其无状态性的限制，并了解如何将其应用程序的SLA映射到无服务器平台和其他依赖服务的SLA。

如果说无服务计算代表了云计算的新阶段，那是因为它代表了一个新的价值主张: 简化云编程。无服务计算提高了云的抽象级别，采用现收现付的定价，并且快速地自动缩放到零和实际上无限的资源。

无服务计算仍在发展，在定义其抽象和实现抽象方面仍存在许多开放性问题。未来的无服务计算可能是:

• 虽然典型的云计算不会消失，但是它在云计算中的相对使用肯能会下降，因为无服务计算克服了它目前的局限性

• 期望新的通用的无服务抽象支持几乎任何用例。它们将支持状态管理以及优化，或者可能比多任务计算更好

• 无服务计算的成本不会超过有服务计算的成本。随着不同应用程序的发展和普及，无论是小型的还是大规模的应用程序，无服务计算的成本不会增加，甚至可能会降低很多

• 机器学习将在无服务计算实现中发挥关键作用，允许云提供者优化大规模分布式系统的执行，同时提供一个简单的编程接口

• 用于无服务计算的计算机硬件将比目前使用的传统 x86服务器更加多样化

如果真的如此，无服务计算才可能成为云时代的默认计算范式，可能取代服务器计算，从而进入了新的时代，就像智能手机带来了 PC 时代的终结那样。

【参考资料 与关联阅读】

• https://cacm.acm.org/magazines/2021/5/252179-what-serverless-computing-is-and-should-become/
  

• https://m.cacm.acm.org/magazines/2010/4/81493-a-view-of-cloud-computing

• http://www.serverlesscomputing.org/wosc17/#keynote

• https://github.com/cncf/wg-serverless#whitepaper

• Technical Report; arXiv:1708.08028, 2017

• https://peerj.com/preprints/27005