当我们构建 Web 应用时，经常会有多个服务。在绝大多数情况下，这些服务由许多不同的 Web 服务协同工作组成。在这种由多个服务组成的 Web 应用中，如何传输数据是每个开发者都需要考虑的事情。在解决这个问题时，两种方法已经成为主流：webhooks 和轮询。每种方法都提供了一种独特的方式来从一个服务获取和传输数据到另一个服务。选择其中一种方式会对你的应用程序的效率、实时能力和整体用户体验产生重大影响。本文将比较 webhooks 与轮询，分析每种方法的优缺点，并讨论何时使用哪种方法。 ## 什么是轮询？轮询（通常称为 API 轮询）是指客户端以固定的时间间隔（比如每隔 x 秒）请求特定数据，并且服务器响应请求的数据。可以将其想象为“有没有新的数据？”以固定的时间间隔来问。轮询可以通过 HTTP 请求来实现，客户端发送 GET 请求到服务器，服务器回应所请求的数据。想象一下，John 构建了一个名为 Doc.AI 的 AI 文档产品，并使用 Logto 进行用户身份管理。 Frank 是 John 产品的一个用户，并创建了他自己的个人账户。某一天，Frank 加入了他的朋友 David 创建的一个工作区。当时，John 想给 Frank 发邮件，请求他在获得对更多敏感资源的访问权限之前开启多因素认证 (MFA) 以加强账户安全。 John 的产品后台需要不断轮询相关 API 以得知 Frank 何时加入了 David 的工作区。 ```mermaid sequenceDiagram participant Client as Doc.AI (服务器) participant Server as Logto loop 每 x 秒轮询一次 Client->>Server: 发送 API 请求
“Frank 加入了 David 的工作区吗？” Server-->>Client: 还没有 end note right of Client: Frank 加入了 David 的工作区 Client->>Server: 发送 API 请求
“Frank 加入了 David 的工作区吗？” Server-->>Client: 是的！ note right of Client: Doc.AI 开始工作：
1. 给 Frank 发送邮件
2. 等待 MFA 完成
... ``` ## 什么是 Webhook？ Webhook（即“HTTP 回调”）是一种实时数据通信的机制，服务器在事件发生时，会将数据发送到客户端。与客户端请求数据不同，webhook 在有更新时会将数据主动推送到客户端。可以将其想象为应用程序的收件箱。当某些事件发生时——例如新用户注册或付款完成——webhook 会给收件箱投递一条消息，以通知你的应用程序当前发生了什么。让我们继续使用前面解释轮询时使用的 Doc.AI 示例。以下是如果我们使用 webhook 来查找 Frank 是否加入了 David 的工作区时的序列图： ```mermaid sequenceDiagram participant Client as Doc.AI (服务器) participant Server as Logto note right of Client: 其它 HTTP 请求 ... note right of Client: ... note right of Client: Frank 加入了 David 的工作区 Server->>Client: 事件触发的 Webhook
“Frank 加入了 David 的工作区” note right of Client: Doc.AI 开始工作：
1. 给 Frank 发送邮件
2. 等待 MFA 完成
... ``` ## 重要区别 - 请求发起方轮询是由客户端发起的（在我们的示例中，Doc.AI 是客户端，Logto 是服务器），而 webhook 是由事件触发并由服务器发起的。 - 资源消耗轮询是一种计算资源的浪费，因为它以固定的时间间隔发送请求，导致计算资源效率低下。相比之下，webhook 是由服务器“按需”发起的。与轮询相比，客户端和服务器的资源消耗更少。 - 时机轮询是由客户端发起的，因此客户端可以控制数据获取的时机；然而，webhook 是由服务器发起的，客户端只能接收和处理数据。不过，由于两者的机制不同，webhook 可以实现实时数据同步，而轮询则无法实现。 ## 应该选择哪一个？根据轮询和 webhooks 的机制，通常的做法是仅在数据频繁更新且对数据的实时性要求不严格时才选择轮询。在其他情况下，webhook 是更好的选择。然而，选择使用 webhook 时，开发者需要注意以下问题： 1. 如果系统对获取的数据有高度依赖性，则需要考虑在 webhook 失败且数据无法同步时有一个备用计划来获取数据，包括但不限于轮询或要求 webhook 具有重新发送机制等。 2. 在客户端接收 webhooks 的端点，应该应用 API 密钥和内容签名验证等措施，以防止黑客通过伪造 webhook 来攻击客户端。 3. 由于 webhook 可能会发送重复请求，此时需要进行相应的处理以防止数据重复和不一致。 Logto 作为一个非常流行的用户身份解决方案，提供了丰富的 webhook 场景和出色的安全性。使用 Logto 作为你的产品身份系统，它可以轻松集成并适用于各种应用场景。