GitHub的每一次代码推送、Issue创建、PR合并，都会触发一个Webhook事件。但把这些事件可靠地存下来，并不是加个URL那么简单——签名验证错了，数据就是不可信的；存储结构僵化了，不同事件类型就会互相打架。

Centrali的处理方式是把配置粒度降到单个触发器。每个来源有自己的签名规则：GitHub用HMAC-SHA256，Stripe用复合头部，Shopify、Twilio各有格式。不是全局一套配置硬套所有服务商。

打开网易新闻 查看精彩图片

GitHub的签名放在x-hub-signature-256头部，格式是sha256=前缀加64位十六进制摘要。这和Stripe的t=...,v1=...复合结构完全不同，也是为什么必须按触发器配置验证规则的原因。

具体实现分三步。先在Centrali控制台创建一个叫Store GitHub Event的函数，核心逻辑是提取头部信息、解析payload、写入无模式集合。无模式集合github-events需要提前创建——push事件和issues事件的字段结构差异很大，固定schema会逼你不断改表。

函数里取两个关键头部：x-github-event标记事件类型，x-github-delivery是GitHub生成的唯一投递ID。payload里的sender.login、action、repository.full_name是常用字段，但整个原始payload也要存，方便后续排查。

再到Triggers里新建触发器，拿到一个公开URL：https://api.centrali.io/data/workspace/{your-workspace}/api/v1/http-trigger/github。把这个URL填进GitHub仓库的Webhook设置里。

签名验证的配置是关键步骤。打开"Validate Signature"，选择HMAC-SHA256算法。高级设置里的提取正则sha256=(.+)会把前缀剥掉，只留摘要本身做比对。Secret填GitHub webhook设置里生成的密钥。

注意GitHub的签名头部不带时间戳，所以没有内建的防重放保护。如果需要，可以单独开启——Centrali会跟踪x-github-delivery值，重复ID直接拒掉。

这套流程的通用性在于：函数逻辑不变，换别的服务商时只改触发器的签名配置。Stripe要配复合头部解析，Twilio可能用不同算法，但存储函数可以复用。

调试建议：先在GitHub webhook设置里看投递历史，确认签名验证通过、响应200。再去Centrali的函数日志里核对recordId和事件类型是否匹配。如果存的是unknown，检查头部名称有没有大小写问题——有些代理会改写头部。

整个搭建过程在免费workspace里就能跑通，不需要部署任何基础设施。对于需要审计代码变更、做自动化工作流的团队，这是比直接接GitHub API更轻量的方案——事件推过来就存，不丢数据，不反复轮询。