Რატომ გადადის iGaming მიკრო სერვისებზე

სტატიის სრული ტექსტი

💡 18+. მასალა არის საგანმანათლებლო. არა თამაშის მოწოდება. ყურადღება გამახვილებულია არქიტექტურის შეცვლის საინჟინრო მიზეზებზე.

1) კონტექსტი: რატომ შეწყვიტა მონოლითმა მუშაობა

iGaming იზრდება შინაარსის, გეოგრაფიისა და რეგულაციების მიხედვით. მონოლითური კოდის ბაზა:

ანელებს რელიზებს (ზოგადი გამომცხვარი ფანჯრები, რეგრესიების რისკი), ცუდად მასშტაბური (საფულე და ფულადი სახსრები ცხელია, ხოლო CMS - ცივი), ხელს უშლის მოთხოვნების დაცვას (სხვადასხვა რეგულატორები - მონაცემთა სხვადასხვა წესები), ართულებს ფულის იზოლაციას (ფულის ყვავილები და პრემიები გადახლართულია).

შედეგი არის ინციდენტების მაღალი რისკები და ნელი დრო-ბაზარი.

2) რა იძლევა მიკრო სერვისის მიდგომას

1. კრიტიკული დომენების იზოლაცია. საფულე/Ledger, Cashier/PSP, Bonus Engine, Game Sessions, KYC/AML, RG, Risk/Fraud, Afffiliates, CRRM M- ცალკეული სერვისები - ცალკეული სერვისები მისი SLLLOOO- ით.

2. მოხმარების მასშტაბები. ცხელი სერვისები (საფულე, სალარო, სათამაშო სესია) უფრო მეტ რესურსს იღებენ მთელი კლასტერის გაძარცვის გარეშე.

3. დამოუკიდებელი გამოშვებები. ბრძანებები ასწორებენ თავიანთ ციკლს (კანარის გამოშვებები, feature დროშები).

4. გაუმართაობისადმი წინააღმდეგობა. ადგილობრივი დეგრადაცია არ იშლება მთელ პროდუქტს (cashier დეგრადაციას - თამაშები გრძელდება კეშებისა და რიგების გამო).

5. იურიდიული სეგმენტი. განსხვავება PII და რეგიონების გადასახადები (EU/UK/BR) და მონაცემთა რეზიდენცია.

6. ინტეგრაციის მოქნილობა. თამაშების პროვაიდერების, PSP და KYC პროვაიდერების პარალელური კავშირი.

3) ძირითადი სქემა (გამარტივებული)

Edge ფენა: API Gateway, WAF/bot დაცვა, rate limiting, geo ფილტრები.

დომენის მიკრო სერვისები: Wallet/Ledger, Bonus, Cashier, Game Gateway, Risk/Fraud, RG, KYC/AML, Affiliates, CRM MS S S aNaNEEUaNaNaNaNaNate, Red, Red, RUed, ReD ed

ღონისძიების საბურავი: Kafka/Pulsar - 'bet. placed`, `bet. settled`, `wallet. debit/credit`, `cashier. deposit. succeeded`, `rg. limit. hit`, `bonus. consumed 'და ა.შ.

მონაცემები: OLTP BD მომსახურებაზე, გარე/CDC-DWH (ClickHouse/BigQuery).

Observability: მეტრიკა/ლოგოები/ტრეისი; SIEM/SOAR; audit-log WORM.

4) ფული და მთლიანობა - რატომ არის ეს მიგრაციის გასაღები

მიკრო სერვისების მთავარი არგუმენტი ფულადი სახსრების მკაცრი იზოლაციაა:

ცალკეული Ledger მკაცრი ACID- ით და გუნდების idempotence, გრძელი პროცესების საგნები (ანაბრები, ქეშუტი, ბონუსის დარიცხვები), მოვლენების გარიგების + გარიგების გამოქვეყნება, ბალანსების „ხელით რედაქტირების“ ნულოვანი დაშვება.

ასეთი დიზაინი ამცირებს სეტლმენტების დაკარგვის/დუბლირების ალბათობას ნულამდე არქიტექტურულ დონეზე.

5) ნიმუშები, რომელთა გარეშეც მიკრო სერვისები არ დაფრინავს

CQRS + პროექცია. ბრძანებები - მკაცრად აფეთქების ღუმელის API- ს საშუალებით; კითხვა - პროექციის მოდელების საშუალებით.

Idempotency Keys. თითოეული ფულადი/ბონუსის გუნდი განმეორებულია გვერდითი მოვლენების გარეშე.

საგები და კომპენსაცია. აშკარა ანაზღაურებადი მოვლენები „BD გამოტოვების“ ნაცვლად.

Schema Registry. ღონისძიების კონტრაქტების ვერსია; მწარმოებლების/კონსიუმერების თავსებადობა.

Rate limits/Retry/Backoff. ქსელის გაუმართაობა ნორმაა; კლიენტის სტაბილურობა.

Zero-trust და საიდუმლოებები. mTLS შიგნით mesh, Vault/HSM, მინიმალური პრივილეგიები.

6) რა უფრო რთულია მიკრო სერვისებში (გულწრფელად მინუსების შესახებ)

ქსელი უფრო ძვირია, ვიდრე მეხსიერება. უფრო მეტი RPC, ლატარიის ზრდა და ინფრასტრუქტურის ღირებულება.

მონაცემთა სირთულე. თანმიმდევრულობა - ღონისძიება ლედგერას გარეთ, საჭიროა პროექციები.

დაკვირვება. გზაჯვარედინისა და SLO- ს გარეშე, ყველაფერი სწრაფად გადაიქცევა „შავ ყუთში“.

გუნდის დისციპლინა. ხელშეკრულების ტესტები, გამოშვების რიტუალები, სქემების მიგრაცია სავალდებულოა.

ჯვარედინი რეგიონალური ხარვეზები. მონაცემთა აღდგენა მოითხოვს გააზრებულ შარდვას.

თუ კომპანია არ არის მზად DevOps/SRE კულტურისთვის, მონოლითი „კარგი მოდულარობით“ შეიძლება უკეთესი იყოს.

7) ეტაპობრივი მიგრაცია: მონოლითიდან მომსახურებამდე

ნაბიჯი 1. სტანდარტიზებული მოვლენები. შეიყვანეთ საბურავი და ერთი ლექსიკონი: მოთამაშე, ფსონი, ნაკრები, ანაბარი, პრემია.

ნაბიჯი 2. გამოიტანეთ ლედგერი. ფულადი წრე გამოყოფილია პირველი: ცალკეული DD, API ბრძანებები, გარეთ.

ნაბიჯი 3. ჲჟრაგვრვ კაჟთპ. PSP ორკესტრი, კასკადები, 3-DS, კრიკეტები - როგორც დამოუკიდებელი მომსახურება.

ნაბიჯი 4. Game Gateway. ერთი კარიბჭე თამაშების პროვაიდერებს; სესიები/კოლბეკი - არა მონოლითის საშუალებით.

ნაბიჯი 5. Bonus Engine и RG. წესები, ვაჯერი, ლიმიტები - ავტონომიურად, საფულე/თამაშების მოვლენების გამოწერა.

ნაბიჯი 6. Risk/AML + KYC. ცალკეული კონტური მისი ინტეგრაციითა და ალერტინაციით.

ნაბიჯი 7. მონაცემები და BI. CDC DWH- ში, KPI ვიტრინები, ანტი-Excelite მოხსენებები.

ნაბიჯი 8. Back-office. RBAC/ABAC, აუდიტის ჟურნალი, „4 თვალი“ კრეტა ეფექტებისთვის.

პარალელურად - კანარის გამოშვებები, ფიჩეფლაგები, rollback, რეგულარული DR სწავლებები.

8) ოპერაციული გამოცდილება: რომელი SLO ითვლება ნორმად

ბირთვის აფთიაქი (wallet/cashier/game-gateway) 99,95% -ს შეადგენს.

p95 საფულის ლატენტობა <150 ms; cashier ავტორიზაცია <3.

„დაკარგული/დუბლირებული ნაკრები“ = 0.

მოვლენების მიტანა BI ფანჯარაში - 5 წთ

MTTR ბირთვის ინციდენტებზე <30.

9) უსაფრთხოება და შესაბამისობა „ნაგულისხმევი“

PII/გადახდის მონაცემების სეგმენტი, PCI DSS, GDPR/ადგილობრივი ანალოგები.

დაშიფვრა at-rest/in-transit, მოკლევადიანი ნიშნები, კლავიშების როტაცია.

WAF/bot დაცვა, მოწყობილობის დაცვა, ანომალიები velocity- ზე.

აუდიტის ლოგოები WORM საცავში, დაშვება მინიმალური უფლებების საფუძველზე.

10) ეკონომიკა და ორგანიზაციული ეფექტები

TTR გამოშვებები: დამოუკიდებელი დეპოზიტები ამცირებენ დავალებების რიგებს და კონტექსტ-სვიტჩს.

Cost-to-scale: ჰორიზონტალური მასშტაბები წერტილოვანი იაფია, მაგრამ თქვენ გჭირდებათ გააზრებული FinOps (skale, limites, spot ინსტანციები).

ინციდენტების რისკი: blast radius შეზღუდულია მომსახურებით.

პროდუქტის სიჩქარე: ახალი პროვაიდერები/PSP და ფიჩები არ ელოდება „საერთო ფანჯარას“.

11) მიკრო სერვისის iGaming ბირთვის სიმწიფის ჩამონათვალი

Ledger - ცალკე სერვისი და BD, მხოლოდ ბრძანების API, outbox/CDC.
ყველა ფულადი/ბონუსის ოპერაცია არის idempotent, დედაპლაციის გასაღებები ყველგან.
მოვლენების საბურავი სქემების რეესტრით; backward compatible კონტრაქტები.
Cashier ერთად PSP კასკადი და ყოველდღიური კრიკეტი.
Game Gateway ინციდენტების დეგრადაციით.
RG/AML - სინქრონული გაჩერების სიგნალები განაკვეთზე, რეალობის შემოწმებები.
Observability: მეტრიკა/logs/traces trace _ id; დაშბორდები SLO.
DR გეგმა: RPO - 5 წთ, RTO - 30 წთ; რეგულარული სწავლებები.
მონაცემთა აღდგენა და PII შენიღბვა; RBAC/ABAC და „4 თვალი“.
BI ხელით Excel- ის გარეშე: KPI ფანჯრები, კოჰორტი, LTV, მოხსენებები რეგულატორებისთვის.

12) წითელი დროშები (ანტიპატერები)

ბალანსების/პრემიების სახელმძღვანელო კორექტირება მონაცემთა ბაზაში.

ერთიანი BD „ყველაფრისთვის“, BI ურტყამს საბრძოლო მაგიდებს.

დომენის გარიგების „გვერდის ავლით“ მოვლენების გამოქვეყნება (არ არის გარეთ).

მოვლენების სქემების ვერსირების არარსებობა.

ნულოვანი idempotenty და retrais „როგორ მუშაობს“.

გადახდის უარი კასკადის და დეტალური ტელემეტრიის გარეშე.

კრიტიკულ გზებზე არ არსებობს RG/AML გაჩერების სიგნალები.

IGaming- ის მიკროსერვისები არ არის ხარკი მოდისთვის, არამედ დამოუკიდებელი სქემების ფულის, რისკის და პროდუქტის განვითარების გზა, გამოშვების დაჩქარება და ინციდენტების მასშტაბების შემცირება. გასაღები - ფულადი მთლიანობა (Ledger + idempotence + sagi), ღონისძიება (საბურავი + კონტრაქტები) და SRE/DevOps კულტურა. ამ საძირკველში, პლატფორმა გაუძლებს ტრეფიკის, გეოგრაფიისა და მარეგულირებელი მოთხოვნების ზრდას, რჩება სწრაფი, გამჭვირვალე და უსაფრთხო.