可靠的 HTTP 事件投遞

接收端短暫失敗,不該讓事件直接消失。

把事件發布到 topic,MsgMesh 主動 POST 到你的端點。暫時性失敗會重試;永久失敗或重試用盡後進入死信佇列,修正後可重放。

投遞流程

先儲存事件,再面對不可靠的網路。

發布到 topic

你的服務只需完成一次 HTTP 發布,不必同步等待每一個外部端點。

平臺投遞 Webhook

Webhook 繫結整個 topic;每一則新事件會 POST 到註冊的公開端點。

按失敗型別處理

連線失敗、超時、限流與多數 5xx 會重試;明確拒絕內容的狀態碼會直接進入死信。

檢查並重放 DLQ

修正接收端後,把死信重放回原 topic;後續 Webhook 投遞會再次執行。

失敗分類

不是每個錯誤都值得重試。

情況處理你該做什麼
逾時、連線失敗、429、多數 5xx短暫重試,仍失敗則進入 DLQ讓端點快速回 2xx;長任務改成內部非同步處理。
400、404、410、413、422 等永久錯誤不重試,直接進入 DLQ修正 URL、payload 契約或接收端驗證後再重放。
3xx 轉址或位址安全檢查失敗不跟隨轉址;部分安全失敗會停用 Webhook註冊最終公開 URL,不要依賴轉址或私網位址。

簽章與冪等

驗證來源,也要防止重複副作用。

01

註冊時提供 secret

只有提供 secret 才會收到 X-MsgMesh-Signature;簽章不是預設開啟。

02

先驗證,再解析

以原始 request body 重算 HMAC。當前簽章沒有時間戳或 nonce,無法單獨防止重放攻擊。

03

業務寫入保持冪等

把你自己的事件 ID、訂單號或狀態遷移條件作為冪等鍵;不要假設每則只到一次。

延伸閱讀

先用一個會故意失敗的端點驗證流程。

確認重試、死信與重放,再接真正的業務系統。

檢視接入片段 →