معماری میکروسرویس

1) چرا میکروسرویس ها در iGaming

سرعت تغییر: انتشار مستقل از ویژگی های تیم (پرداخت، محتوا، ریسک، مسابقات).
قابلیت اطمینان: شکست یک سرویس کل محصول را کاهش نمی دهد (محدودیت شکست).
مقیاس: مقیاس افقی دامنه های «داغ» (کیف پول، لابی، جریان).
انطباق: تفکیک داده ها بر اساس منطقه/صلاحیت.

هنگامی که ارزش آن را ندارد: یک تیم کوچک/حجم، هیچ شیوه DevOps، اتوماسیون ضعیف تست ها - پس یک مونولیت مدولار بهتر است.

2) دامنه ها، مرزها و تیم ها (DDD + توپولوژی تیم)

خطوط دامنه: حساب/مشخصات، CCM/پذیرش، پرداخت/کیف پول، محتوای بازی/تجمع، پاداش/ماموریت، مسابقات، بازاریابی/CRM، گزارش/BI.
متن محدود = مدل داده و قرارداد زبان.
تغییر جریان ↔ دستورات: یک دستور = یک حلقه + SLO های آن.
BFF (Backend for Frontend): نماهای جداگانه برای وب/موبایل/شریک، به طوری که برای جمع آوری «ارکستراسیون» در مشتری.

3) ارتباطات: همزمان در مقابل ناهمزمان

همگام (REST/gRPC): هنگامی که یک پاسخ فوری مورد نیاز است (بررسی محدودیت سپرده).
Asynchron (Kafka/NATS/SQS): رویدادها و فرآیندهای پس زمینه (تعهدی نقدی، پستی، به روز رسانی رتبه).

• مسیر بحرانی = حداقل هاپ شبکه.
• ادغام متقابل دامنه - از طریق رویدادها و API های قراردادی.
• از «زنجیره ای از 5 + تماس همزمان» آنلاین استفاده نکنید → از EDA/sagas استفاده کنید.

4) قراردادها و نسخه

قرارداد اول: OpenAPI/AsyncAPI + Schema Registry (Avro/JSON Schema).
SemVer + سازگاری: اضافه کردن فیلدها مشتریان را خراب نمی کند.
قراردادهای مبتنی بر مصرف کننده (CDC): چک های خودکار در CI (در مقابل رگرسیون).
سیاست رد: پنجره پشتیبانی (12-18 ماه)، تله متری برای نسخه های قدیمی تر.

5) رویدادها، ساگا ها و سازگاری

Outbox/Transaction Log Tailing: رکورد اتمی «داده + رویداد».

• ارکستراسیون (هماهنگ کننده مرکزی) برای پرداخت/خروجی.
• رقص (واکنش به حوادث) برای پاداش/ماموریت.
• Idempotence: کلید در 'entityId + عمل + nonce'، ذخیره سازی رجیستری dedup.
• سازگاری: «خارجی» - از طریق حوادث ؛ «داخلی» - معاملات درون سرویس.

6) داده ها و ذخیره سازی

اصل «فروشگاه خود»: هر سرویس دارای پایگاه داده خود (جداسازی طرح ها) است.

• تراکنشها/ترازها رابطهای (PostgreSQL) با متغیرهای سخت هستند.
• رویدادها/ثبت - پیوست فقط (کافکا/ردپاندا).
• کش/جلسات - Redis/KeyDB ؛ مدیران - مجموعه های مرتب شده Redis.
• جستجو - OpenSearch/الاستیک.
• پیش بینی های خواندن مواد (CQRS) - لیست های سریع/گزارش ها.

7) قابلیت اطمینان و ثبات

Timeouts/Retry با jitter/Retry-budget فقط برای عملیات idemotent.
قطع کننده مدار/خروجی خروجی بین خدمات.
Bulkhead: استخرهای جداگانه برای «پر سر و صدا» بالادست.
محدودیت نرخ در هر مشتری/مسیر، فشار پشتی (503 + Retry-After).
نامه مرده + دست زدن به پیام سمی در صف.

8) قابلیت مشاهده

ردیابی: OpenTelemetry ('trace _ id' از طریق shlyuz → servisy → BD).
معیارها: RPS، p50/p95/p99، میزان خطا 4xx/5xx، اشباع (CPU/mem/صف)، معیارهای تجاری (TTP، TtW).
سیاهههای مربوط: ساختار JSON، PII/PAN/IBAN پوشش، همبستگی با 'trace _ id'.
SLO/هشدار: به مسیر/عملکرد (به عنوان مثال، "سپرده p95 ≤ 300 ms"، "موفقیت ≥ 98. 5%`).

9) ایمنی و انطباق

Zero-Trust: mTLS servis↔servis (SPIFFE/SPIRE)، گواهینامه های کوتاه مدت.
AuthN/Z: OAuth2/JWT (aud/scope/exp)، ویژگی تمایز نقش ها.
اسرار: KMS/Secrets Manager/Sealed Secrets، چرخش کلید.
GDPR/محلی سازی داده ها: خوشه های منطقه ای، جغرافیایی در دروازه API.
حسابرسی: سیاهههای مربوط تغییر ناپذیر (WORM)، ردیابی اقدامات مدیر.

10) استقرار و انتشار

Containers/K8s: یک سرویس = یک استقرار ؛ منابع/محدودیت ها ؛ بودجه PodDisruptionBudget

CI/CD: خطوط، تست واحد/قرارداد/integ، اسکن امنیتی، SBOM.
خروجی: canary/blue-green/shadow, scheme migrations via expand-contract.

مقیاس خودکار: HPA توسط CPU + RPS + p95 + عمق صف ؛ تخلیه در سقوط

11) عملکرد و هزینه

Profiling: p95/99 «by services and methods», flame-graphs.

ذخیره سازی: خواندن از طریق/نوشتن از طریق ؛ TTL/ناتوانی بر اساس رویداد

محل داده: داده های داغ را نزدیک به محاسبات نگه دارید.
FinOps: هدف بارگیری 60-70٪، «استخرهای گرم»، مکث خودکار کارگران غیرفعال.

12) قالب های دامنه (iGaming)

12. 1 پرداخت/کیف پول

خدمات: «پرداخت-gw» (نما)، «کیف پول»، «PSP-آداپتورهای -»، «تقلب چک».
Stream: 'init → reserve → capture/rollback' (حماسه).
События: 'PaymentInitiated', 'PaymentAuthorized', 'PaymentSettled/Failed'.
Idempotency: «Idempotency-Key»، مرده در «کیف پول».

12. 2 CCM/انطباق

Сервисы: 'kyc-flow', 'doc-storage', 'sanctions-check', 'pep-screening'.
События: 'KycSubmitted/Approved/Rejected', 'RiskScoreUpdated'.
حسابرسی و ETA: صف کار، مورد زمان، اقدامات پس از.

12. 3 پاداش/ماموریت

خدمات: «پاداش موتور»، «کیف پول پاداش»، «واجد شرایط بودن».
رقص: «BetPlaced → BonusEngine → BonusGranted → WalletCredited».
حفاظت در برابر سوء استفاده: کمک های بی نظیر، محدودیت ها، شبیه ساز قانون.

12. 4 مسابقات/مدیران

خدمات: «tournament-svc»، «scoring»، «leaderboard».
ذخیره سازی: Redis ZSET + دوره ای «فلاش» در OLAP.
События: 'ScoreUpdated', 'TournamentClosed', 'RewardIssued'.

13) قرارداد + مثال رویداد (ساده شده)

OpenAPI (قطعه) - کیف پول

yaml paths:
/v1/wallet/{userId}/credit:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CreditRequest'
responses:
'202': { description: 'Enqueued' }
components:
schemas:
CreditRequest:
type: object required: [amount, currency, reason, idempotencyKey]
properties:
amount: { type: number }
currency: { type: string, example: UAH }
reason: { type: string, enum: [Deposit, Bonus, Adjustment] }
idempotencyKey: { type: string }

AsyncAPI (قطعه) - رویداد

yaml channels:
wallet. credit. applied:
publish:
message:
name: WalletCreditApplied payload:
type: object required: [userId, amount, currency, sourceEventId]

14) تست

واحد/املاک مبتنی بر قوانین دامنه.
CDC (Pact/Assertible) - آزمایشات قرارداد ارائه دهنده/مصرف کننده.
ادغام با کارگزاران محلی (Testcontainers).

E2E جریان بحرانی (registratsiya → deposit → start igry → vyvod)

آزمون هرج و مرج/شکست: خاموش شدن PSP/افت کارگزار/از دست دادن منطقه.

15) معیارها و SLO (حداقل)

دسترسی به خدمات: ≥99 9٪ برای پرداخت/کیف پول.
تاخیر p95: مسیر بحرانی API ≤ 300-500 ms.
بودجه خطا: 0. 1–0. 5٪ در هر سه ماهه، هشدار سوختگی.
صف: رویدادهای زمان سرب (تولید → مصرف)، DLQ ≤ 0. 1%.
کسب و کار: TTP، TtW، FTD-success، KYC-TtV.

16) چک لیست

طراحی خدمات

• پاک کردن مرز دامنه و صاحب داده.

قراردادهای OpenAPI/AsyncAPI + طرحوارهها در رجیستری.

• SLO/هشدارها تعریف شده است ؛ متریک/مسیرهای پیاده روی/سیاهههای مربوط در ساخته شده است.
• سیاست های وقفه/Retray/Idempotency.
• مهاجرت طرح: گسترش و قرارداد.

قبل از انتشار

• تست واحد/CDC/ادغام سبز.
• مسیر قناری و طرح برگشت.
• مسیرهای سرعت/وزن پیکربندی شده است.
• اسرار/کلید/گواهی حفاری.
• پرچم های Ficha و follbacks آماده می شوند.

17) ضد الگوهای

شبکه به عنوان اتوبوس داده: زنجیره های همزمان عمیق به جای رویدادها.
«خدا» مشترک - DB برای همه خدمات.
فقدان idempotency → double write-offs/تعهدی.
انتشار تاریک بدون تله متری و سوئیچ کشتن.
جلسه پنهان (چسبندگی در همه جا به جای شرایط خارجی).
قرارداد «در کد» بدون نسخه و CDC.
منطق در API دروازه به جای خدمات (دروازه = نازک).

18) مهاجرت یکپارچه (شکل خفه کننده)

1. دروازه نما و مدار اصلی (به عنوان مثال، پرداخت) را انتخاب کنید.
2. حذف باینری ورود به سیستم (outbox) از monolith به حوادث.
3. به تدریج نقاط پایانی را به یک سرویس جدید انتقال دهید (وزن مسیریابی/قناری).
4. یکپارچه را به «هسته» فشرده کنید و آن را خاموش کنید.

19) پشته و زیرساخت (مثال)

ارتباطات: REST/gRPC، Kafka/NATS ؛ ثبت طرح.
مخازن: PostgreSQL، Redis، OpenSearch، S3/MinIO ؛ OLAP - ClickHouse/BigQuery.
ظروف/ارکستراسیون: Docker، Kubernetes (ورودی/دروازه)، مش سرویس (Istio/Linkerd) در صورت لزوم.
دروازه: نماینده/کنگ/Traefik/NGINX.
CI/CD: اقدامات GitHub/GitLab CI + ArgoCD/Flux ؛ پیمان/اواسپ/ZAP.
قابلیت مشاهده: OpenTelemetry، Prometheus، Tempo/Jaeger، Loki.

20) ورق تقلب نهایی

مرزها را با مسئولیت دامنه و داده ها طراحی کنید.
Synchron - فقط در جایی که اکنون پاسخ لازم است ؛ بقیه اتفاقات است.
قراردادها/طرحها/CDC - بیمه رگرسیون.
Sagas + outbox + idempotency - پایه و اساس قابلیت اطمینان.
قابلیت مشاهده و SLO یک گزینه نیست، بلکه معیار «آماده» است.
انتشار از طریق قناری/آبی سبز، مهاجرت - گسترش و قرارداد.
ایمنی/انطباق: mTLS، JWT، KMS، داده های منطقه ای.
اول، یک مونولیت مدولار، سپس تکامل - اگر مقیاس و تیم آماده هستند.