gRPC vs REST в iGaming

1) iGaming კონტექსტი: რატომ უნდა აირჩიოთ ოქმი

• რეალური დრო: კოეფიციენტების ფიდები, მსუბუქი განაკვეთები, კუპონის/მატჩის სტატუსის ნაკადი, მოთამაშის ლიმიტები, მყისიერი დაბლოკვა;
• გარიგებები: ანაბარი/გამომავალი, განაკვეთების გაანგარიშება, პრემიები, KYC/AML, მხარდასაჭერად თიკეტები;
• / B2V ინტეგრაცია: თამაშების პროვაიდერები, გადახდის კარიბჭეები, აფილატები, რეგულატორები.

P99 ლატენტობა, მწვერვალების ქვეშ სტაბილურობა (მატჩები, ფინალები), ინტეგრაციის მოხერხებულობა და ოპერაციის ღირებულება დამოკიდებულია ოქმზე.

2) მოკლედ: რა არის REST და gRPC

REST/HTTP/JSON: ადამიანური, უნივერსალური. ის კარგად მუშაობს ბრაუზერებთან/მობილურ SDK- სთან, ახდენს CDN- ს ქეშირებას, ადვილად დადის.
GRPC (HTTP/2 + Protobuf): ორობითი კონტრაქტები, მომხმარებლის ავტომატური წარმოება, uni/bi directional ნაკადი, მულტიპლექსაცია, მკაცრი სქემები. ქსელის მომსახურება მისი ელემენტია.

3) სად არის შესაფერისი iGaming

GRPC - სიძლიერე

Live fids და tracking: კოეფიციენტების ნაკადი, მატჩის მოვლენები, ლიმიტები (streaming/bidi სერვერი).
შიდა მიკრო სერვისები: რისკის ძრავა, ციტატორი, ანტიფროდის სკორინგი, ბალანსი/საფულე - მოთხოვნები p99/CPU.
RPS- ის დიდი ბრუნვა მოკლე შეტყობინებებით (ბაიტის დაბალი ფასი, მცირე GC-pressure).
მკაცრი კონტრაქტები გუნდებსა და ვერსიებს შორის (Protobuf backward compat- ით).

REST - ძლიერი მხარეები

საზოგადოებრივი და პარტნიორი API: მარტივი ინტეგრაცია (curl/Postman), პარტნიორები grRPC დასტის გარეშე.
ბრაუზერის ფრონტი: nationaly, მარიონეტული გარეშე; ქეში/ETag/304/CDN მხარდაჭერა.
გრძელი რესურსები: თამაშების კატალოგები, პროფილები, მოხსენებები, კონფიგურაცია.
მარეგულირებელი გადმოტვირთვები: JSON/CSV თავსებადობა კარიბჭეების გარეშე.

4) ლატენტობა და გამტარუნარიანობა

GRPC უფრო ეკონომიურია, ვიდრე დატვირთვის ზომა (Protobuf) და სერიალიზაციის/დესერალიზაციის ხარჯები, იმარჯვებს მოკლე და ხშირი გამოწვევებით.
REST/JSON ემატება 30-200% დატვირთვას, მაგრამ იმარჯვებს ქეშით და CDN- ით საზოგადოებრივ GET- ზე.

რეკომენდაცია: DC/offservice შიგნით - gRPC ნაგულისხმევი; გარედან - REST, გარდა რეალურ დროში.

5) ნამდვილი დრო: მსუბუქი განაკვეთები და ციტატები

• GRPC server streaming/bidi: მუდმივი განახლების ნაკადი, backpressure, ფანჯრის კონტროლი.
• GRPC-Web (Envoy- ს მეშვეობით) ბრაუზერისთვის, თუ ფრონტზე ორობითი პროტოკოლი გჭირდებათ.
• WebSocket/SSE + REST: როდესაც GRPC-Web ეკოსისტემა არ არის შესაფერისი ან საჭიროა სუფთა ბრაუზერი მარიონეტული გარეშე.

პატრონი: შიგნით - GRPC ნაკადები ციტატორიდან API კარიბჭემდე/edge; გარეთ - WebSocket/SSE წინა, REST CRUD- ისთვის.

6) საკუთრების, წესრიგისა და მიწოდების გარანტიები

REST: 'Idempotency-Key' POST- ისთვის კარიბჭეზე, მეორე მომსახურება ტაიმაუტით; გასაღები - Redis/BD c TTL.
GRPC: retrais კლიენტის/დაბალანსების დონეზე + imempotent მეთოდები ('retriable _ status _ codes') და sequence/ვერსია ნაკადის შეტყობინებებში.
განაკვეთების გამოსათვლელად, გამოიყენეთ Inbox/Outbox + UPSERT სინქრონზე (იხ. სტატიები დედაპლაციის და პროცედურის შესახებ) - თავად პროტოკოლი არ იძლევა გარანტიებს ბიზნეს ეფექტზე.

7) უსაფრთხოება და შესაბამისობა

ტრანსპორტი: TLS/mTLS როგორც მასაში, ასევე edge; GRPC ადვილია ყველგან mTLS (SPIFFE/SPIRE) შენარჩუნება.
ავთენტიფიკაცია: ორივე ვარიანტი მხარს უჭერს OAuth2/OIDC (JWT 'Authorization: Bearer'), GRPC- სთვის - მეტამონაცემები.
ხელმოწერები/NMAS: უფრო ხშირად REST ინტეგრაციებში B2B.
PII/ლოჯისტიკა: ორობითი payload gRPC უფრო რთულია შემთხვევით „დაასხით“ ლოგოებში, მაგრამ გამოიყენეთ შენიღბვა ნებისმიერ შემთხვევაში.
რეგულატორები ხშირად მოითხოვენ ადამიანის გადმოტვირთვას - REST/JSON უფრო მოსახერხებელია.

8) დაკვირვება და ექსპლუატაცია

ორივე ფორმატი მშვენივრად მუშაობს OpenTelemetry: 'traceparent' (REST )/gRPC ინტერსეპტორები.
GRPC იძლევა მდიდარ სტატუსებს/ტრეილერებს; REST არის ჩვეულებრივი HTTP კოდები და CDN/WAF ფენები.
კარიბჭეზე: rate limiting/íta, circuit breaker, outlier detection, foult injection - თანაბრად ხელმისაწვდომია (Envoy/Kong/NGINX/Traefik).

9) თავსებადობა და ფრონტი

სუფთა ბრაუზერი არ ამბობს gRPC ყუთიდან - gRPC-Web ან REST/WS/SSE.
მობილური მომხმარებლები (iOS/Android) - gRPC კლიენტები ხელმისაწვდომია, მაგრამ SDK ზომა და ნაკადის პოლიტიკა ზოგჯერ REST- ს უბიძგებს.

10) შერეული პერიმეტრის არქიტექტურული ნიმუშები

10. 1 „ორმაგი ფასადის“ სტრატეგია

შიგნით: gRPC.
გარედან (ჩრდილოეთ სამხრეთი): REST + WS/SSE.
ტრანსკოდინგი edge (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: true

10. 2 gRPC-Web

ბრაუზერი - Envoy (grRPC-Web) - grRPC სერვისი. მოსახერხებელია ცოცხალი ვიჯეტებისა და Admin 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) წარმოების ნიუანსი

Taimauty/retrai

GRPC: 'per _ try _ timeout', შეზღუდეთ 'max _ attempts', retrais მხოლოდ idempotent RPC- სთვის.
REST: ექსპონენციალური backoff, jitter, 429/5xx პოლიტიკა კარიბჭეზე.

სხეულის შეზღუდვა/მეთოდი

REST: მოთხოვნის ზომების შეზღუდვები, 'შინაარსის ტიპი' შესაბამისობა.
GRPC: შეტყობინებების ზომების შეზღუდვები, ფრენის კონტროლი.

კეშირება

REST: `Cache-Control`, `ETag`.
GRPC: ქეში განაცხადის/კარიბჭის დონეზე (უნარისთვის), ნაკადებისთვის - სნაიპშოტები/ნაჭრები.

დაკვირვება

სავალდებულოა: კორელაციის ლოგო (request id), სპანი, შეცდომების მეტრიკა მარშრუტზე/მეთოდით, განაწილება p50/p95/p99.

14) ანტი შაბლონები

„გადაწერა ყველაფერი GRPC- ზე“ და შეეცადეთ პირდაპირ ფრონტზე გადასცეს - gRPC-Web/მარიონეტული გარეშე, ეს დაარღვევს ბრაუზერს.
მხოლოდ GRPC-om საჯარო ვებ - endpoints - პარტნიორები იმედგაცრუებულნი იქნებიან.
REST ნახევრის საშუალებით მსუბუქი ფიდების გაჭრა არის ქსელის/ბეკანდის გადატვირთვა და ნელი ციტატები.
კლიენტის დონეზე გადააკეთეთ არაიდემპოტენტური ოპერაციები (განაკვეთის/გადახდის შექმნა).
დაეყრდნოს ფიზიკურ დროს მოვლენების წესრიგისთვის, ვერსიების/სექციის ნაცვლად.

15) პროტოკოლის არჩევის ჩეკის სია

• რეალისტური ან CRUD/პარტნიორი ტრაფიკი?
• კლიენტები - ბრაუზერი/პარტნიორები ან მიკრო სერვისები/მობილური SDK?
• საჭიროა ნაკადი (სერვერი/ბიდი)?
• საჭიროა CDN/ქეში პერიმეტრზე?

რა არის SLO p99 და შეცდომების ბიუჯეტი?

• არსებობს რეგულატორის მოთხოვნები საანგარიშო ფორმატებისთვის (JSON/CSV)?

განსაზღვრულია იდემპოტენტურობისა და ბაბუის გეგმა?

• ინტეგრაცია API კარიბჭესთან/mesh მზად არის (mTLS, ლიმიტები, მაუწყებლობა)?

დამტკიცებულია ვერსიისა და თავსებადობის სტრატეგია?

• Dashbords/alerty და სატესტო playbuks მზად არიან მატჩის დღის მწვერვალებისთვის?

16) მინი ფლეიბუკები (თამაშის დღეები)

მატჩის მწვერვალი: გაორმაგდეს RPS Live fids და შეაფასოს p99 და შეტყობინებების დაკარგვა (ნაკადები).
პროვაიდერის წარუმატებლობა: აფსიდის ვარდნა - CB/outlier უნდა შემცირდეს, ფრონტი - დეგრადაცია ბოლო Snapshot- ზე.
კარიბჭის რეგრესია: გამორთეთ gRPC - REST მაუწყებლობა - დარწმუნდით, რომ fallback (WS/SSE) მუშაობს.
ქსელის შეფერხებები/WAN: ხელოვნურად ამაღლება RTT - შეამოწმეთ ტაიმაუტების ადაპტაცია და backoff.
დიდი სხეულები (KYC): შეამოწმეთ ლიმიტები/განმეორებითი დატვირთვები, შეაჯამეთ.

17) შედეგები

კლასტერის შიგნით: gRPC - ნაგულისხმევი პროდუქტიულობის, მკაცრი კონტრაქტებისა და ნაკადისთვის.
პერიმეტრზე: REST (და WS/SSE რეალურ დროში UI) - ნაგულისხმევი ფართო თავსებადობისთვის.
ჩვენ სამყაროებს ვაწყობთ API კარიბჭის საშუალებით (ტრანსკოდინგი, ლიმიტები, ავთენტიფიკაცია) და სამსახურის მესა (mTLS, ტრაფიკის პოლიტიკა).
წარმატება - შერეულ არქიტექტურაში მკაფიო დემარკაციით: ნაკადი/დაბალი ლატენტობა შიგნით, მოხერხებულობა და მრავალფეროვნება გარეთ.