Torrent Gear

Неліктен iGaming микросервистерге көшеді

Мақаланың толық мәтіні

💡 18+. Материал - ағартушылық. Ойынға шақыру емес. Сәулетті өзгертудің инженерлік себептеріне назар аударылады.

1) Контекст: неліктен монолит жұмысын тоқтатты

iGaming мазмұн, география және реттеу бойынша өсуде. Біртұтас код базасы:

релиздерді тежейді (жалпы деплой-терезелер, регрессия қаупі), нашар масштабталады (әмиян мен касса - ыстық, ал CMS - суық), талаптарға сәйкестікке кедергі келтіреді (түрлі реттегіштер → әртүрлі деректер ережелері), ақшаны оқшаулауды қиындатады (money-flows және бонустар өрілген).

Нәтижесі - оқыс оқиғалардың жоғары тәуекелі және баяу time-to-market.

2) Микросервистік тәсіл не береді

1. Шекті домендерді оқшаулау. Әмиян/Ledger, Cashier/PSP, Bonus Engine, Game Sessions, KYC/AML, RG, Risk/Fraud, Affiliates, CRM - өздерінің SLO-ларымен жеке қызметтер.

2. Тұтыну бойынша масштабтау. Ыстық сервистер (әмиян, касса, ойын сессиясы) бүкіл кластерді үрлемей-ақ көп ресурстар алады.

3. Тәуелсіз релиздер. Командалар өз циклі бойынша деплояланады (канареялық релиздер, feature-жалаулар).

4. Ақауларға төзімділік. Жергілікті деградация бүкіл өнімді құлатпайды (cashier деградацияланады - ойындар кештер мен кезектер есебінен жалғасады).

5. Заңдық сегменттеу. PII және өңірлер бойынша төлемдерді бөлу (EU/UK/BR) және дата-резиденттік.

6. Интеграцияның икемділігі. Ойын провайдерлерін, PSP және KYC провайдерлерін қатарлас қосу.

3) Базалық схема (жеңілдетілген)

Edge қабаты: API Gateway, WAF/бот қорғанысы, rate limiting, geo-сүзгілер.

Домендік микросервистер: Wallet/Ledger, Bonus, Cashier, Game Gateway, Risk/Fraud, RG, KYC/AML, Affiliates, CRM, CMS, Reporting/Compliance.

Оқиға шинасы: Kafka/Pulsar - 'bet. placed`, `bet. settled`, `wallet. debit/credit`, `cashier. deposit. succeeded`, `rg. limit. hit`, `bonus. consumed 'және т.б.

Деректер: OLTP DD service, outbox/CDC → DWH (ClickHouse/BigQuery).

Observability: метрика/логи/трейстер; SIEM/SOAR; audit-log WORM.

4) Ақша және тұтастық: неге бұл көші-қонның кілті

Микросервистердің басты дәлелі - ақша контурының қатаң оқшаулануы:

қатаң ACID және командалардың іспеттілігі бар жеке Ledger, ұзақ процестерге арналған сағалар (депозиттер, кэшаут, бонустық есептеулер), outbox + оқиғаларды транзакциялық жариялау, баланстарды «қолмен түзетуге» нөлдік рұқсат беру.

Мұндай дизайн сәулет деңгейінде сеттлменттерді жоғалту/қайталау ықтималдығын нөлге дейін төмендетеді.

5) Микросервистер оларсыз ұшпайтын паттерндер

CQRS + проекциялары. Командалар - қатаң түрде домендік API арқылы; оқу - проекциялық модельдер арқылы.

Idempotency Keys. Әрбір ақшалай/бонустық команда жанама әсерсіз қайталанады.

Сағалар мен өтемақылар. «ДБ қайтару» орнына анық өтемдік оқиғалар.

Schema Registry. Оқиғалар келісімшарттарын нұсқалау; продюсерлердің/консьюмерлердің үйлесімділігі.

Rate limits/Retry/Backoff. Желілік іркілістер - бұл норма; клиенттік тұрақтылық.

Zero-trust және құпиялар. mesh ішіндегі mTLS, Vault/HSM, ең аз артықшылықтар.

6) Микросервистерде не күрделі (минустар туралы шынымен)

Желі жадтан қымбат. RPC көбірек, жасырындылық өсімі және инфрақұрылым құны.

Деректердің күрделілігі. Консистенттілік - Ledgera шегінен тыс eventual, проекциялар қажет.

Бақылау қабілеті. Трасинг пен SLO жоқ, бәрі тез «қара жәшікке» айналады.

Командалық тәртіп. Келісімшарттық тесттер, рәсімдер, схемалардың көші-қоны - міндетті.

Кросс-аймақтық ажыраулар. Data residency ойланып шардалауды талап етеді.

Егер компания DevOps/SRE-мәдениетке дайын болмаса, «жақсы модульділігі бар» монолит жақсы болуы мүмкін.

7) Қадамдық көші-қон: монолиттен сервистерге

1-қадам. Оқиғаларды стандарттаңыз. Шина мен бірыңғай сөздікті енгізіңіз: ойыншы, мөлшерлеме, сеттлмент, депозит, бонус.

2 қадам. Ledger бағдарламасын шығарыңыз. Ақшалай контур бірінші болып бөлінеді: жеке ДБ, команданың API, outbox.

3 қадам. Cashier бөліңіз. PSP оркестрлеу, каскадтар, 3-DS, салыстыру - дербес сервис ретінде.

4 қадам. Game Gateway. Ойын провайдерлеріне бірыңғай шлюз; сессиялар/коллбектер - монолит арқылы емес.

5 қадам. Bonus Engine и RG. Ережелер, вейджер, лимиттер - дербес, әмиян/ойын оқиғаларына жазылу.

6 қадам. Risk/AML + KYC. Өз интеграцияларымен және алертингімен жеке контур.

7 қадам. Деректер және BI. DWH CDC, KPI витриналар, анти-Excel есеп.

8 қадам. Back-office. RBAC/ABAC, аудит-лог, крит-экшендерге арналған «4 көз».

Сонымен қатар - канареялық релиздер, фичефлагтар, rollback, тұрақты DR-жаттығулар.

8) Пайдалану тәжірибесі: қандай SLO нормасы болып саналады

Ядро аптайымы (wallet/cashier/game-gateway) ≥ 99,95%.

🚨 150 мс; cashier авторизациялау <3 с.

«Жоғалған/қайталанған сеттлменттер» = 0.

Оқиғаларды BI-сөрелерге жеткізу ≤ 5 мин.

Ядро инциденттері бойынша MTTR <30 мин.

9) Қауіпсіздік және комплаенс «әдепкі»

PII/төлем деректерінің сегментациясы, PCI DSS, GDPR/жергілікті аналогтар.

at-rest/in-transit шифрлау, қысқа өмір сүретін токендер, кілттердің ротациясы.

WAF/бот-қорғаныс, device-fingerprinting, velocity бойынша аномалиялар.

WORM-қоймасындағы аудит-логтар, ең аз құқықтар қағидаты бойынша қол жеткізу.

10) Экономика және ұйымдастырушылық әсерлер

TTR релиздері ↓: тәуелсіз деплойлар тапсырмалар мен контекст-свитч кезектерін азайтады.

Cost-to-scale ↓/↑: көлденең масштабтау нүктелі арзан, бірақ ойластырылған FinOps (автоскейл, лимиттер, spot-инстанциялар) қажет.

Инциденттер қатері ↓: blast radius сервиспен шектелген.

Өнім жылдамдығы ↑: жаңа провайдерлер/PSP және фичтер «ортақ терезені» күтпейді.

11) Микросервистік iGaming ядросының жетілу парағы

Ledger - жеке сервис және БД, тек командалық API, outbox/CDC.
Барлық ақшалай/бонустық операциялар демпотентті, дедупликация кілттері - барлық жерде.
Схемалар тізілімі бар оқиғалар шинасы; backward-compatible келісімшарттары.
Cashier PSP каскадымен және күнделікті жарқылдармен.
Оқиғалар кезінде «no new sessions» деградациясы бар Game Gateway.
RG/AML - ставкадағы синхронды тоқтату сигналдары, reality-checks.
Observability: аралық trace_id бойынша метрика/логи/трейдер; SLO дашбордтары.
DR-жоспар: RPO ≤ 5 мин, RTO ≤ 30 мин; тұрақты оқу-жаттығулар.
Data residency және PII бүркемелеу; RBAC/ABAC және «4 көз».
BI қолмен Excel жоқ: KPI витриналары, кохорттар, LTV, реттеушілер есептері.

12) Қызыл жалаулар (антипаттерндер)

Баланстарды/бонустарды ДБ-да қолмен түзету.

Бірыңғай БД «бәріне», BI жауынгерлік кестелерге соғады.

Домен транзакцияларын «айналып өту» оқиғаларын жариялау (outbox жоқ).

Оқиғалар схемаларын нұсқалаудың болмауы.

Нөлдік сәйкессіздік және ретра «қалай болады».

Каскадсыз және егжей-тегжейлі телеметриясыз төлеуден бас тарту.

Сындарлы жолдарда RG/AML тоқтату сигналдары жоқ.

iGaming микросервистері - сән емес, ақшаны, тәуекелді және өнімді тәуелсіз контурлар бойынша бөлудің, релиздерді жылдамдатудың және инциденттердің ауқымын азайтудың тәсілі. Кілт - ақша тұтастығы (Ledger + демпотенттілік + сағалар), оқиғалық (шина + келісімшарттар) және SRE/DevOps мәдениеті. Мұндай іргетаста платформа трафиктің, географияның және реттеуші талаптардың өсуіне төтеп бере алады, жылдам, ашық және қауіпсіз болып қалады.