gRPC vs REST в iGaming
1） iGaming上下文： 为什么要完全选择协议
iGaming平台同时服务：- 实时：系数跳动、轻量级投注、优惠券/比赛状态流、玩家限制、即时锁定；
- 交易：存款/提取，费率计算，奖金，KYC/AML，支持提要；
- 合作伙伴/B2B集成：游戏提供商、支付网关、关联公司、监管机构。
P99潜伏期，峰值下的稳定性（比赛，决赛），集成的便利性和运营成本取决于协议。
2）简要： 什么是REST和gRPC
REST/HTTP/JSON：人性化、普遍性。与浏览器/移动SDK完美配合,由CDN缓存,易于借记。
gRPC （HTTP/2+Protobuf）：二元合同、客户自动生成、uni/bi-directional流媒体、多路复用、严格方桉。网络上的服务k服务是他的元素。
3）在iGaming中合适的地方
gRPC-强项
轻量级和跟踪： 流的系数,比赛事件,限制（服务器流/bidi）.
内部微服务：风险引擎，报价器，防冻计分，平衡/钱包-p99/CPU要求。
短消息大型RPS周转（字节价格低，GC-pressure小）。
命令和版本之间的严格合同（带有反向匹配的Protobuf）。
REST-强项
公共和合作伙伴API：简单集成（curl/Postman）,没有gRPC堆栈的合作伙伴。
浏览器前端：本地，无代理；缓存支持/ETag/304/CDN。
长期资源：游戏目录、配置文件、报告和配置。
监管卸载：JSON/CSV兼容性无网关。
4）潜伏期和吞吐量
gRPC在有效载荷大小（Protobuf）和序列化/去序列化成本方面更经济，在短暂且频繁的呼叫中获胜。
REST/JSON在有效载荷上增加了30％至200％，但通过在公共GET上悬挂和CDN获胜。
建议：DC/服务间内部-默认的gRPC；外部-REST，除了实时。
5）实时： 大价和报价
选项：- gRPC server streaming/bidi：用于更新、背压、窗口控制的恒定线程。
- 如果需要前面的二进制协议，则浏览器的gRPC-Web（通过Envoy）。
- WebSocket/SSE+REST：当gRPC-Web生态系统不合适或需要没有代理的纯浏览器时。
模式：内部-从报价商到API网关/边缘的gRPC流；向外-前部的WebSocket/SSE，CRUD的REST。
6）交货的适航性，顺序和保证
REST："Idempotency-Key"在网关上进行开机自检，在定时时重新提交；关键是Redis/DB c TTL。
gRPC：客户端/平衡器级别的转发+等效方法（"retrible_status_codes"）和流媒体消息中的序列/转发。
要计算费率,请使用Inbox/Outbox+UPSERT（请参阅有关重复数据消除和顺序的文章）-协议本身不提供业务效果保证。
7）安全和合规性
运输：TLS/mTLS在混乱中和边缘；在gRPC中，更容易在任何地方保持mTLS（SPIFFE/SPIRE）。
身份验证：两个变体都支持OAuth2/OIDC（"授权：啤酒"中的JWT），gRPC支持元数据。
签名/NMAS：在B2B的REST积分中更为常见。
PII/Loging：二进制gRPC payload gRPC更难意外"泄露"到日志中,但无论如何都使用伪装。
调节器通常需要人工卸载-REST/JSON更方便。
8）可观察性和操作
两种格式都可以完美地与OpenTelemetry配合："traceparent"（REST ）/gRPC介质。
gRPC提供丰富的状态/预告片；REST是熟悉的HTTP代码和CDN/WAF分层。
在网关上：rate limiting/quota, circuit breaker, outlier detection, fault injection-同样可用（Envoy/Kong/NGINX/Traefik）。
9）兼容性和前线
纯浏览器不使用→ gRPC-Web或REST/WS/SSE开箱即用的gRPC。
移动客户端（iOS/Android）-gRPC客户端可用，但SDK大小和堆栈策略有时会推向REST。
10）混合周边建筑模式
10.1"双立面"策略"
内部（东西部）：gRPC。
向外（南北）：REST+WS/SSE。
边缘转码（Envoy）：一个后端,两个客户端。
yaml
Envoy: REST ↔ gRPC transcoding (фрагмент)
typed_per_filter_config:
envoy.filters.http.grpc_json_transcoder:
"@type": type.googleapis.com/envoy.extensions.filters.http.grpc_json_transcoder.v3.GrpcJsonTranscoder proto_descriptor: "descriptors.pb"
services: ["betting.BetsService"]
print_options:
preserve_proto_field_names: true10.2 gRPC-Web
浏览器→ Envoy（gRPC-Web）→ gRPC服务。方便现场小部件和阿德明UI。
11）合同和API的演变
Protobuf (gRPC)
仅扩展消息（添加带有新标记的字段）,不要更改语义和类型。
proto syntax = "proto3";
package betting;
service BetsService {
rpc PlaceBet(PlaceBetRequest) returns (PlaceBetResponse);
rpc LiveOdds(EventsFilter) returns (stream OddsUpdate); // серверный стрим
}
message PlaceBetRequest {
string account_id = 1;
string event_id = 2;
double stake = 3;
string selection = 4;
string idempotency_key = 5;
}OpenAPI (REST)
在"/v1"路径上进行转化，新字段仅可选。
yaml openapi: 3.0.3 info: { title: Bets API, version: "1.0" }
paths:
/v1/bets:
post:
operationId: placeBet parameters:
- in: header name: Idempotency-Key required: true schema: { type: string }
requestBody:
required: true content:
application/json:
schema:
$ref: '#/components/schemas/PlaceBetRequest'
responses:
'201': { description: Created }
components:
schemas:
PlaceBetRequest:
type: object required: [accountId, eventId, stake, selection]
properties:
accountId: { type: string }
eventId: { type: string }
stake: { type: number, format: double }
selection: { type: string }12） iGaming桉例： 选择什么
13）生产细微差别
Taymauts/Retrai
gRPC："per_try_timeout"，限制"max_attempts"，仅针对幂等的RPC。
REST：指数后端，摇杆，429/5xx网关策略。
物体/方法限制
REST：查询大小限制，"内容类型"验证。
gRPC：限制消息大小,流控。
Keshing
REST: `Cache-Control`, `ETag`.
gRPC： 应用程序/网关级别的kesh（用于unary），对于strims是snapshots/sles.
可观察性
强制性：相关性原理（request id）, spanes,路线/方法错误度量,p50/p95/p99分布。
14）反模式
"在gRPC上重写所有内容"并尝试直接放弃前端-如果没有gRPC-Web/代理,它将破坏浏览器。
只有gRPC的公共网络端口-合作伙伴将退出。
通过REST-polling流式传输-网络/培根过热和慢速报价。
在客户级别上重新安排非偶数交易（创建费率/付款）。
依靠物理时间来排序事件而不是版本/序列。
15）协议选择支票清单
- 实时流量还是CRUD/合作伙伴流量?
- 客户-浏览器/合作伙伴或微服务/移动SDK?
- 需要流媒体（服务器/bidi）?
- 是否需要周边的CDN/腰果?
- 哪个p99 SLO和错误预算?
- 监管机构是否对报告格式（JSON/CSV）有要求？
- 是否定义了幂等和重复数据消除计划?
- 与API 网关/mesh的集成已准备就绪（mTLS、限制、广播）?
- 审批和互操作性战略是否获得批准？
- Dashbords/Alerts和Match Day Peaks的测试花花公子准备好了吗？
16）迷你花花公子（游戏日）
比赛高峰：翻倍RPS live-fids →评估p99和消息丢失（流）。
提供商的失败：apstrim的下降-CB/outlier必须清除，前端必须降级到最后一个狙击手。
网关倒退：禁用gRPC↔REST广播-确保后退（WS/SSE）正在运行。
网络延迟/WAN：人为地提高RTT, →测试Timout和Backoff的适应性。
Big Body （KYC）：检查限制/多次下载,总结。
17）结果
集群内部：gRPC是性能、严格合同和流媒体的违约。
在外围：REST（和实时UI的WS/SSE）是广泛兼容的默认。
我们通过API网关（转码、限制、身份验证）和服务mesh （mTLS,流量策略）缝合世界。
成功在于具有清晰界限的混合体系结构：内部流/低潜伏性，外部便利性和多功能性。