在 AWS 上发送和接收 Webhook：通过事件通知进行创新 计算博客

在 AWS 上发送和接收 Webhook：通过事件通知推动创新

关键要点

本文由 Daniel Wirjo 和 Justin Plock 撰写。

Webhook 通常被称为 反向 API 或 推送 API，它为应用程序提供了一种几乎实时集成和通信的方式，能够为业务和系统事件实现整合。

无论您是构建一个 SaaS 应用程序与客户工作流程集成，还是从供应商处接收交易通知，Webhook 都在推动创新、提升用户体验和简化操作方面扮演着至关重要的角色。

本文将解释如何在 AWS 上构建 Webhook，并涵盖以下两种场景：

在文中，我们会讨论高层次的参考架构、考虑因素、最佳实践以及 代码示例 以指导您的实现。

发送 Webhook

发送 Webhook 的过程是生成事件并将其传送给第三方 API。这些事件可以促进第三方系统中的更新、工作流和操作。例如，一个支付平台提供者可以发送支付状态通知，使电商平台消费者能够在确认后及时发货。

Webhook 提供者的 AWS 架构参考

该架构由两个服务组成：

发送 Webhook 的考虑因素和最佳实践

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

事件生成：需要考虑如何生成事件。此示例使用 Amazon DynamoDB 作为数据源。通过 DynamoDB Streams 的变更数据捕获 生成事件并发送到 Amazon EventBridge Pipes。然后，通过使用 输入转换器 简化 DynamoDB 的响应格式。

过滤：EventBridge Pipes 支持通过匹配 事件模式 进行 过滤。

投递：EventBridge API Destinations 通过 REST API 调用将事件传送到 AWS 之外。为了保护外部端点免受流量激增，您需设置 调用速率限制。

有效载荷结构：考虑消费者如何处理事件负载。该示例使用 输入转换器 创建一个结构化的负载，遵循 CloudEvents 规范。

安全性与授权：为了安全地传递事件，您建立使用 OAuth 的 连接。

成本：发送 Webhook 实际会产生成本，尤其是在生成更多事件时，成本可能会变得显著。可以考虑实施使用政策、配额并允许消费者仅订阅他们需要的事件类型。

监控与故障排除：除了架构之外，还需考虑日常操作的流程，为终端提供自助服务，例如允许消费者查看状态、重放事件和搜索过去的 Webhook 日志以诊断问题。

接收 Webhook

要接收 Webhook，您需要一个 API 提供给 Webhook 提供者。例如，一个电商平台消费者可能依赖于他们的支付平台提供者提供的通知，以确保商品及时发货。Webhook 展现了一种独特的情况，因为消费者必须具备可扩展性、韧性，并确保所有请求得到接收。

Webhook 消费者的 AWS 架构参考

在此场景中，考虑一个可以处理大负载的高级用例，使用 声明检查模式。

接收 Webhook 的考虑因素和最佳实践

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

可扩展性：提供者通常在事件发生时发送事件。API Gateway 提供一个可扩展的受管理端点来接收事件。

授权和验证：提供者可能支持不同的授权方法。在常见情况下，您可以使用基于散列的消息认证码 (HMAC)，共享的密钥存在于 Secrets Manager 中。

负载大小：提供者可能发送不同大小的负载。事件可以包裹成一个更大的请求。

幂等性：为确保可靠性，许多提供者优先考虑至少发送一次，尽管不保证精确定义的概率。

顺序性：考虑按预期顺序处理请求。

灵活处理：EventBridge Pipes 提供与多种事件驱动服务的集成，您可以根据 过滤器 将事件路由到不同的目标。

成本：在处理大负载的用例中，如果能确保提供者只发送必要的负载，则可以考虑不使用声明检查模式的简单架构，以降低成本。

结论

Webhook 是应用程序沟通和企业与客户、合作伙伴协作的重要方式。本文章展示了如何在 AWS 上构建发送和接收 Webhook 的应用程序。使用服务器无缝服务如 EventBridge 和 Lambda 非常适合事件驱动的用例。它涵盖了高层次的参考架构、考虑因素、最佳实践和 代码示例 以帮助您构建解决方案。

如需有关 Webhook 的标准和最佳实践，访问开源社区资源 Webhooksfyi 和 CloudEventsio。

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

标签：贡献，无服务器