REST, gRPC և Webhuks iGaming: pattern և anti-pattern

Հոդվածի ամբողջական տեքստը

💡 18+. Նշված նյութը iGaming-ի սննդի և ինժեներական թիմերի համար։ Խաղի կոչը չէ։ «Պլատֆորմի» տակ նկատի ունենք PAM/դրամապանակ/դրամարկղ/բոնուսներ/RG։ Պրովայդերը RGS/112/ջեկպոտներ/ագրեգատորներ է։

1) Քարտեզագրություն. Ո՞ վ է պատասխանատու դրա համար

REST-ը HTTP/JSON համընդհանուր համաժամանակյա հարցումներ է։ Թափանցիկ քեշը, պարզ կարգաբերումը, հարմար է B2B ինտեգրման և Admin-API-ի համար։

GRPC-ը բարձր արտադրողական երկուական RPC-ն է HTTP/2-ի վերևում 'ցածր լատենտ, ստրիմա, կոշտ սխեմաներ։ Լավ է տաք դրամական ճանապարհների համար (wallet/settle), ներքին ծառայությունները և երկարատև ստրիմները (108)։

Webhuki-ը հետադարձ զանգեր է (callback) ստացողից ուղարկողին։ Օգտագործվում են իրադարձությունների համար («գումար ընկավ», «սահմանը աշխատում էր»), որտեղ նախաձեռնողը միշտ չէ, որ սպասում է արդյունքին։

Ոսկու կանոնը

Գումարները գնում են սինխրոն RPC (REST/gRPC), կոշտ ինվարիանտներով և գաղափարախոսությամբ։ Telemetria և բիզնես իրադարձությունները ասինխրոնո են (webhuks + իրադարձությունների անվադողեր)։

2) Տիպիկ ճանապարհներ և չարտոնված ջրանցքներ

Ճանապարհ	Ռոտանոն	Ինչու՞
`bets. authorize` (hold)	GRPC (ներսում )/REST (B2B)	նվազագույն լատենտ, խիստ SLA
`bets. settle` → `wallet. credit`	GRPC սինխրոն + իրադարձություն անվադողերի	փողը = ACID; իրադարձություններ = դիտարկելիություն
`cashier. deposit/withdraw`	REST + idempotent	ինտեգրումը PSA-ի հետ, թրեյսինգը
`RG check / stop`	GRPC/REST սինխրոն	stop ազդանշանները պետք է անմիջապես աշխատեն անմիջապես
`bonus. issue/consume`	REST սինխրոն	բիզնես տրամաբանություն, չափավոր SLA
`jackpot. trigger/payout`	GRPC/REST + իրադարձություն	դրամավարկային պայմանագիր + աուդիտ
Թելեմետրիա, վերլուծություն, ալտերտներ	Webhuki + shina (Kafka/Pulsar)	կայունություն և մասշտաբներ
Ռուսական կարգավիճակը/2019	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 (www.obuf, պարզեցված)

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 Webhuki (օրինակ 108)


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» write վիրահատությունների վրա (REST/gRPC metadata)։ Խոհարարը հաստատեց նույն պատասխանը։

Ստեղնաշարի իրականացումը կապված է բիզնես պարամետրերի հետ (օրինակ ՝ «bet _ id + amount»)։

Սագին երկար գործընթացների համար (authorize no commit/no settle no credit)։
Windobox/CDC։ Իրադարձությունները արձանագրվում են ատոմային մեքենայի կողքին և հրապարակվում են դրսից։

5) Տարբերակումը և համատեղելիությունը

REST-ը '

SemVer: minor - optional/նոր endpoinae դաշտերը; major - նոր ճանապարհ/փաթեթ, «կրկնակի նամակ» իրադարձությունների վրա։

Երբեք մի փոխեք դրամավարկային ստատուսների սեմանտիկան առանց major տարբերակի։

6) Տրանսպորտի անվտանգությունը

MTSA-ը բոլոր S2S-ում; Webhuks-ը մարմնի ստորագրությունն է (HMAC/EdDSA) + timestamp և valiving պատուհանները։

Սկոպների սահմանափակումը (OAuth2 CC) և per brand/region հատվածը։

Zero-trust: Ցանցային քաղաքականություններ, կարճ հոսանքներ, Vox/HSM, WORM-աուդիտ քննադատական գործողությունների։

7) Դիտարկումը և SLO-ն

«Trace _ id» -ի միջոցով REST, gRPC metadata և webhuks-ում։

Մետրիկները ՝ p50/p95/p99 latency, error rate կոդերով, throughput, lag։
SLO-նվազագույն (կենտրոններ)

Wallet p95 '<150 ms «(Authorize/Settle), REST հանրային B2B p95' 300 ms», Webhuki-ը հանձնվել է <<5 րոպե '99-րդ percentil, «Կորցրած/կրկնվող ցանցեր» = 0։

8) Retrai, backoff և առաքման կարգը

REST/gRPC 'էքսպոնենցիալ backoff, ջիտթեր, տևողության սահմանափակում (deadom/timeout)։

Ուեբհուկի 'կրկնվող առաքումը մինչև «2xx»; հրամանի պահպանումը բանալին («player _ id/round _ id») կամ ստացողի վրա դեդուպլիկացիա։
Անտի փոթորիկները 'զուգահեռ գետերի սահմանը, circuit breaker, rate limit։

9) Patterns

Pattern A '«Փողը սինխրոն է, իրադարձությունները ասինխրոն են»

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

2. Զուգահեռ հրապարակում է «bet»։ settled 'անվադողերի մեջ, իսկ պրովայդերը ստանում է webhuk-quitancia։

Գումարած 'արագ գումար, դիտարկումը։ Մինուս 'անհրաժեշտ է երկու ռուբլիներ։

Pattern B: «Streaming 112»

Core-միջուկը Bridge-ը gRPC streaming-ի միջոցով (սեղանի արձանները, պատուհանը)։

Դրամական վիրահատությունները 'առանձին unary RPC; իրադարձությունները 'անվադողերի/վեբհուկի մեջ։
Գումարած 'կենդանի կարգավիճակների նվազագույն ուշացումը։

Pattern C: «B2B հանրային REST»

System/affiliats/զեկույցները REST են cursor-pagination, ֆիլտրեր, ETag։

Գումարած 'գործընկերների պարզ ինտեգրումը։

10) Anti-patterns (կարմիր դրոշներ)

Դրամական վիրահատությունները միայն վեբհուկի միջոցով (առանց սինխրոն հաստատման)։

«Idempotency-Key» -ի բացակայությունը բացատրում է բանավեճի/վարկերի կրկնությունը։
Իրադարձությունների հրապարակումը շրջանցելով www.box/CDC (կորցնում են իրադարձությունները)։
Webhuks առանց ստորագրության/ժամանակավոր փոխարինման։
PII/տարբեր տարածաշրջանների փողի խառնուրդը մեկ ալիքի մեջ առանց «region/tenae» պիտակների։
Մեծ binary payload-ը Webhuks-ում (կոտրում են retras և limits)։
Զրոյական դեգրադացիաներ. Վեբհուկի անկումը արգելափակում է փողի հաշվարկը։
GRPC-ն առանց deadom և առանց backoff-ը կախված միացություններ են, ռեսուրսների սպառումը։

11) Չեկ թերթերը

Ճարտարապետը/պլատֆորմը

Փողը gRPC/REST-ի վրա 'գաղափարախոսությամբ, իրադարձություններով' webhuki/անվադողերով։
Delbox/CDC բոլոր դրամական ճանապարհների վրա։
`/vN` и schema registry; Deprecation/Sunset գործընթացը։
mTSA + webhuks ստորագրություն; per brand/region հատվածներ։
SLO-dashbords p95/p99, error rate, webhook-lag։
DR/xaoc ուսուցումները 'դուբլ առաքումը, out-of-order, շեղեց տարածաշրջանները։

Պրովայդեր/RGS

Ես ուղարկում եմ "X-Trace-Id 'և" X-Idempotency-Key "։
Retrai backoff և deduplication; պատրաստ է Webhuks-ի ֆինանսական առաքմանը։
Թարմացնում եմ կոդավորման տարբերակները; արձագանքում եմ «Deprecation/Sunset» -ին։
Logs/metriks սխալների և ժամանակի կոդերի վրա։

12) Սուր դեպքերի համար մինի լուծումներ

Safari/ITP-ը և third-party սահմանափակումները 'գումարը (REST/gRPC), iFrame բովանդակությունը հաղորդակցվում է «PostLine» -ի միջոցով։ webooks հոստից, ոչ iFrame-ից։

Multibrend: Tegi 'id _ id/brand _ id/license "վերնագրերում և իրադարձություններում։ բանալիներ/հավաստագրեր առանձին։

Մեծ բարձրացումներ (արբիտր) 'Webhuks-ի առջև' bufer/հերթը DLQ-ից; ծանրաբեռնվածության դեպքում '«new sessions »/» pause non-inthooks»։

13) SLO կողմնորոշված ալերտների օրինակները

Wallet. Authorize p95> 150 ms 5 րոպե անընդմեջ։

Սխալները 'DUPLICATE/IDEMPOTENCY _ MISMATCH'> 0։ Հինգ տոկոսը 10 ռուբլիով

Webhook lag p99> 180 c թեմայի մասին։ settled`.

Consumer lag-ում Kafka> 30-ի համար 'wallet-ի համար։ credit.`.

14) Եզրակացություն

REST, gRPC և webhuks iGaming-ում ոչ թե փոխկապակցված տեխնոլոգիաներ են, այլ մեկ վիրահատական մոդելի մասեր։

REST/gRPC-ն պահպանում է դրամական ինվարանտներ 'ցածր լատենտություն, գաղափարախոսություն, խիստ SLA։

Webhuki/անվադողերը ապահովում են թափանցիկություն և մասշտաբներ ՝ իրադարձություններ, հեռաչափություն, ռուսական։
Ավելացրեք box/CDC, տարբերակումը, ստորագրությունը և դիտարկումը, և կստանաք ճարտարապետություն, որտեղ փողը արագ և ապահով է շարժվում, իրադարձությունները չեն կորչում, իսկ ապգրադները անցնում են անօգուտ։