Webhook 与 WebSocket 供开发者：摄取、队列、扇出模式
面向开发者的 Webhook 和 WebSocket 比较，涵盖无服务器适用性、重试与连接权衡，以及 Webhook→队列→WebSocket...
Webhooks 是一种单向 HTTP 事件推送，当服务器上发生某些事情时触发；WebSockets 是持久的双向连接，保持打开状态以进行持续的双向消息传递。选择 Webhooks 用于服务器到服务器的通知，例如支付确认或 CI/CD 触发器，选择 WebSockets 则是在浏览器或应用程序需要实时交互更新（例如聊天或交易仪表板）时使用。 许多生产系统同时使用这两种方式：一个webhook将数据馈送到你的后端，然后一个WebSocket连接以接近实时的方式将该事件分发给连接的客户端。
TL;DR:
- Webhooks 非常适合第三方服务到服务器的通知，但需要一个公共、可访问的 URL，带有安全的签名和快速的响应。
- WebSockets 更适合与浏览器或应用程序进行实时双向通信，但需要连接管理和状态处理，包括重连逻辑。
- 结合 webhook 和 WebSocket 可以提供一种有弹性的架构：webhook 用于事件摄取，而 WebSocket 则高效地将实时更新传递给客户端。
- 扩展 WebSocket 涉及使用粘性会话或共享消息代理来管理大量打开的连接，而 webhook 可以通过无状态、无服务器队列处理轻松扩展。
- Webhook 安全性依赖于轮换签名和 TLS；WebSocket 安全性强调连接认证和每条消息验证，以防止未经授权的访问。
目录
- Webhook 详解：开发者如何使用
- WebSocket 教程：持久连接模型
- Webhook 和 WebSocket 技术对比
- 何时使用 Webhook 与 WebSocket：决策清单
- 可扩展性和运营考量
- 安全差异和推荐防御措施
- [一个实际模式：Webhook 驱动 WebSocket 分发](#一个实际模式：Webhook 驱动 WebSocket 分发)
- 默认选择和接下来应该关注什么
- 无需自行构建即可获得可靠的 webhook 投递
- 来源
- 常见问题解答
Webhook 详解：开发者如何使用它们
一个webhook开始于注册。您向提供商（例如支付处理器、Git托管服务或区块链节点）提供一个URL，当相关的事件发生时，该提供商会向您的端点发送一个HTTP POST请求，其中包含一个JSON负载，描述发生了什么。没有轮询，没有空闲的开放连接。它是一种基于事件驱动的推送，通过标准的HTTP协议进行，这就是为什么它可以轻松地集成到您已经运行的架构中。
The catch is delivery guarantees. 大部分 webhook 系统使用至少一次（at-least-once）语义：如果您的端点没有足够快地返回 2xx 响应，提供商会重试，有时会重试数小时甚至数天，具体取决于其重试计划。这意味着您的处理器必须是幂等的 (idempotent)，能够处理相同的交付两次而不会创建重复的费用或重复的数据库行。 Webhook 重试行为 是 webhook 集成中细微 bug 最常见的来源，因为团队在构建处理程序时假定协议保证了恰好一次交付，而协议从未做出这样的承诺。
由于 webhook 需要一个可达的 URL，它们也引入了自己的操作检查清单：
- 一个能够穿透防火墙和负载均衡器配置的公共端点
- 签名验证（通常是 HMAC）以确认请求确实来自提供商
- 记录交付 ID，以便您可以追踪重复项或缺失项
- 响应时间足够快，以避免触发您仍在处理的请求的重试
您将在支付确认、CI/CD 管道触发器、Git 推送通知和存款警报之后看到 Webhook。它们也是无服务器后端（serverless backends）的自然选择，因为在每次调用之间无需保持连接状态。
WebSockets 教程：持久连接模型
一个 WebSocket 连接的生命始于一个普通的 HTTP 请求，然后进行升级。客户端发送一个 Upgrade: websocket 头部，服务器同意，从那时起，双方可以在同一 TCP 连接上发送消息，而无需每次都发送一个新的 HTTP 请求。 这就是它之所以是全双工的原因：服务器和客户端可以在需要时推数据，而不仅仅是在响应请求时。
最具挑战性的一部分不是握手。而是握手之后的一切。连接中断，网络出现故障，标签页进入休眠状态。客户端代码需要重连逻辑，并且您需要监控 bufferedAmount 以避免以比套接字能够排空它们更快的方式堆积出站消息。MDN 的 WebSocket 文档详细介绍了此生命周期，包括在安全上下文中始终使用 wss:// 以及在页面卸载时干净地关闭套接字的相关指导。
服务器端，WebSockets 是有状态的。每个打开的连接都会消耗一个文件描述符和一些内存，如果你运行多个服务器实例，则需要粘性会话或消息代理（Redis pub/sub, NATS），以便在一个实例上发布的消息能够到达连接到另一个实例的客户端。
常见用例包括：
- 聊天应用程序和协作编辑器
- 实时仪表盘和股票行情
- 多人游戏状态同步
- 存在指示器（“用户正在输入”）
Wenn Sie etwas mit höheren Backpressure-Anforderungen entwickeln oder stream-basierte APIs wünschen, behalten Sie WebTransport und WebSocketStream im Auge, die beide auf einige der rauen Kanten der klassischen WebSocket API abzielen, obwohl die Browser-Unterstützung noch aufgeholt werden muss.
Wie vergleichen sich Webhooks und WebSockets technisch?
| 属性 | Webhooks | WebSockets |
|---|---|---|
| 连接持久性 | 无，每个事件一次请求 | 持久，保持连接 |
| 方向 / 谁发起 | 单向；提供商发起每次推送 | 双向；握手后任意一方发送 |
| 协议 / 端口 | HTTP/HTTPS，标准端口 | ws/wss，从HTTP升级，标准端口 |
| 有无状态 | 调用之间无状态 | 连接生命周期内有状态 |
| 交付保证/重试 | 至少一次，失败时提供商重试 | 没有内置重试机制，应用程序必须处理丢包 |
| 谁管理重试 | 发送提供商（使用您的幂等处理程序） | 您的客户端和服务器代码 |
| 典型延迟/最适合 | 近实时，适合事件通知 | 最低延迟，最适合持续交互 |
| 安全模型 | HMAC 签名，TLS，时间戳检查 | TLS 握手 (wss)，每个连接的身份验证令牌 |
| 公共端点需求 | 必需，必须可访问互联网 | 客户端发起连接；无需入站端点 |
| 典型用例 | 支付，CI/CD，存款，订单状态 | 聊天，仪表盘，多人游戏，状态 |
实际含义是：Webhooks 将交付问题推给了发送方（带有重试时，您必须以幂等方式处理），而 WebSockets 将连接管理问题推给了您。 抽象地说，两者都“不更容易”。 这取决于您更愿意编写无状态 HTTP 处理程序还是运行有状态的连接池。
何时使用 Webhooks 与 WebSockets：决策清单
在选择架构之前，请运行以下问题：
- 事件的来源在哪里？ 如果它是一个第三方系统（例如支付网关、区块链网络或Git托管服务），您需要webhook。您无法连接到您不控制的服务的WebSocket。
- 您可以容忍多少延迟？ 次秒级的UI更新更适合WebSocket。后端记录更新几秒的延迟对于webhook来说是可以接受的。
- 是什么样的规模形状？ 许多独立的事件生产者为单个后端服务时，更倾向于使用Webhook。单个后端向数千个连接客户端广播更新时，更倾向于使用WebSocket。
- 你的服务器拓扑是什么？ 可以缩减到零的无服务器函数与Webhook自然契合。如果您已经运行了长期的有状态服务器，那么WebSocket的附加复杂性会更小。
- 防火墙或网络限制是否阻止了入站连接？ 如果您的基础设施无法暴露公共端点，WebSocket（客户端发起向外连接）就能完全绕过这个问题。
映射到场景：支付通知和存款警报通过 webhook 发送。来自外部工具的分析事件摄取也通过 webhook 发送。聊天和协作编辑通过 WebSockets 进行。即使底层价格源通过 webhook 接收，实时交易仪表盘也需要 WebSockets 作为最后一英里。
专业提示： 从 webhook 加上前端简单轮询开始构建原型。 速度较慢，但它可以在你投入连接管理之前验证事件模型。 只有在确认用户实际上需要亚秒级更新时才添加 WebSocket，切勿过早添加。
可扩展性和运营注意事项
WebSocket 改变了你的容量计算。每个打开的连接都持有文件描述符和一块内存，一旦你扩展到单个服务器实例，你就需要粘性会话或共享发布/订阅层，以便消息能够到达客户端，无论它们连接到哪个实例。 这就是真正的基础设施，而不是一个配置标志。
Webhook 的扩展方式与其他服务不同，因为它们在调用之间不保持状态，这正因如此，它们非常适合无服务器和零扩展环境。一个函数启动，处理 POST 请求，然后消失。
在生产规模下，一些模式可以使这两种模型都保持合理：
- 通过队列（SQS、Pub/Sub、RabbitMQ）路由传入的 webhook，防止事件爆发淹没你的处理程序
- 当许多事件在短时间内触发时，批量或节流 WebSocket 广播
- 对于反复失败的可重入处理的 webhook 传递，使用死信队列
- 监控 WebSocket 服务器的连接变化和 webhook 端的重试队列深度；这两者都是客户注意到问题前的早期预警信号
安全性差异和推荐防御措施
Webhook 和 WebSocket 的失败方式不同，因此它们需要不同的防御措施。Webhook 安全的重点在于证明请求是真实的：在标头中添加 HMAC 签名，使用时间戳来阻止重放攻击，以及严格的 TLS。 WebSocket 安全的核心在于连接本身：在连接时使用短生命周期令牌进行身份验证，然后验证后续的每个消息，因为 如果不对每个消息重新检查权限，单个握手授权整个长期会话确实存在风险。
值得从第一天开始构建的实际防御措施：
- 定期轮换 HMAC 密钥，并记录每次交付尝试及其签名状态
- 拒绝具有过时时间戳的 webhook 有效载荷，以阻止重放
- 限制每个客户端的并发 WebSocket 连接数量，并限制消息频率
- 即使经过身份验证，也要在服务器端验证有效载荷，因为有效的令牌并不能保证有效消息
Chaingateway 自己的 webhook 基础设施会对每个请求进行 HMAC 签名，并提供一份 记录完善的安全工作流程，用于在不造成停机的情况下轮换密钥，这比大多数团队预期的重要得多，尤其是在他们因密钥泄露而遭受损失后。
一个真实的模式：Webhook 向 WebSocket 分发
在生产环境中反复出现的一种模式：接收一个 webhook，验证它，将其入队，然后让一个 worker 将结果分发到连接的客户端，通过 WebSockets。这在摄取端的 HTTP 至少一次传递持久性，以及 UI 端的持久连接低延迟之间取得了平衡。
步骤如下：
- 接收 webhook POST 请求并验证 HMAC 签名后再处理有效载荷
- 将验证后的事件入队，确保下游慢速处理程序不会阻塞 HTTP 响应
- 处理事件（更新数据库记录，标记支付已确认）
- 将结果发布到 WebSocket 服务器订阅的发布/订阅通道或代理
- 将更新推送到任何已连接并对该事件感兴趣的客户端
这解耦了摄取和交付，这正是实际生产系统使用的容错模式: Webhooks 作为持久的入站机制，中间的代理，WebSocket 作为最后一英里的交付到浏览器或应用程序。 Chaingateway 的 事件通知 webhook 传递经过预解码且 HMAC 签名的负载，覆盖多个链，这从流程中移除了一个步骤，因为您无需在采取行动之前解析原始区块链数据。
默认选择以及接下来需要关注的内容
默认使用webhook进行服务器到服务器的通信，尤其是在无服务器架构中，保持连接打开没有任何架构意义。当人类盯着屏幕等待在不到一秒的时间内发生变化时，默认使用WebSockets。大多数真实系统最终会结合使用两者，而不是教条地选择其中一种，这通常不是妥协，而是通常正确的设计。
关注 WebTransport 和 WebSocketStream。它们尚未完全取代 WebSockets，但两者都旨在解决导致编写原始 WebSocket 代码比预期更困难的反向压力和流处理问题。
— Bitblade
获取可靠的 Webhook 传递，无需自行构建
构建可靠的网络钩子（webhook）背后的数据摄取、验证和重试逻辑，是真正的工程时间，大多数团队都会低估，直到他们将其部署两次。Chaingateway的区块链网络钩子为您提供HMAC签名的、预解码的事件通知，覆盖以太坊、Tron、比特币和其他主要链，因此上面描述的分发模式从已验证的有效负载开始，而不是您必须自行解析的原始链数据。
这直接对应于本文中的架构：Chaingateway 处理 webhook 接收和签名，您处理队列和 WebSocket 分发给您的用户。计划从每月 49 欧元的 Plus 方案开始，可升级到企业版以处理更高的流量。 如果您正在权衡是构建自定义 webhook 基础设施还是连接到托管的 feed，请查看定价页面，并在编写下一个重试处理程序之前，确定哪个层级符合您的事件量。
来源
为了更深入地了解协议细节，请参考MDN的WebSocket客户端指南，它精确地涵盖了连接生命周期。关于webhook传递机制，请参阅Webhooker的分步指南以及Twilio的webhook指南。关于混合架构模式，WebhookRelay的对比分析值得一读。
- WebSockets 与 Webhook：它们有何不同？ | GetStream
- Webhook 是如何工作的？ 实际的 HTTP 步骤详解 — Webhooker
- Webhook 与 WebSocket：有什么区别？ | WebhookRelay
常见问题解答
什么是取代 WebSockets 的技术？
虽然还没有完全替代 WebSockets，但 WebTransport 和 WebSocketStream 正在兴起，它们是旨在更干净地处理反向压力和复用流的替代方案。浏览器支持仍然不完整，因此 WebSockets 仍然是今天大多数实时功能的实用默认选项。
ChatGPT 使用 SSE 还是 WebSocket？
流式传输浏览器中的 AI 响应通常使用服务器发送事件 (SSE) 进行单向令牌流式传输，因为客户端主要只需要接收，而不需要发送连续数据。一些实时语音或多轮交互功能使用 WebSockets，因为在这些功能中，双向交换更为重要。
Webhooks 使用有哪些缺点？
Webhooks 需要一个公开可访问的端点，这会带来防火墙和安全方面的考虑，并且传递通常是至少一次的，这意味着您的处理程序必须能够容忍重复事件。如果您的端点在事件触发时出现故障并且重试过期，则该事件可能会在您围绕它构建监控之前悄无声息地丢失。
Webhooks 的例子有哪些？
常见的例子包括支付确认通知、Git推送和拉取请求事件、CI/CD流水线触发器，以及区块链网络上的存款或交易警报。Chaingateway的基于webhook的存款处理是一个无需轮询区块链节点即可自动确认资金的实际例子。
Chaingateway的webhook服务需要多少费用？
Chaingateway的webhook和事件通知功能包含在所有API计划中，从每月计费的Plus计划（49欧元/月）开始，或者每年计费490欧元。 更高的层级（Pro、Premium、Enterprise）会根据使用量和附加功能进行调整。
推荐
准备好自己动手构建了吗？ 获取你的 API key — 7 天试用，无需信用卡 — 或查看 区块链 API 获取完整的 endpoint 参考。