Skip to main content
在公共端点接收 YCloud 事件并对其进行处理,避免丢失或重复执行业务操作。在生产环境中请使用 HTTPS,保留原始请求正文,并在接收事件前验证每个签名。

注册端点

在 YCloud 控制台中,打开 开发者 > Webhook,选择 添加端点,输入 端点 URL,选择 事件,然后点击 确认保存。您也可以使用 POST /v2/webhookEndpoints;有关请求和响应,请参阅 配置 Webhook。
  • 每个账户最多可配置 20 个端点。
  • URL 必须可公开访问,且不得解析为私有地址。
  • URL 最多支持 500 个字符;可选描述最多支持 400 个字符。
  • 安全保存返回的签名 secret。

读取事件请求

有关完整示例,请参阅 Webhook 载荷。

验证签名

YCloud-Signature 标头的格式为 t=TIMESTAMP,s=SIGNATURE。 时间戳为 Unix 时间(秒)。
  1. 从标头中提取 t 和 s。
  2. 将时间戳、英文句点以及完全一致的原始请求正文字节拼接在一起。
  3. 使用端点的签名密钥计算 HMAC-SHA256。
  4. 使用恒定时间比较法比对十六进制结果。
切勿通过序列化解析后的 JSON 来重构正文。空白字符、键顺序或 Unicode 转义均会改变签名输入。 以下示例还使用了可配置的 5 分钟时间戳容差以降低重放风险。此容差属于应用程序策略,并非 YCloud 重试截止时间。请保持服务器时钟同步。

确认应答前持久化接收

在返回 2xx 之前,将验证通过的事件持久化到持久队列或事务收件箱中。若存储不可用,请返回失败以便重试投递。持久化接收后,让您的 Worker 处理业务逻辑失败并执行其自身的重试。 此 Express 处理程序使用应用程序提供的 persistEvent 操作。将其实现为以事件 id 为键的原子插入;已存储的事件必须视为成功。切勿在其业务事务提交之前将事件标记为已处理。

Java 和 Spring 示例

此 Java 17 示例采用相同的验证与持久化接收顺序。提供一个基于事务存储的 EventInbox bean,并对事件 ID 设置唯一约束。insertIfAbsent 必须在返回前提交完整事件;重复的 ID 将成功返回。然后,您的 Worker 可以在自己的事务中处理并标记已存储的事件。
切勿在将事件排入队列前先执行单独的“已处理”Redis 写入:如果在该写入后入队失败,重试可能会被丢弃。请使用原子、持久的收件箱,或者使用其接收和重复处理均为原子的队列。

耗时、重试和挂起

及时返回 2xx 响应;目标耗时应小于 6 秒。超过 10 秒的缓慢响应可能会降低投递优先级。切勿在 HTTP 处理程序内部执行耗时的业务工作。 对于非 2xx 响应或未响应的情况,默认重试间隔为: 达到配置的重试限制后,YCloud 将停止重试该事件。在默认设置下,当某个 URL 在一分钟内达到 200 次失败,或跨并发请求在一分钟内的累计失败时间达到 10 分钟时,该 URL 可能会被挂起 3 分钟。挂起期间请求将暂停,挂起结束后恢复。 此外,还请监控端点的 status。处于 pending 状态的端点不会接收事件;请参阅 端点配置。

验证接收器

  • 签名有效且事件持久化存储后返回 2xx。
  • 正文被篡改、签名格式错误以及过期的时间戳均会被拒绝。
  • 重复事件会被接收,但不会重复执行其业务操作。
  • 存储故障时返回失败,以便后续重新投递。
  • 未知的事件类型不会导致接收端崩溃。
  • 接收请求后,处理失败的任务会由您的 worker 进行重试。
  • 机密信息和完整的客户有效载荷不会被写入应用程序日志。