1. Webhook 基础概念
1.1 什么是 Webhook
Webhook 是一种基于 HTTP 的回调机制，允许一个应用在发生特定事件时，主动向另一个应用发送实时数据通知。与传统的“客户端主动拉取”模式不同，Webhook 采用“服务器主动推送”模式——事件源在事件发生时，立即向预先注册的 URL 发送 HTTP 请求（通常是 POST），携带事件相关的数据负载。
核心特征：事件驱动、实时推送、单向通知、轻量级 HTTP 回调。
一个典型的 Webhook 流程包含三个角色：
- 事件源（Provider）：产生业务事件的一方，如 GitHub、Stripe、微信支付。
- 接收端（Consumer）：注册 Webhook URL 并处理事件的一方，通常是开发者的后端服务。
- Webhook 请求：事件源向接收端发送的 HTTP POST 请求，包含事件类型、时间戳、负载数据及签名。
1.2 Webhook 与 API 轮询的区别
Webhook 和 API 轮询是两种完全不同的数据获取模式。轮询是接收端按固定时间间隔主动向事件源发起请求，查询是否有新数据；Webhook 则是事件源在有新数据时主动通知接收端。下表从多个维度对比两者的差异：
| 对比维度 | Webhook（推送） | API 轮询（拉取） |
|---|---|---|
| 通信方向 | 事件源 → 接收端（服务器推送） | 接收端 → 事件源（客户端拉取） |
| 触发方式 | 事件驱动，实时触发 | 时间驱动，固定间隔 |
| 实时性 | 毫秒级，事件发生即送达 | 取决于轮询间隔，通常秒级到分钟级 |
| 资源消耗 | 低，仅在有事件时发送请求 | 高，大量无效请求浪费带宽和计算 |
| 实现复杂度 | 需暴露公网端点、验证签名 | 只需调用 API，无需公网端点 |
| 可靠性保障 | 需重试机制、幂等处理 | 天然幂等，可重复拉取 |
| 典型场景 | 支付回调、CI/CD 通知、即时消息 | 数据同步、状态检查、批量导出 |
选择建议：需要实时响应、事件频率不确定的场景优先选择 Webhook；需要批量拉取历史数据、接收端无法暴露公网端点的场景使用轮询。实践中，许多系统同时使用两者——Webhook 处理实时事件，轮询作为兜底补偿机制。
1.3 Webhook 的典型应用场景
Webhook 在现代化系统架构中应用广泛，以下列举四个最常见的场景：
- 支付回调：支付宝、微信支付、Stripe 等支付网关在用户完成支付后，通过 Webhook 通知商户系统更新订单状态。这是 Webhook 最典型、对实时性要求最高的场景。
- CI/CD 与 DevOps：GitHub、GitLab 在代码推送、PR 合并时触发 Webhook，通知 Jenkins、GitHub Actions 等 CI 工具自动执行构建和部署流水线。
- 即时消息与通知：Slack、钉钉、飞书的机器人 Webhook 允许外部系统向群聊推送告警、监控事件或业务通知。
- 数据同步与 ETL：CRM、ERP 系统在数据变更时通过 Webhook 将增量数据实时推送到数据仓库或搜索引擎，替代批量导入。
安全提醒：Webhook 接收端暴露在公网，必须对每个请求进行签名验证，防止伪造事件注入恶意数据。本课程后续章节将详细讲解 HMAC、RSA 等签名算法的实现与校验。
下表总结了上述场景的关键特征：
| 应用场景 | 事件示例 | 实时性要求 | 签名常见算法 |
|---|---|---|---|
| 支付回调 | 支付成功、退款完成 | 极高（秒级） | HMAC-SHA256、RSA |
| CI/CD 触发 | Push、PR、Tag 创建 | 高（秒级） | HMAC-SHA256 |
| 即时消息推送 | 告警、机器人消息 | 中（秒~分钟） | HMAC-SHA1 |
| 数据同步 | 创建/更新/删除记录 | 中（秒~分钟） | HMAC-SHA256、自定义签名 |