无论是出于高昂的维护成本，还是对专业人力的需求，维护物理或虚拟服务器都并非易事。无服务器计算通过提供一种经济实惠的方式，让开发人员在云端构建并运行应用，从而解决了这些问题。
本文将回顾无服务器计算、其应用场景，以及它对开发者和企业的益处。这个话题之所以重要，是因为无服务器计算的市场规模在 2022 年已超过 900 万美元，并预计在未来十年再增长 25%。让我们开始吧。
定义与概览
假设您家中的水电费不是按固定的月度估算收费，而是根据实际用量计费。无服务器计算的原理与此类似：云提供商按使用量为您分配基础设施资源，让您无需担心服务器维护，就能构建和运行应用程序。
与传统云计算需要部署物理或虚拟服务器、存储和网络设备不同，在无服务器计算中，云提供商负责管理基础设施，并在您的应用进行扩缩时自动为您分配资源。换言之，无服务器计算将服务器从开发者的视野中抽象出来，使其能够更专注于构建应用本身，而不必操心应用所托管的基础设施。
想象一下，您的应用平时每日有 100 到 200 名用户。若第二天用户数突然飙升至 1,000,000，平台会自动扩展资源以满足需求。传统云计算难以做到这一点，因为服务器会因流量激增而出现停机，如果存储不足，还需要采购更大的存储，这将耗费时间。
| 类别 | 无服务器计算 | 传统计算 |
|---|
| 扩展方式 | 动态 | 固定 |
| 计费 | 按使用量计费 | 不论使用与否均有持续成本，且包含维护与运营成本 |
| 基础设施管理 | 对企业抽象 | 需要主动管理 |
关键特性
在了解将无服务器计算与其他传统云模型区分开的关键特性之前，先来看一些无服务器计算中的关键术语。
- 函数（Function）：一段用于执行特定任务的代码，如文件上传、处理 HTTP 请求等。每个函数彼此独立，并设计为对事件作出响应。
- 调用（Invocation）：对函数发起调用以执行特定操作，也可理解为函数在事件触发下的代码执行。
- 时长（Duration）：从函数被调用到返回响应所经历的时间。
- 冷启动（Cold Start）：函数被调用后，服务器平台在开始执行前为其分配资源所需的时间。
- 并发上限（Concurrency Limit）：函数在响应事件和请求时可同时运行的实例最大数量。
- 超时（Timeout）：服务器平台允许函数在被终止前的最长执行时间。
事件驱动的执行
事件驱动的执行也称为函数即服务（FaaS），无服务器应用被拆分为相互独立的无服务器函数，这些函数由特定事件触发，如 HTTP 请求、数据库变更、消息队列或文件上传等来源。
假设您有一个无服务器应用，会在图片上传到 Amazon S3 存储桶时自动处理。用户上传图片文件后，会触发某个函数来处理图片，并将其保存到另一个 Amazon S3 存储桶。这样一来，函数只在需要时运行，使系统高效且具成本效益。
以文件上传为例的事件驱动执行。图片作者自制
自动伸缩
自动伸缩是指根据需求或工作负载的增加来分配计算资源。这是无服务器计算的关键特性之一，使其高效且具适应性：当工作负载或需求较低时避免资源浪费，而在高需求时避免出现停机。
例如，您的应用遇到流量激增。平台不会因高流量导致服务器宕机，而是会自动提供额外实例来处理增加的工作负载。同样，当流量较低时，平台会缩减资源以降低成本。整个过程无需人工干预，确保应用在不同场景下既经济又响应迅速。
按用量付费
无服务器平台按实际使用的资源向用户收费，而不是按预分配的资源计费。与传统云模型可能出现的“资源分配但未充分使用”不同，在无服务器平台中，您只为实际使用的计算时间买单。费用还会精确到调用次数或函数执行时长，确保按您实际使用的资源精准计费。
例如，如果您的应用在某个月内为用户处理了 100 张图片，那么您无需为 24/7 的服务器使用付费，而只需为处理这 100 张图片所消耗的计算时间付费。
服务器管理抽象
这同样是无服务器计算的一项关键特性，开发人员和企业无需关心服务器的部署、扩缩与维护。这样可以将精力集中在核心业务问题上，而把服务器维护交由云提供商处理。
并发管理
无服务器平台可以同时执行多个函数。与传统方法相比，这让其更快速、更高效。比如，用户要在平台上上传图片，而无服务器提供商的默认并发上限为 100，那么超出并发上限的请求将被排队，等待下一次函数执行。
无服务器计算的优势
成本效率
与传统云计算需要专用服务器、且即便服务器空闲也会产生成本不同，无服务器平台采用事件驱动的计费模式。一个贴切的类比是打车与拥有私家车。打车无需操心停车费、燃油费等开销，只需按行驶里程付费。在无服务器计算中，就像打车一样，您只为实际使用的计算资源付费。而传统方式（拥有一辆车）中，即使系统空闲，您也要承担所有计算资源的成本。
不同服务器类型的成本效率对比。来源：Cloudflare
降低运维复杂度
在无服务器计算中，开发人员无需投入时间安装和维护服务器，从而节省大量时间，更专注于构建应用。由于应用由相互独立的云函数构成，可以单独更新某个函数，而不会影响其他函数或整个应用。
更强的可扩展性
这是无服务器平台最重要的优势之一，也是其在中小型组织和初创公司中广受欢迎的原因。无服务器平台让开发人员能在需求上升时自动扩展。对于请求波动较大的函数，无服务器平台会通过增加或减少资源分配来满足请求，确保计算资源得到优化。
更快的上市速度
借助无服务器应用，您可以快速发布应用并立即获得用户反馈。对于初创公司而言，这能显著减少开发时间和所需人力。
可靠性
与托管在专用服务器上的应用不同，无服务器应用可在任意地点运行。与传统云计算相比，这提升了应用性能并降低了延迟。
无服务器架构及其工作原理
无服务器架构是一种无需安装和管理承载应用的基础设施即可构建应用的方式。开发者可以采用两种无服务器模型之一来构建无服务器应用：即后端即服务（BaaS）或函数即服务（FaaS）。
FaaS 与 BaaS 的无服务器云架构。来源：Journal of Cloud Computing
无服务器架构的主要目标是将服务器管理从开发者中抽离。以下是无服务器平台在其基础设施中如何运作的分解说明。
- 函数创建：采用无服务器架构构建的应用会将代码拆分为若干子部分，每一部分都是独立函数，彼此独立，旨在完成特定任务。
- 函数开发：这些函数被打包并部署到无服务器平台，如 AWS Lambda、Azure Cloud Functions 或 Google Cloud Functions。
- 事件驱动的执行：这些函数会在特定事件或触发器出现时被调用。触发器可以是数据库变更、HTTP 请求等。
- 自动伸缩：无服务器平台会随着工作负载的增减来管理资源使用。例如，当某个函数流量较高时，服务器将分配更多资源。
- 瞬态容器：事件被触发后，会创建容器使正在执行的函数能够访问所需资源。任务完成后，这些容器会被销毁。
- 计费：根据执行时间与所用计算资源进行计费。
- 无状态性：无服务器函数在执行时不保留状态。调用所需的任何信息会保存在数据库或外部系统中。
- 日志与监控：无服务器平台提供日志与监控工具，用于追踪应用性能及函数中的问题。
有人可能会问：既然容器架构也将服务器从开发者中抽象出来，那么与无服务器架构是否相同？这在一定程度上成立，但不同于无服务器函数在构建与交付应用时的完全抽象，在使用容器时，一旦应用遭遇高流量，就需要使用如 Kubernetes 等工具来扩展容器。这与 FaaS 的目标相悖——在 FaaS 中，与服务器相关的所有操作都由无服务器平台自动处理。
在容器架构中，容器实例可能会长时间运行，从而产生成本；而在无服务器函数中，您仅为函数运行所花费的时间付费。对于较小的应用，采用无服务器架构有助于将其解耦为平台可作为独立函数运行的部分。
无服务器计算平台
早在 2008 年 Google App Engine 推出之前，Zimki 就曾提供首个“按需付费”的代码执行平台，但后来关闭。在早期阶段，Google App Engine 仅支持 Python，并为包括 SnapChat 在内的应用提供按量计费。约在 2010 年，另一个名为 PiCloud 的平台也为 Python 应用提供了 FaaS 支持。
2014 年，AWS 通过发布 AWS Serverless Application Model（AWS SAM）和 Amazon CloudWatch 等工具，使无服务器模型广为人知。2016 年，Google 推出了其第二款无服务器产品 Google Cloud Functions，微软也发布了 Azure Functions。从那时起，陆续出现了诸多无服务器平台，例如阿里云的函数计算以及 IBM Cloud 的 IBM Cloud Functions。
为消除对虚拟或物理数据库的需求，也出现了无服务器数据库。AWS 提供了基于 MySQL 和 PostgreSQL 的无服务器版本 Amazon Aurora。Azure 提供了 Azure Data Lake，而 Google 提供了 Firestore。
无服务器云平台。来源：Network Interview
实践应用与用例
网站与 API
无服务器计算用于构建网站应用与 REST API。其亮点在于，基于无服务器基础设施构建的应用可根据用户需求自动扩缩，从而提升用户体验。
媒体处理
无服务器架构让媒体处理更加便捷。用户可从不同设备上传大小不一的媒体内容，平台通过一个函数即可满足所有用户的处理需求，而不会降低应用性能。例如，用户可通过 S3 存储桶上传图片，从而触发 AWS Lambda 函数为图片添加水印或缩略图。
聊天机器人
开发者可以利用无服务器架构实现能回应客户问题的聊天机器人，并只为该机器人实际使用的资源付费。例如，Slack 使用无服务器架构来应对机器人请求的波动，以避免因客户需求的日常起伏而造成带宽闲置。
Webhooks
您可以通过无服务器平台与 SaaS 供应商进行交互，方式是使用一个 webhook 的 HTTP 端点来接收通知并执行任务。这样构建的 webhook 具有维护量低、成本低且可自动扩展的优势。
物联网（IoT）
可口可乐在其售货机 Freestyle 上采用无服务器架构，让顾客可以下单、支付并接收支付通知。可口可乐称，他们运营售货机的年成本曾约为 13,000 美元，采用无服务器架构后降至每年 4,500 美元。
数据处理
美国职业棒球大联盟高级媒体（MLBAM）使用无服务器架构构建了其产品 Statcast，为用户提供准确、实时的体育数据指标。它利用无服务器计算处理数据并为用户提供棒球比赛的洞见。
事件驱动的应用
无服务器架构可用于事件驱动的应用，即当事件或状态发生变化时，会触发某项服务。可以使用无服务器平台监测数据库变更，并将变更与质量标准进行比对。
无服务器边缘计算
由于数据需要长距离传输，应用从中心化服务器处理请求和分发内容时会产生延迟和瓶颈问题。
无服务器边缘计算通过将计算资源分布到多个地点来缓解这一问题，从而减轻中心服务器的负载。无服务器边缘计算是指将运行无服务器函数的计算资源部署在更靠近终端用户（边缘）的位置。这使无服务器应用能在更多设备上运行，降低拥塞与延迟。
在无服务器边缘计算中，基础设施可针对每台设备提供支持，使其无需将数据回传中心位置处理，也能执行复杂任务。以下是一些利用无服务器边缘函数优化用户体验的用例：
- 个性化体验：借助无服务器边缘函数，用户可以基于偏好、位置与设备类型来个性化内容。
- 视频流媒体与游戏：在靠近用户处处理请求可降低观看视频或在线游戏时的延迟与缓冲。
- 安全与认证：通过将工作负载分发至多个边缘位置，可在恶意流量抵达中心基础设施前对其进行检查与过滤。
- 物联网设备：无服务器边缘计算通过确保运行设备的基础设施贴近用户，使物联网设备更高效地工作。
挑战与注意事项
尽管无服务器计算带来了诸多益处，但也存在以下一些不足。
- 供应商锁定：大多数云提供商都提供与无服务器应用高度集成的多项服务。虽然可以在您的服务器应用中使用其他供应商的服务，但单一提供商的服务往往更易集成。
- 可控性较弱：另一个问题是对服务器缺乏控制。如果服务器出现宕机或硬件故障等问题，您无法自行修复，只能依赖云提供商处理。
- 冷启动：当某个函数长时间未活动后被调用，可能需要几秒钟才能开始执行。这会引入延迟，影响应用性能与用户体验。
- 安全性：将数据交由第三方托管并与其他用户共享服务器，若服务器配置不当，可能会让您的应用与用户数据面临暴露风险。
- 调试复杂性：由于无服务器应用的特性，开发者很难在本地复现生产环境，从而难以在本地测试代码。在无服务器环境中，验证前后端交互的集成测试也更难开展。
结语
对于打算构建轻量级应用的公司而言，无服务器计算是一个理想方向。对于由大量服务构成且交互复杂的应用，建议采用由虚拟机承载大型流程的混合式基础设施；在这种情况下，仅将无服务器容器用于短时任务。也可考虑无服务器边缘函数，它们通过在本地处理数据来最大限度降低延迟，同时不会给中心服务器带来过多负载。
请注意，无服务器计算的能力仍在不断发展与演进。例如，可以采用多云策略来构建无服务器应用，即使用多家云提供商的服务来搭建同一个无服务器应用。还出现了更多改进以确保无服务器函数“零冷启动”，如 Cloudflare Workers 的实践。
感谢您的阅读。若想进一步了解无服务器计算并提升相关技能，欢迎查看以下 DataCamp 资源：
如果想要更短的阅读内容，请查看我们的博客文章，获取适合各个水平的项目灵感。
无论是出于高昂的维护成本，还是对专业人力的需求，维护物理或虚拟服务器都并非易事。无服务器计算通过提供一种经济实惠的方式，让开发人员在云端构建并运行应用，从而解决了这些问题。
本文将回顾无服务器计算、其应用场景，以及它对开发者和企业的益处。这个话题之所以重要，是因为无服务器计算的市场规模在 2022 年已超过 900 万美元，并预计在未来十年再增长 25%。让我们开始吧。
定义与概览
假设您家中的水电费不是按固定的月度估算收费，而是根据实际用量计费。无服务器计算的原理与此类似：云提供商按使用量为您分配基础设施资源，让您无需担心服务器维护，就能构建和运行应用程序。
与传统云计算需要部署物理或虚拟服务器、存储和网络设备不同，在无服务器计算中，云提供商负责管理基础设施，并在您的应用进行扩缩时自动为您分配资源。换言之，无服务器计算将服务器从开发者的视野中抽象出来，使其能够更专注于构建应用本身，而不必操心应用所托管的基础设施。
想象一下，您的应用平时每日有 100 到 200 名用户。若第二天用户数突然飙升至 1,000,000，平台会自动扩展资源以满足需求。传统云计算难以做到这一点，因为服务器会因流量激增而出现停机，如果存储不足，还需要采购更大的存储，这将耗费时间。
关键特性
在了解将无服务器计算与其他传统云模型区分开的关键特性之前，先来看一些无服务器计算中的关键术语。
事件驱动的执行
事件驱动的执行也称为函数即服务（FaaS），无服务器应用被拆分为相互独立的无服务器函数，这些函数由特定事件触发，如 HTTP 请求、数据库变更、消息队列或文件上传等来源。
假设您有一个无服务器应用，会在图片上传到 Amazon S3 存储桶时自动处理。用户上传图片文件后，会触发某个函数来处理图片，并将其保存到另一个 Amazon S3 存储桶。这样一来，函数只在需要时运行，使系统高效且具成本效益。
以文件上传为例的事件驱动执行。图片作者自制
自动伸缩
自动伸缩是指根据需求或工作负载的增加来分配计算资源。这是无服务器计算的关键特性之一，使其高效且具适应性：当工作负载或需求较低时避免资源浪费，而在高需求时避免出现停机。
例如，您的应用遇到流量激增。平台不会因高流量导致服务器宕机，而是会自动提供额外实例来处理增加的工作负载。同样，当流量较低时，平台会缩减资源以降低成本。整个过程无需人工干预，确保应用在不同场景下既经济又响应迅速。
按用量付费
无服务器平台按实际使用的资源向用户收费，而不是按预分配的资源计费。与传统云模型可能出现的“资源分配但未充分使用”不同，在无服务器平台中，您只为实际使用的计算时间买单。费用还会精确到调用次数或函数执行时长，确保按您实际使用的资源精准计费。
例如，如果您的应用在某个月内为用户处理了 100 张图片，那么您无需为 24/7 的服务器使用付费，而只需为处理这 100 张图片所消耗的计算时间付费。
服务器管理抽象
这同样是无服务器计算的一项关键特性，开发人员和企业无需关心服务器的部署、扩缩与维护。这样可以将精力集中在核心业务问题上，而把服务器维护交由云提供商处理。
并发管理
无服务器平台可以同时执行多个函数。与传统方法相比，这让其更快速、更高效。比如，用户要在平台上上传图片，而无服务器提供商的默认并发上限为 100，那么超出并发上限的请求将被排队，等待下一次函数执行。
无服务器计算的优势
成本效率
与传统云计算需要专用服务器、且即便服务器空闲也会产生成本不同，无服务器平台采用事件驱动的计费模式。一个贴切的类比是打车与拥有私家车。打车无需操心停车费、燃油费等开销，只需按行驶里程付费。在无服务器计算中，就像打车一样，您只为实际使用的计算资源付费。而传统方式（拥有一辆车）中，即使系统空闲，您也要承担所有计算资源的成本。
不同服务器类型的成本效率对比。来源：Cloudflare
降低运维复杂度
在无服务器计算中，开发人员无需投入时间安装和维护服务器，从而节省大量时间，更专注于构建应用。由于应用由相互独立的云函数构成，可以单独更新某个函数，而不会影响其他函数或整个应用。
更强的可扩展性
这是无服务器平台最重要的优势之一，也是其在中小型组织和初创公司中广受欢迎的原因。无服务器平台让开发人员能在需求上升时自动扩展。对于请求波动较大的函数，无服务器平台会通过增加或减少资源分配来满足请求，确保计算资源得到优化。
更快的上市速度
借助无服务器应用，您可以快速发布应用并立即获得用户反馈。对于初创公司而言，这能显著减少开发时间和所需人力。
可靠性
与托管在专用服务器上的应用不同，无服务器应用可在任意地点运行。与传统云计算相比，这提升了应用性能并降低了延迟。
无服务器架构及其工作原理
无服务器架构是一种无需安装和管理承载应用的基础设施即可构建应用的方式。开发者可以采用两种无服务器模型之一来构建无服务器应用：即后端即服务（BaaS）或函数即服务（FaaS）。
FaaS 与 BaaS 的无服务器云架构。来源：Journal of Cloud Computing
无服务器架构的主要目标是将服务器管理从开发者中抽离。以下是无服务器平台在其基础设施中如何运作的分解说明。
有人可能会问：既然容器架构也将服务器从开发者中抽象出来，那么与无服务器架构是否相同？这在一定程度上成立，但不同于无服务器函数在构建与交付应用时的完全抽象，在使用容器时，一旦应用遭遇高流量，就需要使用如 Kubernetes 等工具来扩展容器。这与 FaaS 的目标相悖——在 FaaS 中，与服务器相关的所有操作都由无服务器平台自动处理。
在容器架构中，容器实例可能会长时间运行，从而产生成本；而在无服务器函数中，您仅为函数运行所花费的时间付费。对于较小的应用，采用无服务器架构有助于将其解耦为平台可作为独立函数运行的部分。
无服务器计算平台
早在 2008 年 Google App Engine 推出之前，Zimki 就曾提供首个“按需付费”的代码执行平台，但后来关闭。在早期阶段，Google App Engine 仅支持 Python，并为包括 SnapChat 在内的应用提供按量计费。约在 2010 年，另一个名为 PiCloud 的平台也为 Python 应用提供了 FaaS 支持。
2014 年，AWS 通过发布 AWS Serverless Application Model（AWS SAM）和 Amazon CloudWatch 等工具，使无服务器模型广为人知。2016 年，Google 推出了其第二款无服务器产品 Google Cloud Functions，微软也发布了 Azure Functions。从那时起，陆续出现了诸多无服务器平台，例如阿里云的函数计算以及 IBM Cloud 的 IBM Cloud Functions。
为消除对虚拟或物理数据库的需求，也出现了无服务器数据库。AWS 提供了基于 MySQL 和 PostgreSQL 的无服务器版本 Amazon Aurora。Azure 提供了 Azure Data Lake，而 Google 提供了 Firestore。
无服务器云平台。来源：Network Interview
实践应用与用例
网站与 API
无服务器计算用于构建网站应用与 REST API。其亮点在于，基于无服务器基础设施构建的应用可根据用户需求自动扩缩，从而提升用户体验。
媒体处理
无服务器架构让媒体处理更加便捷。用户可从不同设备上传大小不一的媒体内容，平台通过一个函数即可满足所有用户的处理需求，而不会降低应用性能。例如，用户可通过 S3 存储桶上传图片，从而触发 AWS Lambda 函数为图片添加水印或缩略图。
聊天机器人
开发者可以利用无服务器架构实现能回应客户问题的聊天机器人，并只为该机器人实际使用的资源付费。例如，Slack 使用无服务器架构来应对机器人请求的波动，以避免因客户需求的日常起伏而造成带宽闲置。
Webhooks
您可以通过无服务器平台与 SaaS 供应商进行交互，方式是使用一个 webhook 的 HTTP 端点来接收通知并执行任务。这样构建的 webhook 具有维护量低、成本低且可自动扩展的优势。
物联网（IoT）
可口可乐在其售货机 Freestyle 上采用无服务器架构，让顾客可以下单、支付并接收支付通知。可口可乐称，他们运营售货机的年成本曾约为 13,000 美元，采用无服务器架构后降至每年 4,500 美元。
数据处理
美国职业棒球大联盟高级媒体（MLBAM）使用无服务器架构构建了其产品 Statcast，为用户提供准确、实时的体育数据指标。它利用无服务器计算处理数据并为用户提供棒球比赛的洞见。
事件驱动的应用
无服务器架构可用于事件驱动的应用，即当事件或状态发生变化时，会触发某项服务。可以使用无服务器平台监测数据库变更，并将变更与质量标准进行比对。
无服务器边缘计算
由于数据需要长距离传输，应用从中心化服务器处理请求和分发内容时会产生延迟和瓶颈问题。
无服务器边缘计算通过将计算资源分布到多个地点来缓解这一问题，从而减轻中心服务器的负载。无服务器边缘计算是指将运行无服务器函数的计算资源部署在更靠近终端用户（边缘）的位置。这使无服务器应用能在更多设备上运行，降低拥塞与延迟。
在无服务器边缘计算中，基础设施可针对每台设备提供支持，使其无需将数据回传中心位置处理，也能执行复杂任务。以下是一些利用无服务器边缘函数优化用户体验的用例：
挑战与注意事项
尽管无服务器计算带来了诸多益处，但也存在以下一些不足。
结语
对于打算构建轻量级应用的公司而言，无服务器计算是一个理想方向。对于由大量服务构成且交互复杂的应用，建议采用由虚拟机承载大型流程的混合式基础设施；在这种情况下，仅将无服务器容器用于短时任务。也可考虑无服务器边缘函数，它们通过在本地处理数据来最大限度降低延迟，同时不会给中心服务器带来过多负载。
请注意，无服务器计算的能力仍在不断发展与演进。例如，可以采用多云策略来构建无服务器应用，即使用多家云提供商的服务来搭建同一个无服务器应用。还出现了更多改进以确保无服务器函数“零冷启动”，如 Cloudflare Workers 的实践。
感谢您的阅读。若想进一步了解无服务器计算并提升相关技能，欢迎查看以下 DataCamp 资源：
如果想要更短的阅读内容，请查看我们的博客文章，获取适合各个水平的项目灵感。