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,流量策略）縫合世界。
成功在於具有清晰界限的混合體系結構：內部流/低潛伏性，外部便利性和多功能性。