加密賭場

Torrent Gear

IGaming中的REST，gRPC和webhooks：模式和反模式

文章全文

💡 18+.iGaming產品和工程團隊的技術材料。不打電話。「平臺」是指錢包/現金/獎金/RG。「提供商」-RGS/live/頭獎/聚合器。

1）協議圖： 誰負責什麼

REST是通過HTTP/JSON進行的通用同步請求。B2B集成和admin-API易於使用,易於調試。

gRPC是一種高性能的二進制RPC，位於HTTP/2之上：低潛伏度，流道，剛性電路。有利於熱現金（錢包/設置），內部服務和長壽流（實時）。

Webhooks是從收件人到發件人的回調（回調）。用於事件（「現金下降」，「限額工作」），其中發起者並不總是等待結果的人。

黃金規則：

這筆錢是通過具有剛性不變性和等效性的同步RPC（REST/gRPC）進行的。遙測和業務事件-異步（webhooks+事件總線）。

2）示範路徑和推薦通道

路徑	建議采取的行動	為什麼
`bets.authorize` (hold)	gRPC （內部）/REST （B2B）	最小潛伏期,嚴格SLA
`bets.settle` → `wallet.credit`	gRPC同步+總線事件	金錢=ACID；事件=觀察性
`cashier.deposit/withdraw`	REST+等效性	與PSP集成,tracing
`RG check / stop`	gRPC/REST同步	停止信號必須立即啟動
`bonus.issue/consume`	REST同步	商業邏輯，適度SLA
`jackpot.trigger/payout`	gRPC/REST+事件	現金合同+審計
遙測，分析，Alertes	Webhuki+總線（Kafka/Pulsar）	可持續性和規模
Live狀態/目錄	gRPC streaming / Server-Sent Events	盡量減少民意測驗和滯後

3）以合同為導向的設計

3.1 REST（片段）


POST /v1/bets/authorize
Headers: X-Idempotency-Key: bet_r_8c12_1, X-Trace-Id: tr_a1b2
{
"session_id":"s_456",  "bet_id":"b_001",  "round_id":"r_8c12",  "amount":{"amount":2.00,"currency":"EUR"}
}
→ 200 {"status":"authorized","hold_id":"h_zz1"}

錯誤（單一模式）：


409
{"code":"DUPLICATE","message":"Bet already authorized","retryable":false,"trace_id":"tr_a1b2"}

3.2 gRPC（protobuf，簡化）

proto syntax = "proto3";
package wallet.v1;

message Money { int64 minor_units = 1;string currency = 2; } // cents message AuthorizeBetReq { string session_id=1;string bet_id=2;string round_id=3;Money amount=4;string idempotency_key=5; }
message AuthorizeBetRes { string status=1;string hold_id=2; }

service Wallet {
rpc AuthorizeBet(AuthorizeBetReq) returns (AuthorizeBetRes);
rpc SettleBet(SettleReq) returns (SettleRes);
}

3.3 Webhooks（訂閱示例）


POST https://provider.example/webhooks
{
"topic":"wallet.credit.ok",  "callback_url":"https://rgs.example/journal",  "secret":"", "version":"1.2"
}

交貨：


POST https://rgs.example/journal
Headers: X-Signature: sha256=..., X-Trace-Id: tr_a1b2
{
"event_type":"wallet.credit.ok",  "schema_version":"1.2.0",  "event_id":"uuid",  "payload":{"player_id":"p_19f3","amount":{"minor_units":1460,"currency":"EUR"}}
}

4）相同性和一致性

在寫操作中始終需要「X-Idempotency-Key」（REST/gRPC metadata）。重播→相同的響應。

密鑰組成與業務參數（例如「bet_id+amount」）相關聯。

長過程傳奇（authorize → commit/lock → settle → credit）。

Outbox/CDC：事件在事務旁以原子方式捕獲並從外部發布。

5）轉化與兼容性

REST-'/v1/……'+'Deprecation/Sunset'-sister；gRPC — `package wallet.v1`;事件-主體中的「schema_version」+模式註冊表。

SemVer：次要-選項/新端點字段；主要是新的路徑/軟件包，即遷移事件的「雙重寫作」。

切勿在沒有專業版本的情況下更改貨幣狀態的語義。

6）運輸安全

所有S2S的mTLS；webhooks-身體簽名（HMAC/EdDSA）+timestamp和有效性窗口。

漏洞限制（OAuth2 CC）和按品牌/區域按鍵分割。

零信任：網絡策略、短壽命令牌、Vault/HSM, WORM審核關鍵操作。

7）可觀察性和SLO

REST，gRPC metadata和webhook中的端到端「trace_id」。

度量標準：p50/p95/p99 latency，代碼錯誤率，throughput，lag隊列。

SLO最低（地標）：

Wallet p95'< 150 ms'（Authorize/Settle），REST公共B2B p95' <300 ms'，Webhooks交付了'<5 min' 99 percentil，「丟失/重復設置」=0。

8）Retrai，backoff和交付順序

REST/gRPC：指數後端，抖動，持續時間限制（最後期限/時間）。

Webhooks：可重復交付至「2xx」；保持按鍵（「player_id/round_id」）或接收器上的重復數據消除順序。

反風暴：平行靜修限制，巡回休息器，房價限制。

9）集成模式

模式A： 「金錢同步，事件異步」

1.RGS → Wallet (gRPC/REST) `authorize` → `settle/credit`.

2.並行出版'bet。設置為總線，提供商收到網絡包收據。

加：快速金錢，可觀察性。減：需要兩個輪廓。

模式B： 「Streaming live」

實時內核通過gRPC流式傳輸（桌子狀態，投註窗口）↔橋。

現金交易是單獨的unary RPC；事件-總線/webhooks。

另外：生活狀態的最小延遲。

模式C： 「B2B公共REST」

目錄/獎金/附屬機構/報告-REST具有讀取器分區，過濾器，ETag。

另外：簡單的合作夥伴集成。

10）反模式（紅旗）

僅通過webhooks進行現金交易（無同步確認）。

沒有「Idempotency-Key」 →借記/貸款。

發布繞過outbox/CDC的事件（事件丟失）。

沒有簽名/時間戳的Webhooks →替代。

將不同地區的PII/貨幣混合在一個沒有「區域/tenant」標簽的通道中。

網絡包中的大型二進制負載（打破後退和限制）。

零退化：webhook的下降阻止了金錢的計算。

gRPC沒有最後期限,沒有後端-掛起連接,資源耗盡。

11）支票單

建築師/平臺

通過gRPC/REST等效性賺錢，事件-webhooks/總線。
Outbox/CDC在所有現金路徑上。

[] `/vN` и schema registry;Deprecation/Sunset過程。

mTLS+webhook簽名；sextrects per brand/region。
SLO-dashbords p95/p99，error rate，webhook-lag。
DR/xaoc演習：雙重交付，出訂單，帶走了該地區。

提供商/RGS

發送「X-Trace-Id」和「X-Idempotency-Key」。
帶有後退和重復數據消除功能的Retrai；準備重新交付網絡手冊。
我更新合同版本；我對「Deprecation/Sunset」做出反應。
錯誤和時間代碼的邏輯/度量。

12）尖銳案例迷你解決方案

Safari/ITP和第三方限制：金錢-在主機上（REST/gRPC），iFrame內容通過「postMessage」進行通信；來自主機的webhooks，不來自iFrame。

多品牌：標題和事件中的「tenant_id/brand_id/license」標簽；鑰匙/證書分開。

大爆發（錦標賽）：在網絡包之前-具有DLQ的緩沖區/隊列；過載時-「no new sessions」/」pause non-core hooks」。

13） SLO定向Alert的示例

Wallet.Authorize p 95>150毫秒5分鐘。

錯誤'DUPLICATE/IDEMPOTENCY_MISMATCH'> 0.10分鐘5%

Webhook lag p99> 180 c關於'bet主題。settled`.

Kafka中的Consumer lag> 30 s for 'wallet。credit.`.

14）結論

iGaming中的REST，gRPC和webhooks不是可互換技術，而是同一操作模型的一部分。

REST/gRPC保持貨幣不變性：低潛伏率，等效性，嚴格SLA。

Webhooks/總線提供透明度和規模：事件，遙測，集成。

添加outbox/CDC、轉換、簽名和可觀察性-並獲得一個體系結構,其中資金可以快速安全地移動,事件不會丟失,升級不會無痛地進行。