Q54 — AWS SAA-C03 第17章

第 54/89 题 | ← 返回第17章

Q1354. 一家媒体出版公司正在AWS上构建一个应用程序，使用户能够自行打印书籍。该应用程序的前端运行在Docker容器中。订单量波动很大。订单量有时会暂时超过公司图书印刷机的处理能力。订单处理数据量最大可达 4 MB。该公司需要开发一种能够扩展以处理不断涌入的订单的解决方案。哪种方案能够满足这一要求?

正确答案: C. 使用 Amazon SQS 对传入订单进行排队。创建 AWS Lambda 函数来处理订单。使用 AWS Fargate 启动类型将前端应用程序部署到 Amazon ECS 上。

解析

正确答案是 C。使用 Amazon SQS 对传入订单进行排队。创建 AWS Lambda 函数来处理订单。将前端应用程序部署到 Amazon ECS，并使用 AWS Fargate 启动类型。解释:要求如下:处理可变数量的订单（可扩展的解决方案）。处理可能超出打印机吞吐量的订单（将订单接收与处理分离）。订单有效负载最大为 4 MB（考虑消息大小限制）。前端运行在 Docker 容器中（基于容器的部署）。为什么选项 C 正确:Amazon SQS（标准队列）:将订单接收与处理分离:当需求超过打印能力时，订单将被排队。可处理可变负载:根据传入流量自动扩展。原生支持每条消息最大 256 KB（但可以使用 SQS 扩展客户端处理最大 2 GB 的更大有效负载）。4 MB 有效载荷的替代方案:将有效载荷存储在 S3 中，并在 SQS 消息中发送 S3 URL。用于订单处理的 AWS Lambda:无服务器扩展:自动扩展以处理队列中的订单。成本效益高:只需为使用的计算资源付费。基于 Amazon ECS 和 AWS Fargate 的前端:Docker 容器支持:ECS + Fargate 是一套完全托管的容器编排服务。可扩展性强:无需管理 EC2 实例;Fargate 会自动处理扩展。其他选项错误的原因:A. 使用 SQS + Lambda@Edge + Amazon EKS错误:Lambda@Edge 是用于边缘计算（CloudFront CDN），而不是订单处理。Amazon EKS 基于 Kubernetes，对于这种用例来说有点过于复杂（Fargate 更简单）。B. 使用 SQS + Lambda + AWS Fargate（不使用 ECS）错误:AWS Fargate 需要 ECS 或 EKS 来运行容器，它无法直接处理 SQS 消息。Lambda 可以处理 SQS 消息，但前端必须通过 ECS/EKS + Fargate 进行部署。D. 使用 SNS + Lambda@Edge + Amazon EC2错误:SNS 是一种发布/订阅服务，而不是队列——如果没有订阅者准备就绪，订单可能会丢失。Lambda@Edge 不适用于订单处理。EC2 需要手动扩展，这与可扩展解决方案的要求相矛盾。关键考虑因素:SQS 与 SNS:SQS 是一个队列（解耦生产者和消费者，确保消息持久性）。SNS 是一个发布/订阅系统（向多个订阅者广播消息，没有队列）。由于订单必须按顺序处理（或者至少不能丢失），因此 SQS 是正确的选择。处理大型有效载荷（4 MB）:SQS 对每条消息的大小限制为 256 KB，但是:将有效负载存储在 S3 中，并在 SQS 消息中发送 S3 URL。使用 SQS 扩展客户端库可以处理更大的有效负载。前端部署:ECS + Fargate 是无需管理服务器即可使用 Docker 容器的最佳选择。除非需要 Kubernetes 的功能，否则 EKS 是不必要的。EC2 需要手动扩展，这对于可变工作负载来说并不理想。正确架构（选项 C）:前端（Docker 容器）Amazon ECS + Fargate（可扩展的无服务器容器）。亚马逊 SQS 订单（已排队等待处理）。SQS 触发 AWS Lambda 处理订单（自动扩展）。如果有效负载大于 256 KB:则存储到 S3，并在 SQS 消息中发送 S3 URL。结论:选项C是唯一满足所有要求的方案:SQS 用于解耦和可扩展性。Lambda 用于无服务器订单处理。ECS + Fargate 用于可扩展的 Docker 前端。其他选项要么滥用服务（Lambda@Edge、SNS），要么缺乏适当的扩展性（EC2）。