加密赌场

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、转换、签名和可观察性-并获得一个体系结构,其中资金可以快速安全地移动,事件不会丢失,升级不会无痛地进行。