亚马逊AWS官方博客

适用于开发人员的无服务器入门：第 3 部分 – 入口

原文链接：

https://aws.amazon.com/blogs/compute/getting-started-with-serverless-for-developers-part-3-the-front-door/

 

本博客文章是适用于开发人员的无服务器入门的第 3 部分，可帮助开发人员从其 IDE 中开始构建无服务器应用程序。在上一篇博客文章中，我介绍了 AWS Lambda 并展示了如何设计函数来为无服务器应用程序运行业务逻辑。

在本博客文章中，您将了解如何通过使用 Amazon API Gateway 创建无服务器应用程序的前门来访问该业务逻辑。您将扩展第 1 部分中的示例无服务器应用程序以处理一个额外的 GitHub Webhook URL。最后，您将了解无服务器应用程序如何通过将业务逻辑与路由逻辑解耦来帮助降低复杂性和减少代码。

无服务器架构使用事件驱动型模型。Lambda 服务运行 Lambda 函数以响应事件。该操作通过指示 Lambda 服务开始运行 Lambda 韩式，被称为调用。Lambda 函数可以直接从众多集成的 AWS 服务（包括 API Gateway）中调用。

第 1 部分中部署的无服务器应用程序在 GitHub 存储库加星号标记时通过 Slack 通知用户。此无服务器应用程序的业务逻辑包含在单个 Lambda 函数中：

一个 GitHub Webhook 被配置为，在存储桶被标记上星号时对 URL 提出 HTTP POST 请求。此过程是一个事件。但是，URL 终端节点在哪里？您如何配置要运行的业务逻辑以响应此请求？

 

认识 Amazon API Gateway

Amazon API Gateway 是一项完全托管的服务，可使开发人员创建几乎能在任何规模下运行的无服务器 API。这些 API 可以被配置为访问应用程序业务逻辑。

之前显示的无服务器应用程序使用 Amazon API Gateway 创建 URL 终端节点。该 URL 终端节点将充当应用程序业务逻辑的前门。当终端节点收到 HTTP POST 请求时，它会调用 Lambda 函数。该系列未来的博客文章将演示如何通过向 API 请求添加身份验证来确保这个前门的安全。

 

路由到业务逻辑

在第 2 部分：业务逻辑中，我展示了传统应用程序架构如何将所有业务和路由逻辑作为单个单元或代码库保存在一起。与此相反，无服务器应用程序使用托管服务将业务逻辑与其他应用程序组件（如路由逻辑）分开。

以经理/工作人员模型为例。通常，经理的角色是接收传入的请求，决定由哪个工作人员完成工作，然后将请求传递给适当的工作人员。工作人员收到经理的请求并执行任务，但不负责决定“大局”。然后，工作人员将已完成的任务返回给经理。

在传统的非服务器应用程序中应用这个相同的模型，工作人员和经理都在业务逻辑中实现。在示例无服务器应用程序中，经理是使用 API Gateway 实现的，后者将请求路由到业务逻辑。业务逻辑在 Lambda 函数中运行：

在无服务器模型中，业务逻辑和路由逻辑是解耦的。当应用程序开始增长时，这种方法的益处即显而易见起来。

举例来说，对应用程序进行扩展，以在对 GitHub 存储桶进行新代码推送时发布 Slack 通知。要在传统应用程序模型中实现这一点，通常需要编辑现有的业务逻辑和路由。在无服务器应用程序中，它的实现方式为：

  1. 创建新的 Lambda 函数以运行新业务逻辑。
  2. 在调用新 Lambda 函数的 API 终端节点上创建新路径。
  3. 配置 GitHub Webhook 以将 POST 请求发送到新的 API 路径。

使用 AWS Serverless Application Model (AWS SAM) 等框架构建的无服务器应用程序可以通过复制模板代码来快速实施此操作。以下步骤对此进行了演示，并解释了如何配置路由逻辑并将其与业务逻辑解耦。

 

开始之前

要部署应用程序的这个阶段，请按照博文 1 中的步骤克隆并部署示例应用程序。示例应用程序的代码可以参见此 GitHub 存储库。

  1. 从克隆的存储库的根目录中运行以下命令：
    cd ./part_3查看 /part_3/template.yaml 文件。这是示例无服务器应用程序的新 AWS SAM 模板。新的 Lambda 函数及其 API 调用事件被添加了注释：
# PushWebhookHandler:
  #   Type: AWS::Serverless::Function
  #   Description: A github webhook handler when a new push is made
  #   Properties:
  #     CodeUri: src_push/
  #     Handler: app.handler
  #     Runtime: nodejs12.x
  #     Timeout: 3
  #     Environment:
  #       Variables:
  #         slackEndpoint: !Ref slackUrl
  #     Events:
  #       HttpApiEvent:
  #         Type: HttpApi
  #         Properties:
  #           Path: /push
  #           Method: POST

这与第一个 Lambda 函数配置相同，但以下两个定义除外：

  • CodeUri 告诉应用程序，业务逻辑位于此函数的单独目录内，称为 /src_push。这包含一个名为 app.js 的文件，其中包含新 Lambda 函数的业务逻辑。
  • API 事件路径使用新路径 /push 创建了新的 API 终端节点。
  1. 通过删除 # 符号取消新 Lambda 函数配置的注释。
  2. 使用以下命令构建和部署应用程序：
sam build
sam deploy --guided --config-file ../samconfig.toml

此命令可引导您进行指导式部署，它需要一些输入参数。如果您已完成第 1 部分 中的步骤，这些参数将被预填充。

3. 部署完成后，将提供以下输出：

现在，有两个 API 终端节点输出。请记下 PushGitHubEndpoint 值。此 URL 是处理代码推送事件的业务逻辑的网关。对此 URL 进行的 POST 请求以及格式正确的有效负载将触发 PushWebhookHandler Lambda 函数运行。这会将消息发布到 Slack Webhook URL。最后一个任务是配置 GitHub 以向此 URL 发送 POST 请求：

4. 按照第 1 部分中的设置 GitHub Webhook 步骤来创建新的 Webhook。

5. 将 PushGitHubEndpoint 粘贴到有效负载 URL 输入中。

6. 选择推送作为单个事件，以触发 Webhook。

 

运行无服务器应用程序

更新后的无服务器应用程序的高层表示如下：

要查看在 GitHub 存储库中运行的应用程序：

    1. 从存储库主页中选择 Add file（添加文件）按钮，然后选择 create new file（创建新文件）。

    1. 为新文件命名，在 name your file（为文件命名）文本输入中输入 push.md，然后选择 commit new file（提交新文件）：


这会将 GitHub 事件发送到无服务器应用程序，然后应用程序将处理事件并将其发送到 Slack Webhook URL。此消息出现在 Slack 频道中，显示已进行新的代码推送：

 

结论

这篇博客文章介绍了如何使用 Amazon API Gateway 创建无服务器应用程序业务逻辑的前门。

您可以看到无服务器技术如何帮助开发人员将路由逻辑与业务逻辑解耦。这有助于降低构建无服务器应用程序时的代码复杂性，并支持无服务器应用程序快速增长。您还扩展了 GitHub Webhook 来处理代码推送事件。

该系列中接下来三篇博客文章将重点介绍构建无服务器应用程序的开发人员工作流。它们将描述如何在本地构建时检查日志、测试和调试代码，以及这与传统应用程序的不同之处。

有关更多的入门内容，请转至 serverlessland.com。