GitHub的每一次代碼推送、Issue創(chuàng)建、PR合并，都會(huì)觸發(fā)一個(gè)Webhook事件。但把這些事件可靠地存下來(lái)，并不是加個(gè)URL那么簡(jiǎn)單——簽名驗(yàn)證錯(cuò)了，數(shù)據(jù)就是不可信的；存儲(chǔ)結(jié)構(gòu)僵化了，不同事件類型就會(huì)互相打架。

Centrali的處理方式是把配置粒度降到單個(gè)觸發(fā)器。每個(gè)來(lái)源有自己的簽名規(guī)則：GitHub用HMAC-SHA256，Stripe用復(fù)合頭部，Shopify、Twilio各有格式。不是全局一套配置硬套所有服務(wù)商。

GitHub的簽名放在x-hub-signature-256頭部，格式是sha256=前綴加64位十六進(jìn)制摘要。這和Stripe的t=...,v1=...復(fù)合結(jié)構(gòu)完全不同，也是為什么必須按觸發(fā)器配置驗(yàn)證規(guī)則的原因。

具體實(shí)現(xiàn)分三步。先在Centrali控制臺(tái)創(chuàng)建一個(gè)叫Store GitHub Event的函數(shù)，核心邏輯是提取頭部信息、解析payload、寫入無(wú)模式集合。無(wú)模式集合github-events需要提前創(chuàng)建——push事件和issues事件的字段結(jié)構(gòu)差異很大，固定schema會(huì)逼你不斷改表。

函數(shù)里取兩個(gè)關(guān)鍵頭部：x-github-event標(biāo)記事件類型，x-github-delivery是GitHub生成的唯一投遞ID。payload里的sender.login、action、repository.full_name是常用字段，但整個(gè)原始payload也要存，方便后續(xù)排查。

再到Triggers里新建觸發(fā)器，拿到一個(gè)公開URL：https://api.centrali.io/data/workspace/{your-workspace}/api/v1/http-trigger/github。把這個(gè)URL填進(jìn)GitHub倉(cāng)庫(kù)的Webhook設(shè)置里。

簽名驗(yàn)證的配置是關(guān)鍵步驟。打開"Validate Signature"，選擇HMAC-SHA256算法。高級(jí)設(shè)置里的提取正則sha256=(.+)會(huì)把前綴剝掉，只留摘要本身做比對(duì)。Secret填GitHub webhook設(shè)置里生成的密鑰。

注意GitHub的簽名頭部不帶時(shí)間戳，所以沒(méi)有內(nèi)建的防重放保護(hù)。如果需要，可以單獨(dú)開啟——Centrali會(huì)跟蹤x-github-delivery值，重復(fù)ID直接拒掉。

這套流程的通用性在于：函數(shù)邏輯不變，換別的服務(wù)商時(shí)只改觸發(fā)器的簽名配置。Stripe要配復(fù)合頭部解析，Twilio可能用不同算法，但存儲(chǔ)函數(shù)可以復(fù)用。

調(diào)試建議：先在GitHub webhook設(shè)置里看投遞歷史，確認(rèn)簽名驗(yàn)證通過(guò)、響應(yīng)200。再去Centrali的函數(shù)日志里核對(duì)recordId和事件類型是否匹配。如果存的是unknown，檢查頭部名稱有沒(méi)有大小寫問(wèn)題——有些代理會(huì)改寫頭部。

整個(gè)搭建過(guò)程在免費(fèi)workspace里就能跑通，不需要部署任何基礎(chǔ)設(shè)施。對(duì)于需要審計(jì)代碼變更、做自動(dòng)化工作流的團(tuán)隊(duì)，這是比直接接GitHub API更輕量的方案——事件推過(guò)來(lái)就存，不丟數(shù)據(jù)，不反復(fù)輪詢。