1. 概述
应用程序之间要实现实时事件通知，通常有两种方式：轮询（Polling） 和 Webhooks。
本文将介绍这两种方式的区别，重点讲解 Webhooks 的原理、使用场景以及安全性保障。
2. 轮询 vs Webhooks
我们先分别看一下这两种机制的基本概念。
2.1. 轮询（Polling）
轮询是指客户端定时向服务端发起请求，询问某个事件是否发生。
当事件发生后，服务端返回相应的数据（即 payload）给客户端：
这种方式虽然实现简单，但效率较低，资源消耗大。
2.2. Webhooks
Webhooks 是一种事件驱动机制。当服务端某个事件发生时，它会主动向客户端注册的 URL 发送请求（通常是 POST），推送事件数据。
这种方式更高效，也更符合现代应用对实时性的需求：
3. Webhooks 深入解析
接下来我们详细看看 Webhooks 的工作方式和使用场景。
3.1. Webhooks 与轮询对比
| 特性 | 轮询 | Webhooks |
|---|---|---|
| 响应速度 | 较慢 | 快速 |
| 资源消耗 | 高 | 低 |
| 客户端工作量 | 多 | 少 |
| 数据传输机制 | 主动拉取 | 事件驱动自动推送 |
✅ 从整体来看，Webhooks 在效率和实时性方面明显优于轮询。
3.2. Webhooks 的使用场景
任何需要实时响应外部事件的应用，都可以考虑使用 Webhooks。
常见场景包括：
- 在线支付系统集成（如 PayPal、Stripe）：支付完成后通过 Webhook 实时通知支付结果
- 消息通知系统：如 Slack 接收来自其他系统的实时通知
- 自动化流程触发：如 GitHub Push 事件触发 CI/CD 流程
- 第三方服务回调：如短信服务、邮件服务、订单状态变更等
3.3. Webhooks 的工作流程
Webhooks 的核心是客户端提供一个回调 URL（也称为 Endpoint），服务端在事件发生时主动调用这个 URL。
通常是一个 POST 请求，包含事件数据（payload）：
客户端收到请求后，在后端解析 payload 并执行相应的业务逻辑。
示例请求结构如下：
{
"event": "payment_complete",
"data": {
"user_id": "U123456",
"amount": "199.00",
"currency": "USD"
},
"timestamp": "2022-10-15T14:30:00Z"
}
客户端应返回 2xx 响应表示接收成功，否则服务端可能会重试。
3.4. Webhooks 的安全性保障
由于 Webhook 的回调 URL 是公开可访问的，存在被伪造请求的风险。为提升安全性，可以采取以下措施：
✅ 强制使用 HTTPS 加密传输
✅ 签名验证（Signature）：服务端在发送请求时，使用共享密钥对 payload 进行哈希签名（如 HMAC-SHA256）。客户端收到请求后，使用相同密钥重新计算签名，验证是否一致。
示例签名头：
X-Signature: sha256=abc123xyz...
⚠️ 客户端必须验证签名，否则可能接收到伪造数据。
✅ 限制请求频率（Rate Limiting）
✅ IP 白名单控制：限制只接受来自可信服务端的请求
4. 总结
本文介绍了轮询和 Webhooks 两种事件通知机制：
- 轮询 实现简单但效率低，适合低频或对实时性要求不高的场景
- Webhooks 是事件驱动的高效方案，适合需要实时响应的系统集成
- 使用 Webhooks 时需关注回调 URL 的安全性和请求验证机制
合理使用 Webhooks，可以显著提升系统间的交互效率和响应能力，是现代应用集成中不可或缺的一环。