简介

初级 | 10 分钟

无服务器 - 深入探究介绍基础概念、参考架构、最佳实践和动手实验活动,以帮助您开始构建无服务器应用程序。如果您第一次接触无服务器,从此处开始非常适合。对于经验丰富的无服务器构建者,我们提供更高级主题的资源和链接。

什么是无服务器计算?

无服务器计算让您可以在不考虑服务器的情况下构建并运行应用程序和服务。它消除了基础设施管理任务,例如服务器或集群配置、修补、操作系统维护和容量预置。您能够为几乎任何类型的应用程序或后端服务构建无服务器应用程序,并且运行和扩展具有高可用性的应用程序所需的所有操作都可由您负责。

无服务器应用程序是由事件驱动的,并通过与技术无关的 API 或消息收发进行松散耦合。为了响应事件而执行事件驱动型代码,例如状态更改或终端节点请求。事件驱动型架构将代码与状态解耦。松散耦合组件之间的集成通常使用消息收发异步完成。

AWS Lambda 是非常适合事件驱动型架构的无服务器计算服务。Lambda 函数由事件通过 Amazon Simple Queue Service (SQS)、Amazon Simple Notification Service (SNS) 和 Amazon Kinesis 等集成的事件源触发,这些事件源可用于创建异步集成。Lambda 函数将使用和生成事件,其他服务随后可以使用这些事件。

无服务器架构模式将 Lambda 与同为无服务器的其他托管服务结合使用。除了消息和流传输服务之外,无服务器架构还使用适用于 API 管理的 Amazon API Gateway、适用于数据存储的 Amazon DynamoDB 和适用于编排的 AWS Step Functions 等托管服务。无服务器平台还包括一组开发人员工具,其中包括无服务器应用程序模型(或 SAM),可以帮助简化您的 Lambda 函数和无服务器应用程序的部署和测试。

为什么使用无服务器计算?

无服务器管理:无需预置或维护任何服务器。无需安装、维护或管理任何软件或运行时。

灵活扩展:您的应用程序可自动扩展,或通过切换占用资源(如吞吐量、内存)的单位数(而不是切换单个服务器的单位数)来调整容量,从而实现扩展。

按价值付费:为一致的吞吐量或执行持续时间(而不是服务器单元)付费。

自动化的高可用性:无服务器应用程序提供内置可用性和容错功能。您无需构建这些功能,因为运行此应用程序的服务在默认情况下会提供这些功能。

核心无服务器服务

无服务器应用程序通常使用完全托管的服务作为跨计算、数据、消息收发和集成、流传输以及用户管理和身份层的构建块来构建。AWS Lambda、API Gateway、SQS、SNS、EventBridge 或 Step Functions 等服务是大多数应用程序的核心,受 DynamoDB、S3 或 Kinesis 之类的服务支持。

类别
服务
说明
计算 AWS Lambda AWS Lambda 让您可以在托管平台上运行无状态的无服务器应用程序,
该平台支持微服务架构、部署和管理
函数层的执行。
API 代理 API Gateway Amazon API Gateway 是一项完全托管型服务,可让开发人员轻松地
在任何规模下创建、发布、维护、监控和保护 API。它
API 管理提供综合平台。使用 API Gateway,您可以处理
数十万个并发的 API 调用,并且可处理流量管理、
授权和访问控制、监控和 API 版本管理。
消息收发和集成 SNS Amazon SNS 是完全托管的消息发布/订阅服务,可轻松
分离和扩展微服务、分布式系统和无服务器应用程序。
SQS Amazon SQS 是完全托管的消息队列服务,可轻松
分离和扩展微服务、分布式系统和无服务器应用程序。
EventBridge Amazon EventBridge 是无服务器事件总线,可使用您自己的应用程序数据将应用程序
连接在一起,集成软件即服务
(SaaS) 应用程序和 AWS 服务。
编排 Step Functions
AWS Step Functions 让您能够使用可视化工作流程图轻松
协调分布式应用程序和微服务的组件。

开始构建!

下面是几个可以帮助您了解我们的核心无服务器服务的资源。

运行无服务器的“Hello, World!”

使用 AWS Lambda 控制台创建“Hello World”Lambda 函数,并了解在不预置或管理服务器的情况下运行代码的基础知识。

开始教程 >>

从上传的图像创建缩略图

创建一个 Lambda 函数,Amazon S3 在每次将图像文件上传到 S3 存储桶并自动创建该图像的缩略图时都会调用此函数。

开始教程 >>

使用 AWS Lambda 构建您的第一个应用程序
创建简单的微服务

使用 Lambda 控制台创建一个 Lambda 函数和一个 Amazon API Gateway 终端节点来触发该函数。

开始教程 >>

创建无服务器工作流

了解如何使用 AWS Step Functions 设计和运行无服务器工作流,以协调多个 AWS Lambda 函数。

开始教程 >>

基础知识

中级 | 20 分钟

在此部分中,您将了解事件驱动型设计、可扩展无服务器应用程序后的核心原则。

事件驱动型设计

事件驱动型架构使用事件进行触发和在解耦的服务之间进行通信。事件指的是状态的改变或更新,例如在电子商务网站上的购物车中放置一个商品。事件可以包含状态(例如,购买的商品、其价格和收货地址),也可以是标识符(例如,订单已发货的通知)。

事件驱动型架构有三个主要组成部分:事件生成器、事件路由器和事件使用者。生成器将事件发布至路由器,由路由器对事件进行筛选并推送给使用者。生成器服务和使用者服务将会解耦,从而使它们能够独立扩展、更新和部署。

要了解为什么需要事件驱动型架构,我们来了解一下同步 API 调用。

Serverless deep dive synchronous api call

客户通过进行 HTTP API 调用利用您的微服务。Amazon API Gateway 托管 RESTful HTTP 请求和对客户的响应。AWS Lambda 包含业务逻辑,以处理传入的 API 调用和利用 DynamoDB 作为永久存储。

当进行同步调用时,API Gateway 预计会立即响应并产生 30 秒的超时。使用同步事件源时,如果来自 Lambda 的响应需要超过 30 秒,则您要负责编写重试和错误处理代码。因此,客户端下游任何组件(如 DynamoDB 中的读/写容量单元)发生的任何错误或扩展问题都将被推送回客户端以进行前端代码处理。通过使用异步模式和对这些组件进行解耦,您可以构建更强大、高度可扩展的系统。

发送扇出事件通知

了解如何实施扇出消息收发场景,在此场景中,消息会被“推送”给多个订阅者,无需通过定期检查或轮询获取更新,且系统能够按订阅者并行异步处理消息。

开始教程 >>

将 Amazon EventBridge 集成到您的无服务器应用程序中

了解如何在 AWS Lambda 中创建事件生成器和使用者,并创建路由事件的规则。

开始教程 >>

迁移到事件驱动型架构
触发器和事件源

事件触发 Lambda 函数。然后,它们执行代码以响应触发器,并且还可以生成自己的事件。有很多选项可用于触发 Lambda 函数,并且您可以灵活地创建符合您特定需求的自定义事件源。

事件源的主要类型包括:

  • 数据存储(例如 Amazon S3、Amazon DynamoDB 或 Amazon Kinesis)可以触发 Lambda 函数。如果它存储您希望跟踪其更改的数据,您可以将它用作事件源。
  • 发送事件的终端节点可以调用 Lambda。例如,当您要求 Alexa 执行某项操作时,她将发送事件以触发 Lambda 函数。
  • 消息收发服务(例如 Amazon SQS 或 Amazon SNS)也可以作为事件源。例如,当您推送某项内容到 SNS 主题时,它可能会触发 Lambda 函数。
  • 存储库内发生某些操作时,例如提交代码到您的 AWS CodeCommit 存储库时,它可能会触发 Lambda 函数以开始您的 CI/CD 构建过程等。
Serverless deep dive event source trigger
调用 AWS Lambda 函数

通过我们的开发人员指南了解有关调用 AWS Lambda 函数的一切信息。

请参阅开发人员指南 >>

在您的无服务器应用程序中选择事件、队列、主题和流
参考架构

在本部分中,您将看到一套参考架构,其中包含常见的无服务器应用程序使用案例。

  • RESTful 微服务

    无服务器技术构建于高可用性的容错基础设施之上,使您可以为任务关键型工作负载构建可靠的服务。AWS 无服务器核心服务与数十种其他 AWS 服务紧密集成,并从丰富的 AWS 生态系统和第三方合作伙伴工具中获益。使用此生态系统,您可以精简构建过程、自动化任务、编排服务和依赖项,并监控您的微服务。使用 AWS 无服务器服务,您只需按实际使用量付费。这使您能够提高业务的使用率,并在使用率较低时降低成本。上述所有功能使无服务器技术成为构建弹性微服务的理想技术。

    RESTful 微服务架构示例

    Serverless deep dive restful microservice architecture

    客户通过进行 HTTP API 调用利用您的微服务。理想情况下,您的消费者应该与您的 API 有一个紧密绑定的服务合约,以实现对服务水平和变更控制的一致期望。

    Amazon API Gateway 托管 RESTful HTTP 请求和对客户的响应。在此情景下,API 网关提供内置的授权、限流、安全性、容错能力、请求/响应映射和性能优化。

    AWS Lambda 包含业务逻辑,以处理传入的 API 调用和利用 DynamoDB 作为永久存储。

    Amazon DynamoDB 永久存储微服务数据,并根据需要进行扩展。由于微服务通常被设计为擅长某一个领域,因此,将定期整合非模式化 NoSQL 数据存储。

  • 图像处理

    图像处理是一个可以通过事件驱动的常见工作负载,需要动态地向上和向下扩展,无服务器技术非常适合它。通常情况下,图像将存储在 Amazon S3 中,从而可以触发 Lambda 函数以进行处理。处理后,Lambda 函数可以将修改过的版本返回另一个 S3 存储桶或 API 网关。

    下图表示您可以使用该解决方案实施指南和随附的 AWS CloudFormation 模板在几分钟内部署的 Serverless Image Handler 架构。

    Serverless deep dive image handler

    AWS Lambda 从您的 Amazon Simple Storage Service (Amazon S3) 存储桶中检索图像,并使用 Sharp 将修改版的图像返回到 Amazon API Gateway 中。该解决方案会生成 Amazon CloudFront 域名,以提供对图像处理程序 API 的缓存访问。

    此外,该解决方案还部署可选的演示用户界面,在该用户界面中,您可以使用您账户中已经存在的图像文件与您的图像处理程序 API 终端节点直接交互。演示 UI 部署在 Amazon S3 存储桶中,使客户能够通过简单的 Web 界面立即开始操作图像。CloudFront 用于限制对该解决方案的网站存储桶内容的访问。

    部署解决方案 >>

  • 流处理

    您可以使用 AWS Lambda 和 Amazon Kinesis 处理实时流数据,从而跟踪应用程序活动、处理事务处理顺序、分析单击数据流、整理数据、生成指标、筛选日志、建立索引、分析社交媒体以及遥测和计量 IoT 设备数据。

    流处理架构示例

    serverless deep dive stream processing

    本图中描述的架构可以使用 AWS CloudFormation 模板创建。模板将执行以下操作:

    • 创建 Kinesis 流
    • 创建名为 -EventData 的 DynamoDB 表
    • 创建 Lambda 函数 1 (-DDBEventProcessor),以从 Kinesis 中接收记录并将记录写入 DynamoDB 表中
    • 创建 IAM 角色和策略,以允许事件处理 Lambda 函数从 Kinesis 流中读取并写入 DynamoDB 表中
    • 创建一个有权将事件与凭证一起放置在 Kinesis 流中以便用户在 API 客户端中使用的 IAM 用户
  • Web 应用程序

    使用 AWS 上的无服务器计算,您可以部署整个 Web 应用程序堆栈,无需管理服务器、预置容量或为闲置的资源付费。此外,您必须牺牲安全性、可靠性或性能。使用无服务器技术构建的 Web 应用程序提供高可用性,并且可以根据需要全局扩展。

    serverless deep dive web application
    1. 此 Web 应用程序的使用者可能集中在一个地理区域,也可能分布在世界各地。利用 Amazon CloudFront 不仅可以通过缓存和最佳源路由为这些使用者提供更好的性能体验,还可以限制对您的后端进行的冗余调用。
    2. Amazon S3 托管 Web 应用程序静态资产,并通过CloudFront 安全地提供。
    3. Amazon Cognito 用户池为您的 Web 应用程序提供用户管理和身份提供商功能。
    4. 在很多情况下,当使用者从 Amazon S3 下载静态内容时,需要发送动态内容或由您的应用程序接收该内容。例如,当用户通过表格提交数据时,Amazon API Gateway 会用作安全终端节点来进行这些调用,并且会返回通过 Web 应用程序显示的响应。
    5. AWS Lambda 函数在 DynamoDB 之上为您的 Web 应用程序提供创建、读取、更新和删除 (CRUD) 操作。
    6. Amazon DynamoDB 可以提供后端 NoSQL 数据存储,以随着您的 Web 应用程序流量弹性扩展。
部署

在微服务架构中进行部署的最佳实践是确保更改不会破坏使用者的服务合约。如果 API 拥有者进行的更改破坏了服务合约且使用者没有为此做好准备,则可能会发生故障。

要了解部署更改的影响,您需要知道哪些使用者在使用您的 API。您可以通过使用 API 密钥收集使用元数据,如果对 API 进行了破坏性的更改,它们也可以作为一种合约形式。

如果客户想要减轻对 API 进行的破坏性更改的影响,他们可以克隆 API 并将客户路由到不同的子域(例如,v2.my-service.com),以确保现有客户不受影响。这种方法允许客户仅将新更改部署到新的 API 服务合约中,但需要权衡利弊。采用此方法的客户需要维护两个版本的 API,将需要处理基础设施管理和预置开销。

部署
客户影响
回滚 事件模型因素
部署速度
一次性 一次性 重新部署旧版本 低并发率的任何事件模型 立即
蓝/绿 事先一次性进行一定程度的生产环境测试 将流量恢复到上一个环境 对处于中等并发工作负载的异步和同步事件模型更有益 进行几分钟到几小时的验证,然后直接发送给客户
Canary/线性 1–10% 典型的初始流量迁移,然后分阶段增加或一次性增加 将 100% 流量恢复到上一次部署 对于高并发工作负载更有益 几分钟到几小时
  • 一次性部署

    一次性部署包括在现有的配置之上进行更改。这种风格的部署优势在于,对关系数据库等数据存储进行后端更改在更改周期中需要的协调事务工作量小得多。虽然这种部署风格的工作量较少,而且几乎不对低并发模型产生任何影响就可以实现,但它增加了回滚风险,并且通常会导致停机。使用此部署模型的示例场景为用户影响最小的部署环境。

    尝试进行一次性部署 >>

  • 蓝/绿部署​

    使用蓝/绿部署​模式,客户会将一部分流量转移到新的真实环境(绿色),同时将旧环境(蓝色)保持温暖,以防系统需要回滚。使用此模式时,最好保持较小的更改,以便能够快速、轻松地完成回滚。蓝/绿部署​旨在减少停机,很多客户用它们进行生产部署。使用 API 网关,您可以轻松定义转移到新的绿色环境的流量百分比,从而使其成为此部署模式的有效工具。

    这种风格的部署特别适合无服务器架构,这些架构都是无状态的,并且与底层基础设施解耦。

    您需要适当的指示器来了解是否需要回滚。作为最佳实践,我们建议客户使用 CloudWatch 高分辨率指标,它们可以以 1 秒的间隔进行监控,并快速捕获下降趋势。与 CloudWatch 警报结合使用时,您可以启用快速回滚。CloudWatch 指标可以在 API 网关、Step Functions、Lambda(包括自定义指标)和 DynamoDB 上捕获。

  • Canary 版本部署

    Canary 版本部署是一种不断增长的方式,让您可以在受控制的环境中利用新版本软件,并支持快速部署周期。Canary 版本部署包括将少量请求部署到新更改中,以分析对您的一小部分用户的影响。

    在 API 网关中使用 Canary 版本部署时,您可以将更改部署到您的后端终端节点(例如 Lambda),同时仍然为使用者维持相同的 API 网关 HTTP 终端节点。此外,您还可以控制路由到新部署的流量百分比,以及受控制的流量切换。Canary 版本部署的实际场景可能是一个新网站。在将所有流量转移到新部署之前,您可以监控一小部分终端用户的点击率。

    Implementing canary deployments of AWS Lambda functions with alias traffic shifting

    了解如何实施 AWS Lambda 函数的 Canary 版本部署。

    阅读博客文章 >>

    逐步部署无服务器应用程序

    AWS SAM 为您的无服务器应用程序提供逐步 Lambda 部署。

    请参阅开发人员指南 >>

其他资源

操作教程
访问无服务器教程的完整清单,并获得更多操作教程。
查看操作教程 >>
AWS 无服务器博客
在 AWS 无服务器博客上阅读有关无服务器的最新资讯。
阅读博客文章 >>
类别深入探究
深入研究特定技术,以充分利用 AWS 云。
查看类别深入探究 >>