将聚合器和快餐餐厅与亚马逊云科技无服务器架构集成

在这篇文章中，您将学习如何使用亚马逊云科技无服务器技术，例如 Amazon EventBridge 和 Amazon Lambda，在快餐餐厅 (QSR) 与在线订购和送餐聚合商之间建立集成。这些聚合商已成为 QSR 的一种选择，以扩大其消费者基础，从而为他们提供了帮助其发展业务的交付选项。

QSR 概述

QSR 优先考虑快速便捷的服务，提供简化的菜单。为了满足不断变化的消费者期望，QSR 可以使用与第三方聚合器的 API 集成。这种技术协同作用使 QSR 能够扩展其能力，引入多种付款方式并整合送货服务。这些功能已成为该餐厅细分市场的标准配置。

在幕后，这些 API 用于协调聚合器与 QSR 之间的交互，同时提供一致的订购和交付体验。

QSR 的业务目标是：

提供一致的订购和交付体验
提供个性化菜单项
留住回头客
减少因缺乏配送个性化选项而导致的第三方配送取消

这篇文章从一个简单的架构开始，并添加了解决架构挑战的组件。

架构

作为解决方案架构师，一家蓬勃发展的当地餐饮企业联系了您，他们正在寻求技术解决方案来推动其扩张。您的任务是设计一个符合其技术要求、简化操作和增强客户体验的优秀集成架构。

这种集成的核心是 Amazon API Gateway，它接受来自各种配送聚合器的传入订单。API Gateway 成为前门，将 QSR 与终端客户连接起来，形成简化的动态订单处理系统。

驱动这种集成的后端是 Lambda 函数。这些函数验证订单并安全地与交付聚合器通信。Lambda 函数可以按需动态扩展，并确保优秀的资源使用率和成本效益。

下单工作流程

以下步骤概述了 API Gateway 和 Lambda 函数之间的无服务器集成，如下图所示：

客户可以通过送餐聚合器或企业自己的订购系统下订单。
订单请求将发送到 API Gateway。

该架构适用于小型和简单的集成。要扩展此架构以应对高流量，请使用异步集成来减少 API 和 Lambda 函数之间的耦合。

订单传送工作流程

以下步骤概述了无服务器集成，其中 API Gateway 通过 Amazon EventBridge 作为事件路由服务连接到 Lambda 函数，如下图所示：

API Gateway 接收订单请求。
API Gateway 将客户的订单请求路由到 EventBridge 总线进行处理。

EventBridge 将事件（例如订单状态更改）路由到 Lambda 函数，确保服务中断期间的灵活性。这消除了手动错误处理，并保持 QSR 和聚合器同步。

EventBridge 提供以下基本功能：

EventBridge 接收由各种操作触发的事件，例如新订单或菜单更新。
它将事件路由到相关的 Lambda 函数，启动相应的操作。
EventBridge 支持事件重放，允许从 Lambda 部署问题或函数故障中恢复。此功能通过存储服务中断期间的事件来实现业务连续性，并在系统稳定时自动恢复处理。

为了维护订单历史记录并实现快速数据检索，系统需要一个高性能的数据库。Amazon DynamoDB 是一项无服务器 NoSQL 数据库服务，它通过高效存储和管理订单信息和元数据来满足这些要求。订单处理 Lambda 函数与 DynamoDB 交互以保存订单详情。这种方法允许其他后端进程对存储的数据进行异步处理。该数据库解决方案提供了处理不断增长的订单量所需的可扩展性和响应能力，同时保持稳定的性能，将订单接收与后续处理步骤分开。

订单处理工作流程

以下步骤概述了订单处理工作流程，如下图所示：

订单处理 Lambda 函数验证订单并使用新的订单详细信息更新 DynamoDB 数据库。
该函数将错误事件发布到 EventBridge，从而为错误处理和重试逻辑启用下游处理。这些事件可以触发更多旨在管理特定错误场景和恢复过程的 Lambda 函数。

EventBridge 实现模式：单总线或双总线方法

EventBridge 为事件总线拓扑提供了多种方法。架构师可以选择根据订单状态使用具有不同事件模式的单一事件总线，也可以选择实施多总线策略。

单总线方法对所有事件使用一个事件总线，其路由规则模式基于订单状态。例如，规则将匹配特定状态（例如"新"或"已处理"）以触发相应的 Lambda 函数。尽管它在架构上很简单，但它需要仔细管理事件架构以避免潜在的错误。但是，单总线方法需要谨慎处理以防止递归处理，在这种处理中，消息会以无限循环方式触发更多消息。

或者，多总线方法将订单下放和处理分隔在不同的总线上，可以有效防止循环和递归问题。尽管设置稍微复杂一些，但这种方法可以更好地分离交易。

EventBridge 可以使用 API 目标选项直接定位外部服务，从而无需使用 Lambda 函数进行第三方集成。

协调订单处理

在复杂的 QSR 订单处理系统中，管理多个相互依赖的 Lambda 函数可能会变得具有挑战性，可能会导致代码复杂和架构难以维护。为了解决这个问题，可以引入 Amazon Step Functions 作为编排层。

Step Functions 充当 QSR 订单流所需的业务逻辑的中心协调器。该服务管理订单处理工作流程中的活动进度，从而有效地协调厨房准备和交付物流等任务。定义和管理复杂的工作流程允许 Step Functions 优化 QSR 操作的整体效率，提供结构化且适应性强的解决方案。这种协调增强了餐厅处理动态处理的能力，实现了与送货服务的顺畅和响应式集成，同时简化了底层架构。

以下步骤概述了订单处理的编排，如下图所示：

订单处理触发相应的 Lambda 函数，该函数更新 DynamoDB 数据库中的订单数据。
更新后的顺序适用于后续的 Lambda 函数，这些函数处理由更多 Lambda 函数执行的更多业务逻辑。

在多总线 EventBridge 架构中，流程如下所示：

第一条 EventBridge 总线接收初始订单事件，并将其路由到 Step Functions 工作流程。
Step Functions 工作流程协调订单处理，协调各种任务和检查。
完成后，Step Functions 工作流程会向第二条 EventBridge 总线发出一个包含处理结果的事件。
根据 Step Functions 工作流程的输出，第二条总线包含一条规则，该规则将聚合器 API 作为 API 目的地触发。

用户参与工作流程

当客户下订单时，必须有办法在订单准备就绪时确认或通知他们。为此，您可以使用亚马逊云科技最终用户消息服务向客户推送订单完成通知和新优惠。

通过分析客户数据和个人偏好，可以使用 Amazon Personalize 来提供个性化推荐和促销。

Amazon Personalize 可以分析历史订单数据，通过个性化推荐来增强用户体验，例如优秀配送时间、首选菜单以及基于个人订购模式的定制促销。

结论

这篇文章展示了如何使用亚马逊云科技无服务器服务来构建订单处理平台，而不必担心管理底层基础设施。包括的无服务器服务包括 Amazon API Gateway、Amazon Lambda、Amazon EventBridge、Amazon Step Functions、亚马逊云科技最终用户消息和 Amazon Personalize。

这篇文章简要介绍了事件驱动架构，重点是内部订购系统与交付聚合器和第三方订购平台的集成。这可以帮助扩大用户群，并且一直是许多 QSR 增长的关键因素。提高订购、外卖和配送体验的效率可以转化为收入的增长、放弃订单的减少，以及经常性客户留存率和品牌忠诚度的提高。

如需更多无服务器学习资源，请访问 Serverless Land。要查找更多模式，请直接访问无服务器模式集合。