在 亚马逊云科技 上发送和接收 webhook：利用事件通知进行创新

这篇文章由解决方案架构师丹尼尔·维尔乔和首席解决方案架构师贾斯汀·普洛克撰写。

Webhook 通常被称为 反向 AP I 或 推送 API ，它为应用程序提供了一种相互集成和近乎实时地通信的方式。它支持业务和系统事件的集成。

无论你是在构建与客户工作流程集成的软件即服务 (SaaS) 应用程序，还是来自供应商的交易通知，webhooks 在解锁创新、增强用户体验和简化运营方面都起着至关重要的作用。

这篇文章解释了如何在 亚马逊云科技 上使用 webhook 进行构建，并涵盖了两种场景：

• 网络挂钩提供商： 向外部 API 发送网络挂钩的 SaaS 应用程序。
• Webhooks 使用者： 接收具有处理大型有效负载能力的 Webhook 的 API。

它包括高级参考架构，包括注意事项、最佳实践和 代码示例 ，以指导您的实施。

发送网络挂钩

要发送 webhook，您需要生成事件并将其交付给第三方 API。这些事件促进了第三方系统中的更新、工作流程和操作。例如，支付平台（提供商）可以发送付款状态通知，允许电子商务商店（消费者）在确认后发货。

Webhook 提供商的 亚马逊云科技 参考架构

该架构由两项服务组成：

• Webhook 交付： 向使用者指定的外部端点交付 webhook 的应用程序。
• 订阅管理 ：一种管理 API，使消费者能够管理其配置，包括指定要交付的端点以及要订阅的事件。

发送 webhook 的注意事项和最佳实践

在构建用于发送 webhook 的应用程序时，请考虑以下因素：

事件生成： 考虑如何生成事件。此示例使用 亚马逊 Dynam oDB 作为数据源。事件是通过 DynamoDB Streams 的 变更数据捕获生成的， 并发送到亚马逊 Ev entBri d ge Pipes。 然后，您可以使用 输入 转换器简化 DynamoDB 响应格式。

使用 EventBridge，您可以近乎实时地发送事件。如果事件对时间不敏感，则可以批量发送多个事件。这可以通过使用 EventB ridge 调度器以指定频率轮询新事件 来完成。 要从其他数据源生成事件，可以考虑使用类似的方法使用 亚马逊简单存储服务 (S3) 事件 通知 或 Amazon Kinesis。

筛选： 在 事件路由到目标目的地之前 ，EventBridge 管道支持 按匹配 的事件 模式 进行 筛 选。例如，您可以筛选与付款表 DynamoDB 到相关的订阅者 API 端点的状态更新操作相关的事件。

交付： EventBridge API 目的地 使用 REST API 调用在 亚马逊云科技 之外 传输事件。为了保护外部端点免受流量激增的影响，您可以设置 调用速率限制 。 此外，会 根据错误自动 处理指数退避 的 重试 。 亚马逊简单队列服务 (SQS) 死信队列会 保留无法传 送的消息。它们可以提供可扩展和弹性交付。

负载结构： 考虑消费者如何处理事件有效载荷。此示例使用 输入转换器 创建符合 CloudEvents 规范的结构化负载。CloudEvents 提供行业标准格式和通用负载结构，并为消费者提供开发者工具和软件开发工具包。

有效载荷大小： 为了快速可靠地交付，请将有效载荷大小降至最低。考虑仅提供必要的详细信息，例如标识符和状态。如需更多信息，您可以为消费者提供单独的 API。然后，消费者可以单独调用此 API 来检索其他信息。

安全和授权： 为了安全地传送事件，您可以 使用 OAuth 等授权方法建立 连接 。在幕后，该连接将证书存储在 亚马逊云科技 Secrets Manager 中 ，后者对证书进行安全加密。

订阅管理： 考虑消费者如何管理其订阅，例如指定要订阅的 HTTPS 端点和事件类型。DynamoDB 存储此配置。 亚马逊 API Gateway 、 Amazon Cognito 和 亚马逊云科技 Lam bda 为运营提供了管理 API。

成本： 实际上，发送 webhook 会产生成本，随着您的成长和生成更多事件，成本可能会变得很大。考虑实施使用政策、配额，并允许消费者仅订阅他们需要的事件类型。

获利： 考虑根据消费者的使用量或等级向其计费。例如，您可以提供免费套餐以提供对 webhook 的低摩擦访问，但只能达到一定的音量。要增加交易量，您需要收取与您的 webhooks 提供的商业价值一致的使用费。在大批量下，您可以提供高级套餐，在那里您可以为某些消费者提供专用基础架构。

监控和故障排除： 除了架构之外，还要考虑日常操作流程。由于端点由外部各方管理，因此可以考虑启用自助服务。例如，允许消费者查看状态、重播事件和搜索过去的 Webhook 日志以诊断问题。

高级场景： 此示例专为常见用例而设计。对于高级场景，可以考虑备 用应用程序集成服务 ， 注明其 服务配额 。 例如， Amazon Simple Notification Service (SNS) 用于向更多用户分发，Lambda 用于灵活自定义负载和身份验证，以及用于协调 断路器模式以停用不可靠订阅者的 亚马逊云科技 Ste p F un ctions。

接收 webhook

要接收 webhook，您需要向网络挂钩提供商提供一个 API。例如，电子商务商店（消费者）可能依靠其支付平台（提供商）提供的通知来确保及时发货。Webhook 呈现出一种独特的场景，因为消费者必须具有可扩展性、弹性并确保收到所有请求。

适用于 webhook 使用者的 亚马逊云科技 参考架构

在这种情况下，考虑一个高级用例，该用例可以通过使用 索赔 检查模式处理大型有效载荷。

总体而言，该架构包括：

• AP I： 用于接收网络挂钩的 API 端点。然后，事件驱动的系统对收到的 webhook 进行授权和处理。
• 负载存储： S3 为大型有效负载提供可扩展存储。
• Webhook 处理： E ventBridge 管道为处理提供了可扩展的架构。它可以 批处理 、 筛选 、 丰富 事件并将事件作为 目标 发送到一系列处理服务 。

接收 webhook 的注意事项和最佳实践

在构建接收 webhook 的应用程序时，请考虑以下因素：

可扩展性 ：提供商通常在事件发生时发送事件。API Gateway 提供可扩展的托管端点来接收事件。如果不可用或受到限制，提供商可以重试请求，但是，这不能保证。因此， 配置适当的速率和突发限制 非常重要 。在入口点限制请求可以减轻对下游服务的影响，下游服务的每项服务都有自己的 配额 和限制。 在许多情况下，供应商还意识到对下游系统的影响。因此，它们以阈值速率限制发送事件，通常最高为每秒 500 笔交易 (TPS)。

此外，API Gateway 允许您 验证请求 、 监控任何错误 并防范分布式拒绝服务 (DDoS)。这包括第 7 层和第 3 层攻击，这些攻击是公开曝光的 webhook 消费者面临的常见威胁。

授权和验证 ：提供商可以支持不同的授权方法。以基于哈希的消息身份验证码 (HMAC) 的常见场景为例，其中共享密钥建立并存储在 Secrets Manager 中。然后，Lambda 函数会验证消息的完整性，处理请求标头中的签名。 通常，签名包含 带有过期时间戳 的随机数，以缓解重放攻击，攻击者会多次发送事件。 或者，如果提供商支持 OAuth，可以考虑使用亚马逊 Cognito 保护 API。

有效载荷大小 ：提供商可以发送各种大小的有效载荷。事件可以批量处理单个较大的请求，也可以包含重要信息。考虑事件驱动系统中的有效负载大小限制。API Gateway 和 Lambda 的限制分别 为 10 Mb 和 6 Mb。 但是，DynamoDB 和 SQS 限制在 400 k b 和 256 kb （带有 大型消息的 扩展名 ）以 内，这可能构成瓶颈。

S3 不是处理整个负载，而是存储有效负载。然后在 DynamoDB 中通过其存储桶名称和对象密钥对其进行引用。这被称为 索赔核对模式 。 使用这种方法，根据 Lambda 调用负载配额 ，该架构支持高达 6mb 的有效负载。

幂等性 ：出于 可靠性考虑，许多提供商优先考虑 至少交付一次 ，即使这意味着不能保证准确交付一次。 它们可以多次传输同一个请求，从而产生重复请求。为了处理这个问题，Lambda 函数会将事件的唯一标识符与 DynamoDB 中以前的记录进行核对。如果尚未处理，则创建一个 DynamoDB 项目。

排序 ：考虑按预期顺序处理请求。由于大多数提供商优先 考虑至少一次交 付，因此事件可能会出现故障。为了指示顺序，事件可以在负载中包含时间戳或序列标识符。否则，可能会根据收到网络挂钩的时间尽最大努力进行订购。要可靠地处理订购，请选择可确保排序的事件驱动服务。此示例使用 DynamoDB 流 和 EventBridge 管道。

灵活处理 ：EventBridge Pipes 将一系列事件驱动的服务作为目标提供集成。 您可以根据 过滤器 将事件路由到不同的目标 。不同的事件类型可能需要不同的处理器。例如，您可以使用 Step Functions 来编排复杂的工作流程，将 Lambda 用于执行时间少于 15 分钟的计算操作，使用 SQS 来缓冲请求，使用 亚马逊弹性容器服务 (ECS) 来处理长时间运行的计算任务。 EventBridge Pipes 提供 转换 以确保仅发送必要的有效载荷，并在需要其他信息 时进行 扩 展。

成本： 此示例考虑了一个可以处理大型有效载荷的用例。但是，如果你能确保提供商发送的有效载荷最少，可以考虑采用更简单的架构，不采用索赔检查模式，以最大限度地降低成本。

结论

Webhooks 是应用程序通信以及企业与客户和合作伙伴协作和整合的常用方法。

这篇文章展示了如何构建应用程序以在 亚马逊云科技 上发送和接收 Webhook。它使用诸如EventBridge和Lambda之类的无服务器服务，这些服务非常适合事件驱动的用例。它涵盖了高级参考架构、注意事项、最佳实践和 代码示例 ，可帮助您构建解决方案。

有关网络挂钩的标准和最佳实践，请访问开源社区资源 Webhooks.fyi 和 Cloud Events.io 。

如需更多无服务器学习资源，请访问 无服务器世界 。