无服务器计算

已完成

在云计算的早期阶段,Amazon 和 Microsoft 等云服务提供商致力于为客户提供丰富的 IaaS 服务。 通过允许客户相当轻松地将物理服务器或虚拟机本地运行的工作负载转移到云中的虚拟机,这推动了公共云的增长。 但伴随 IaaS 而来的是责任。 在云中启动 VM 的组织还负责维护 VM 内的对象:操作系统、所需的任何运行时、利用这些运行时的应用程序等。

PaaS 将部分责任转移给云服务提供商,并进一步推动对云的投资。 借助 AWS Elastic Beanstalk 和 Azure 应用服务等服务,客户可以预配配备常用运行时(例如 Java、Node.js 和 Microsoft .NET)的虚拟 Web 服务器,并在几分钟内在其上运行软件。 当虚拟机在后台执行繁重的任务时,这些虚拟机的存在在很大程度上被抽象化。 PaaS 使客户能够专注于他们为解决业务问题而编写的应用程序,而不必花费时间来管理 VM 及持续修补和更新平台。

无服务器计算是云计算中相对较新的创新,它使这种抽象更进一步。 假设贵组织编写并维护以下类型的代码:每晚执行任务关键型数据备份的代码、执行每周计费运行的代码,或每当将发票上传到云存储时即传输电子付款的代码。 在这种情况下,首要目标是执行此代码并在适当的时间执行它。 其他事项都是次要的,包括代码的存储位置以及代码的执行方式和执行位置。

采用 IaaS 方法,方法是创建一个或多个 VM 用于运行代码并安装必需的平台和库。 可以预配一个 Elastic Beanstalk 或应用服务实例并在其中托管代码。 或者,可在需要时随时使用函数运行时(例如 AWS Lambda 或 Azure Functions)执行代码,而不考虑代码的托管位置或托管方式。 AWS Lambda 和 Azure Functions 都是无服务器计算(特别是无服务器函数)的示例,Google Cloud Functions 也是相关示例。 三者均代表从 IaaS 到云计算的自然演进中的下一步。在 IaaS 中,你负责所有事务,而在无服务器计算中,你专注于要在云中执行的操作(要执行的代码),而让云服务提供商管理所有其他事务。

由云中的函数运行时执行的无服务器函数是无服务器计算的最常见形式,但并非唯一形式。 Amazon、Microsoft 和 Google 提供其他一些 PaaS 服务的无服务器版本,包括无服务器数据库。 一些提供商提供对无服务器工作流的支持,此类支持让你可以在云中定义业务工作流并执行它们用于响应外部事件(例如上传到云存储的发票、按指定间隔触发的计时器或到达收件箱的电子邮件),且通常无需编写任何代码。 最后,云服务提供商提供的许多容器服务(包括 Azure 容器实例和 AWS Elastic Container Service)可作为无服务器计算的示例,因为它们使你可以在云中运行容器,同时抽象化基础结构。

无服务器计算的优势

无服务器计算为利用云计算的组织提供三个主要优势:

降低计算成本:客户通常按月为 IaaS 虚拟机和 PaaS 服务(例如 Elastic Beanstalk 和 Azure 应用服务)付费。 即使服务处于空闲状态,计费仍将继续。 但是,大多数无服务器计算服务都支持使用定价,在这种定价模式中,只需为执行代码的时间付费。 假设专门使用一个每月费用为 100 美元的 VM 运行代码,而代码每晚执行一次任务关键型数据备份并每晚运行 30 分钟。 你每个月要支付 100 美元,但仅在 1/48 个月或不到一天的时间内执行代码。 如果将同一代码作为无服务器函数进行部署,每月只需花费几美元。 借助使用定价,无需为空闲时间付费。

自动可伸缩性:云服务提供商提供在产品中缩放 IaaS 服务的机制,例如 AWS Auto Scaling 和 Azure 中的虚拟机规模集。 它们还为 PaaS 服务提供手动和自动缩放选项。 但即使缩放自动执行,云管理员也必须启用自动缩放并进行配置,以便云服务提供商知道应该如何以及何时进行缩放。 管理员必须考虑的基本注意事项之一是,由于要为 IaaS 和 PaaS 服务的单个实例付费,可能需要将服务配置为足量缩放,而不过量缩放。 无服务器计算提供透明且自动的横向扩展选项用于满足增长的需求以及在需求下降时进行缩小。 除在服务中启用此选项外,云管理员通常不执行任何配置。 如果一次遇到 100 个请求要执行无服务器函数,则云服务提供商会确保可以并行(或大部分并行)执行请求。 成本不会受到影响,因为在使用定价模式中,这与执行一个函数 100 次的成本相同,而无论执行是串行执行还是并行执行。

降低管理成本:无服务器计算让你能够专注于执行代码和工作流,同时将所有其他事项(包括维护基础平台)的责任转移给云服务提供商。

无服务器计算也有不足之处。 需要考虑的一些限制包括:

  • 一些函数运行时会限制允许函数执行的时长。

  • 除非愿意支付更多成本,否则一些函数运行时不保证函数会立即执行。 例如,通过将 Azure Functions 配置为利用基于使用的定价,某个函数在触发后的最长执行时间可能不会超过 10 分钟。 对于夜间备份来说,这可能不是问题;你可能不关心备份是在凌晨 1:00 还是凌晨 1:10 运行,但它可能会影响必须实时(或接近实时)执行的时间关键型函数。

  • 无服务器函数通常无状态,也就是说,它们无法在内部存储数据,并且会从一个函数调用保留到下一个函数调用。 它们使用外部云存储服务(例如 Amazon S3 和 Azure 存储)在两次调用之间保留数据,但这会使函数的代码更加复杂。

一些云服务提供商提供对有状态函数(Azure 称其为“Durable Functions”)的支持,但保留状态的函数是无服务器计算中相对较新的新增功能,并未受到普遍支持。

无服务器函数

无服务器计算的最常见示例是无服务器函数。 将代码上传到云,并告诉它何时执行。 该代码可使用多种语言编写,包括 Java 和 C#。

图 11 列出了撰写本文时 Azure、AWS 和 GCP 中的无服务器函数支持的编程语言:

语言 Azure Functions AWS Lambda Google Cloud Functions
C# x x
F# x
Go x x
Java x x
JavaScript (Node.js) x x x
PowerShell x x
Python x x x
Ruby x
TypeScript x

图 11:常用无服务器函数运行时支持的编程语言。

创建函数并提供其将执行的代码时,还会标识导致该函数运行的外部事件。 常用云平台支持各种类型的触发器,包括计时器、其他云服务中发生的事件(例如要上传到云存储中的文档)以及 HTTP 调用。 将计费代码上传到函数运行时并配置为每天、每周或每月运行一次很简单。 在每次将发票上传到云存储(例如,Amazon S3 或 Azure 存储)时或在每次调用与该函数关联的 REST 终结点时激活函数同样很简单。

无服务器函数经常用于执行独立任务,例如每晚备份和计费。 它们还用于连接其他云服务,并通过将云服务用作构建基块来构建丰富的解决方案。 图 12 介绍了一个此类解决方案,该解决方案用于合并多个 Azure 服务来监视北极地区的北极熊活动。 通过从 Azure 流分析中获取输出(由 HTTP 调用触发),从 Azure Blob 存储中检索照片以及将照片提交到使用 Azure 自定义视觉服务进行训练的模型(使用人工智能 [AI] 确定照片中是否包含北极熊)中,Azure 函数在体系结构中起着关键作用。 该函数是将流分析、Blob 存储和自定义视觉服务绑定在一起的粘合剂。

Figure 12: Using an Azure Function to connect other Azure services.

图 12:使用 Azure 函数连接其他 Azure 服务。

无服务器工作流

一些无服务器计算服务使客户无需编写代码即可实现业务工作流的自动化。 例如,Azure 逻辑应用提供 100 多个内置连接器,用于与从 Oracle 数据库到社交媒体服务(如 Twitter)的数据源进行交互。 它们提供用于定义应何时执行工作流的触发器,例如,在文件上传到 Box.com 时或使用指定话题发布推文时。 它们还提供数百个预定义的操作,这些操作定义触发器被触发时会发生什么,并可链接在一起形成复杂的工作流;它们还提供允许操作有条件地执行的条件。 而且它们可无限扩展,因为 Azure 逻辑应用支持的其中一个操作就是调用 Azure 函数。 如果工作流涉及未封装在操作中的自定义逻辑,则可以提供实现该逻辑的代码,并将其包括在工作流中,就如同它是预定义的操作一样。

图 13 显示 Azure 逻辑应用设计器1中的一个此类工作流。 电子邮件到达时,逻辑应用便会启动,并检查电子邮件主题行是否包含关键短语以及是否存在附件。 如果两个条件都满足,则逻辑应用会调用 Azure 函数以从电子邮件正文去除所有 HTML。 然后,它将经过净化的电子邮件及其随附的所有附件都存储在 Azure Blob 存储中,并发送包含指向 Blob 存储中相关文档的链接的电子邮件,以通知相关方此类信息可用并等待查看。 此示例合并两个无服务器范例:一个无需任何代码(至少不是你或组织中的任何人编写的代码)即可执行操作的逻辑应用,以及一个包含提供用于自定义工作流的代码的 Azure 函数。此示例代表云计算中正在发生的从自己动手的虚拟机到更高级别的抽象的转变,这让组织能够将精力集中在解决业务问题上,而不是花费时间管理虚拟机以及安装和维护运行时。

Figure 13: Defining a workflow in Azure Logic Apps.

图 13:在 Azure 逻辑应用中定义工作流。

Amazon 以 AWS Step Functions 的形式提供类似服务。 借助 Step Functions,你可以构成合并其他服务(例如 AWS Lambda 和 AWS ECS)的可视工作流。 工作流包括一系列步骤,其中一个步骤的输出用作下一个步骤的输入。 与 Azure 逻辑应用一样,AWS Step Functions 提供用于分支和并行执行的基元,让你无需编写代码即可执行此操作。 实际上,业务工作流成为易于理解、易于向他人解释且易于修改的状态机示意图。

无服务器数据库

在云计算的早期阶段,在云中托管数据库意味着预配虚拟机并安装数据库产品,例如 MySQL、PostgreSQL 或 SQL Server。 PaaS 通过以服务的形式提供数据库改变了这一点。 例如,借助 Azure SQL 数据库或 Amazon Relational Database Service (RDS),只需预配一个实例,几分钟后便可使用云托管数据库来为客户端提供服务。 此外,云服务提供商通过应用软件更新和修补程序来使数据库平台保持最新状态。

无服务器数据库是云计算中的一项最新创新,它提供经过优化的性价比模型,非常适合具有不定期使用模式的单个数据库。 例如,Azure 提供 Azure SQL 数据库的无服务器版本。 在主流版本的 Azure SQL 数据库中,你可以根据预期数据库处理的最大负载来选择性价比层。 如果负载是“尖峰性”或间歇性的,则经常会按照数据库始终承受最高负载进行付费。

根据需要缩放数据库以处理遇到的负载,借此 Azure SQL 数据库的无服务器版本可缓解这种情况,成本为计算成本和存储成本之和。 与拥有使用模型的无服务器函数一样,只需为使用的部分付费。 Amazon 以 AWS Aurora Serverless 的形式提供类似服务,这是 Amazon 的 Aurora 数据库服务的无服务器版本,而 Google 为客户提供 NoSQL 数据库服务的无服务器版本,称为 Google Cloud Firestore。

参考

  1. Microsoft (2019)。 使用 Azure 逻辑应用自动处理电子邮件和附件https://learn.microsoft.com/azure/logic-apps/tutorial-process-email-attachments-workflow

知识检查

1.

以下哪一项不是你会考虑使用无服务器计算解决方案的方案?