隆重推出 Convoy

嗨 dev.to，我想向您展示 Convoy。

Convoy 是一款开源的 Webhook 服务。你可以把它想象成一把用于发布 Webhook 事件的瑞士军刀。几个月前，我正在构建一个金融科技 API，当时正在寻找一款能够推送 Webhook 事件的工具。我想要的是一款简单易用、语言无关且云原生的工具。理想情况下，我希望它是一个容器，我可以部署它，向其中发布事件，然后它能够​​可靠地将事件发布到相应的端点。由于找不到这样的工具，所以我们自己开发了一个。Convoy 提供了一个 REST API，用于注册端点并将事件发布到相应的端点。

Webhook 问题

表面上看，Webhook 并非简单的 HTTP 推送。它包含多种功能，并针对某些类型的集成有特定的使用场景。我想谈谈其中几个方面：

• 不良终点

  发布 Webhook 需要处理一些设计不佳的端点，例如响应负载过大的端点、无限期挂起最终超时的端点，以及证书过期的端点。一个优秀的 Webhook 系统应该能够让发布者和使用者都清楚地了解这些问题。

• 投递尝试日志

  对于开发者来说，构建基于 Webhook 的系统有时并非易事。开发者经常使用 ngrok 将事件传输到本地机器进行调试，例如：签名有效负载、解析有效负载结构、快速响应 200 状态码、监控成功重试次数以及测试每个事件的 URL。构建一个优秀的 Webhook 发送系统需要建立一个发送尝试日志，记录已发送的内容和已返回的内容。

• 工作实施延迟。

  由于 Webhook 本质上是一种异步活动，因此需要一个底层弹性任务队列系统来应对可扩展性，以及针对瞬态和非瞬态事件故障的重试机制。标准的 Webhook 交付系统是在任务队列系统（例如 Redis、Kafka、Rabbit、NATS 等）的基础上实现的，以提供这些功能。

• 安全

  使用 HTTP 发布 Webhook 事件需要用户保护其端点免受恶意用户的攻击。用户需要知道是谁在发布事件，以及他们是否拥有发布事件的授权。一些用户采用了多层安全措施：例如，使用共享密钥对有效负载进行签名（常见）、使用静态 IP 地址（常见于金融科技领域）、以及使用双向 TLS（例如 PagerDuty 中使用的技术）。本质上，一个优秀的 Webhook 交付系统需要根据各个用户的具体需求，支持所有安全措施。

• 每个事件的URL。

  在如今无代码工具和无服务器函数盛行的时代，开发者通常会从服务提供商（例如 Stripe）接收 webhook 事件，并将其分发给后台的多个应用程序以执行所需的操作。例如，Stripe 为这种机制提供了卓越的支持，用户可以订阅特定事件的端点，但许多其他应用程序却不具备这种功能。一个优秀的 webhook 分发系统应该为每个事件提供一流的 URL 支持。

我们正在尝试用Convoy来解决所有这些 Webhook 实现上的碎片化问题。

入门

首先，您可以访问https://getconvoy.io/docs/guide并按照分步指南在本地计算机上运行 Convoy。

结论

我们相信，将分散的 Webhook 实现抽象到 Convoy 中仍处于非常早期的阶段，但我们很高兴分享目前为止的进展，并邀请您加入我们的社区。

您可以点击此处加入我们的 Slack 社区。

我们迫不及待地想听听您的反馈！