AWS Elastic Beanstalk
开发人员指南
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

AWS Elastic Beanstalk 工作线程环境

如果您的应用程序执行的操作或工作流需要较长的时间才能完成,则可将这些任务卸载到专用的工作线程环境。确保您的应用程序能够在负载下保持响应的常见方法是,将 Web 应用程序前端与执行阻止操作的过程分离开。

长时间运行的任务是指大大增加完成请求所需的时间的操作,例如,处理图像或视频、发送电子邮件或生成 ZIP 存档。这些操作可能只需花费 1 秒或 2 秒的时间即可完成,但对于要在 500 毫秒内完成的 Web 请求来说,几秒的延迟时间也是非常长的。

一种选择是在本地生成工作进程,返回成功值并异步处理任务。如果您的实例能够与其收到的所有任务保持同步,此选择便有效。不过,在高负载下,实例会填满后台任务并且不会响应优先级更高的请求。如果单个用户能够生成多个任务,负载增加可能不会对应用户增加,这会导致难以有效地向外扩展 Web 服务器。

要避免在本地运行长时间运行的任务,您可使用适用于编程语言的 AWS 开发工具包来将这些任务发送到一个 Amazon Simple Queue Service (Amazon SQS) 队列,并运行在一组单独的实例上执行这些任务的过程。工作线程实例仅在能够运行项目时从队列中提取项目,并阻止项目将实例填满。

Elastic Beanstalk 通过管理 Amazon SQS 队列并在每个实例上运行守护程序进程 (从队列中进行读取) 来简化此过程。当守护程序从队列中提取项目时,它会将 HTTP POST 请求本地发送到端口 80 上的 http://localhost/ (正文中包含队列消息的内容)。您的应用程序只需执行长时间运行的任务来响应 POST 请求。可以配置守护程序以发布到其他路径,使用 application/JSON 之外的 MIME 类型,连接到现有队列或自定义连接、超时和重试。

Elastic Beanstalk 工作线程环境 Amazon SQS 消息处理

利用定期任务,您还可以将工作线程守护程序配置为根据 cron 计划对消息进行排队。每个定期任务均可向不同的路径发送 POST 请求。通过在定义每个任务的计划和路径的源代码中包含 YAML 文件来启用定期任务。

注意

Windows Server 平台上的 .NET 不支持工作线程环境。

工作线程环境 SQS 守护程序

工作线程环境运行 Elastic Beanstalk 提供的守护程序进程。此守护程序将定期更新以添加功能和修复 Bug。要获取最新版本的守护程序,请更新到最新的平台版本

功能

发行日期

描述

增强型运行状况报告

2015 年 8 月 11 日

更详细、准确地监控环境运行状况。

定期任务

2015 年 2 月 17 日

在应用程序源代码中运行您在 cron.yaml 文件中配置的 cron 作业。

死信队列

2014 年 5 月 27 日

将失败的作业发送到死信队列以进行故障排除。

已将默认可见性超时从 30 秒更改为 300 秒。

当工作线程环境中的应用程序返回 200 OK 响应以确认其已收到并成功处理了请求时,守护程序将向 Amazon SQS 队列发送 DeleteMessage 调用以便从队列中删除消息。如果应用程序返回 200 OK 之外的任何其他响应,则 Elastic Beanstalk 将会等待,然后在经过配置的 ErrorVisibilityTimeout 时间段后将消息放回到队列中。如果没有响应,则 Elastic Beanstalk 将会等待,在经过 InactivityTimeout 时间段后将消息放回到队列中,以便在处理期间可以对消息进行另一次尝试。

注意

Amazon SQS 队列的属性 (消息顺序、至少一次的传递和消息采样) 会影响您设计用于工作线程环境的 Web 应用程序的方式。有关更多信息,请参阅 Amazon Simple Queue Service 开发人员指南中的分布式队列的属性

Amazon SQS 会自动删除在队列中存在时间超过所配置的 RetentionPeriod 的消息。

守护程序将设置以下 HTTP 标头。

HTTP 标头

名称

用户代理

aws-sqsd

aws-sqsd/1.11

X-Aws-Sqsd-Msgid

SQS 消息 ID,用于检测消息风暴 (异常多的新消息).

X-Aws-Sqsd-Queue

SQS 队列的名称.

X-Aws-Sqsd-First-Received-At

采用 ISO 8601 格式的 UTC 时间 (当首次收到消息时)。

X-Aws-Sqsd-Receive-Count

SQS 消息接收计数.

X-Aws-Sqsd-Attr-message-attribute-name

分配给正在处理的消息的自定义消息属性。message-attribute-name 是实际消息属性名称。所有字符串和数字消息属性都将添加到标头。二进制属性已被放弃且未包含在标头中。

Content-Type

Mime 类型配置;默认情况下为 application/json

死信队列

Elastic Beanstalk 工作线程环境支持 Amazon Simple Queue Service (Amazon SQS) 死信队列。死信队列是其他 (源) 队列将因为某种原因而无法成功处理的消息发送到其中的队列。使用死信队列的主要好处是能够放弃和隔离未成功处理的消息。然后,您可以分析发送到死信队列的任何消息,以尝试确定它们未成功处理的原因。

如果您在创建工作线程环境层时指定一个自动生成的 Amazon SQS 队列,则默认情况下将为该工作线程环境启用死信队列。如果您为工作线程环境选择现有的 SQS 队列,则必须使用 SQS 单独配置死信队列。有关如何使用 SQS 配置死信队列的信息,请参阅使用 Amazon SQS 死信队列

您不能禁用死信队列。无法交付的消息最终总会发送到死信队列。但是,您可以通过将 MaxRetries 选项设置为最大有效值 100 来有效禁用此功能。

注意

Elastic Beanstalk MaxRetries 选项等效于 SQS MaxReceiveCount 选项。如果您的工作线程环境不使用自动生成的 SQS 队列,请使用 SQS 中的 MaxReceiveCount 选项来有效禁用死信队列。有关更多信息,请参阅使用 Amazon SQS 死信队列

有关 SQS 消息的生命周期的更多信息,请转到消息生命周期

定期任务

您可以在源包中名为 cron.yaml 的文件中定义定期任务,以便定期自动将作业添加到工作线程环境的队列中。

例如,以下 cron.yaml 文件将创建两个定期任务,一个定期任务每 12 小时运行一次,另一个定期任务在每天晚上 11 点 (UTC 时间) 运行。

例 cron.yaml

version: 1 cron: - name: "backup-job" url: "/backup" schedule: "0 */12 * * *" - name: "audit" url: "/audit" schedule: "0 23 * * *"

对于每个任务,name 必须是唯一的。URL 是为触发作业而将 POST 请求发送到的路径。计划是一个用于确定任务运行时间的 CRON 表达式

当任务运行时,守护程序会向环境的 SQS 队列发送一条消息,其标头指示需要执行的作业。环境中的任何实例均可选择消息和处理作业。

Elastic Beanstalk 使用领导选择来确定工作线程环境中的哪个实例对定期任务进行排队。每个实例均尝试通过对 Amazon DynamoDB 表进行写入来变为领导。第一个获得成功的实例将成为领导,并且必须继续对表进行写入来维护领导状态。如果领导中断服务,则另一个实例将迅速成为领导。

对于定期任务,工作线程守护程序将另外设置以下领导。

HTTP 标头

名称

X-Aws-Sqsd-Taskname

对于定期任务,为要执行的任务的名称。

X-Aws-Sqsd-Scheduled-At

为定期任务安排的时间

X-Aws-Sqsd-Sender-Id

消息发送者的 AWS 账号

为工作线程环境层中的自动扩展使用 Amazon CloudWatch

Amazon EC2 Auto Scaling 和 CloudWatch 一起监控在工作线程环境中运行的实例的 CPU 利用率。您对 CPU 容量配置的自动扩展限制将决定 Auto Scaling 组运行多少个实例来相应管理 Amazon SQS 队列中的消息吞吐量。每个 EC2 实例都会将其 CPU 使用率指标发布到 CloudWatch。Amazon EC2 Auto Scaling 从 CloudWatch 中检索工作线程环境中所有实例的平均 CPU 利用率。您需要配置上限和下限阈值,以及要根据 CPU 容量添加或终止的实例的数量。当 Amazon EC2 Auto Scaling 检测到已达到 CPU 容量的指定上限时,Elastic Beanstalk 会在工作线程环境中创建新实例。当 CPU 负载降到阈值之下时,将删除实例。

注意

实例被终止时还未处理的消息将返回队列中,可由仍在运行的实例中的其他守护程序进行处理。

您也可以根据需要使用 AWS 管理控制台、CLI 或选项文件设置其他 CloudWatch 警报。有关更多信息,请参阅配合使用 Elastic Beanstalk 和 Amazon CloudWatch使用步进扩展策略创建 Auto Scaling 组

配置工作线程环境

您可以通过编辑环境管理控制台配置页面上的工作线程配置卡来管理工作线程环境的配置。

Elastic Beanstalk 工作线程详细信息配置页面

注意

您可以配置发布工作线程队列消息的 URL 路径,但不能配置 IP 端口。Elastic Beanstalk 始终在端口 80 上发布工作线程队列消息。工作线程环境应用程序或其代理必须侦听端口 80。

配置工作线程守护程序

  1. 打开 Elastic Beanstalk 控制台

  2. 导航到您的环境的管理页

  3. 选择 Configuration

  4. 选择 Worker Configuration

Worker Details (工作线程详细信息) 页包含以下选项:

  • Worker queue (工作线程队列) - 指定守护程序从中读取消息的 Amazon SQS 队列。如果您有现有队列,可以选择现有队列。如果您选择 Autogenerated queue (自动生成的队列),Elastic Beanstalk 将创建新 Amazon SQS 队列和相应的 Worker queue URL (工作线程队列 URL)

  • 工作线程队列 URL – 如果您选择现有工作线程队列,则此设置将显示与该 Amazon SQS 队列关联的 URL。

  • HTTP path (HTTP 路径) - 指定将从 Amazon SQS 队列接收数据的应用程序的相对路径。该数据将插入到 HTTP POST 消息的消息正文中。默认值为 /

  • MIME type (MIME 类型) - 指示 HTTP POST 消息使用的 MIME 类型。默认值为 application/json。但是,因为您可以创建并指定您自己的 MIME 类型,所以任何值都是有效的。

  • Max retries (最大重试次数) - 指定 Elastic Beanstalk 在将消息发送到死信队列之前尝试向 Amazon SQS 队列发送该消息的最大次数。默认值是 10。可以指定 1100

  • HTTP 连接 – 指定守护程序可与 Amazon EC2 实例中的任何应用程序建立的最大并发连接数量。默认值为 50。可以指定 1100

  • Connection timeout (连接超时) - 指定等待与应用程序成功建立连接的时间 (以秒为单位)。默认值是 5。可以指定 160 秒。

  • Inactivity timeout (不活动超时) - 指示等待与应用程序的现有连接传回响应的时间 (以秒为单位)。默认值是 180。可以指定 136000 秒。

  • Visibility timeout (可见性超时) - 指示从 Amazon SQS 队列传入的消息被锁定以进行处理的时间 (以秒为单位)。配置的时间量过后,会再次使消息在队列中可见,以供其他守护程序读取。选择一个值,该值大于应用程序处理消息所需的预期值,最多为 43200 秒。

  • Error visibility timeout - 指示在处理尝试由于显式错误而失败后,Elastic Beanstalk 将消息返回到 Amazon SQS 队列之前经过的时长 (以秒为单位)。可以指定 043200 秒。

  • 保留周期 – 指示消息有效并将进行有效处理的时间 (以秒为单位)。默认值是 345600。可以指定 601209600 秒。

如果您使用现有的 Amazon SQS 队列,则您在创建工作线程环境时配置的设置可能与您在 Amazon SQS 中直接配置的设置冲突。例如,如果您在配置工作线程环境时所用的 RetentionPeriod 值高于在 Amazon SQS 中设置的 MessageRetentionPeriod 值,则 Amazon SQS 将在消息存在时间超过 MessageRetentionPeriod 时删除该消息。

反过来,如果您在工作线程环境设置中配置的 RetentionPeriod 值低于在 Amazon SQS 中设置的 MessageRetentionPeriod 值,则守护程序将先于 Amazon SQS 删除该消息。对于 VisibilityTimeout,您在工作线程环境设置中为守护程序配置的值将覆盖 Amazon SQS VisibilityTimeout 设置。请通过比较 Elastic Beanstalk 设置与 Amazon SQS 设置,确保合理地删除消息。