微服務體系結構

1）為什麼在iGaming微服務

更改速度：獨立發布的團隊信息（付款、內容、風險、錦標賽）。
可靠性：單一服務的故障不會影響整個產品（故障邊界）。
規模：「熱」域的水平滑板（錢包，大廳，流）。
合規性：按區域/轄區劃分數據。

不值得的時候：小團隊/音量，沒有DevOps實踐，測試自動化薄弱--那麼模塊化整體更好。

2）域，邊界和命令（DDD+Team Topologies）

域輪廓：帳戶/配置文件，KUS/合規性，付款/錢包，遊戲內容/聚合，獎金/任務，錦標賽，營銷/CRM，報告/BI。
Bounded Context=關於數據模型和語言的約定。
更改流程↔命令：一個命令=一個輪廓+其SLO。
BFF （Backend for Frontend）： Web/Mobile/Partner下的單個立面,以免在客戶端上收集「編排」。

3）通訊： 同步vs asinchron

同步（REST/gRPC）：當需要立即響應時（在存款時檢查限額）。
Asinhron （Kafka/NATS/SQS）：事件和背景過程（現金返還、郵件、評級更新）。

• 關鍵路徑=網絡跳的最小值。
• 跨域集成-通過事件和合約API。
• 不要在網上建立「5+同步呼叫鏈」→使用EDA/傳奇。

4）合同和考試

合同一：OpenAPI/AsyncAPI+計劃註冊（Avro/JSON計劃）。
SemVer+兼容性：添加字段不會破壞客戶端。
消費者驅動合同（CDC）：CI中的自動反駁（反對回歸）。
Deprecation policy：支持窗口（12-18個月）,舊版本遙測。

5）事件、傳奇和一致性

Outbox/Transaction Log Tailing：原子記錄「數據+事件」。

• 用於付款/結算的編排（中央協調員）。
• 編舞（對事件的反應）以獲得獎金/任務。
• 相似性：「entityId+action+nonce」上的密鑰，dedup註冊表存儲。
• 一致性：「外部」-通過事件；「內部」-服務範圍內的交易。

6）數據和存儲

「自己的支架」原則：每個服務都擁有自己的DB（電路隔離）。

• 事務/資產負債表-具有嚴格不變性的關系（PostgreSQL）。
• 事件/日誌僅適用於（Kafka/Redpanda）。
• Kesh/會議-Redis/KeyDB；領導板是Redis Sorted Sets。
• 搜索-OpenSearch/Elastic。
• 實例化閱讀投影（CQRS）-快速列表/報告。

7）可靠性和可持續性

Timeouts/Retry with jitter/Retry-budget僅用於偶數操作。
服務之間的Circuit-breaker/Outlier-ejection。
Bulkhead：單獨的池到「嘈雜」的apstrims。

Rate limits per-client/route, backpressure (503 + Retry-After).

Dead-letter+poison-message排隊。

8）觀察力（觀察力）

跟蹤：OpenTelemetry（「trace_id」通過shlyuz→servisy→BD）。
度量標準：RPS，p50/p95/p99，error rate 4xx/5xx，aturation（CPU/mem/queue），業務指標（TTP，TtW）。
Logs：結構JSON，PII/PAN/IBAN掩蓋，通過「trace_id」表示。

SLO/Alerts： 路線/功能（例如"Deposit p95 ≤ 300 ms"，"成功≥ 98。5%`).

9）安全和合規性

零信任：mTLS servis↔servis（SPIFFE/SPIRE），短期證書。
AuthN/Z：OAuth2/JWT（aud/scope/exp），屬性角色劃分。
秘密：KMS/Secrets Manager/Sealed Secrets，按鍵旋轉。
GDPR/數據本地化：區域集群，在API網關上進行地理設置。
審計：不變日誌（WORM），管理操作跟蹤。

10）部署和發布

容器/K8s： 一項服務=一項服務；資源/限制；PodDisruptionBudget.

CI/CD：linters，unit/contract/integ測試，security scan，SBOM。
發行版本：canary/blue-green/shadow，通過擴展和合同遷移電路。
自動軌道：CPU+RPS+p95+queue-depth的HPA；折叠時繪制。

11）性能和成本

剖析：p95/99「按服務和方法」，flame圖。
Cashing：read-through/write-through；TTL/事件障礙。
數據本地性：保持熱數據接近計算。
FinOps：60-70%的下載目標，「warm pools」，不活躍的竊賊的自動暫停。

12）域模板（iGaming）

12.1付款/錢包

服務：「payments-gw」（立面），「wallet」，「psp-adapters-」，「fraud-check」。
流：「init → reserve → capture/rollback」（傳奇）。

События: `PaymentInitiated`, `PaymentAuthorized`, `PaymentSettled/Failed`.

相似性：「Idempotency-Key」，「wallet」中的惡作劇。

12.2 KUS/合規性

Сервисы: `kyc-flow`, `doc-storage`, `sanctions-check`, `pep-screening`.

События: `KycSubmitted/Approved/Rejected`, `RiskScoreUpdated`.

審核和ETA：任務隊列，案例超時，後期操作。

12.3個獎金/任務

服務：「bonus-engine」，「wallet-bonus」，「eligibility」。
編舞：「BetPlaced → BonusEngine → BonusGranted → WalletCredited」。
防止濫用：特許贈款，限制，規則模擬器。

12.4個錦標賽/領導板

服務：「tournament-svc」，「scoring」，「leaderboard」。
存儲：Redis ZSET+OLAP中周期性的「重置」。

События: `ScoreUpdated`, `TournamentClosed`, `RewardIssued`.

13）合同+事件示例（簡化）

OpenAPI（片段）-Wallet

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）測試

基於域規則的Unit/Property。
CDC（Pact/Assertible）是提供商/消費者的合同測試。
與本地經紀人（Testcontainers）集成。
E2E批判性洪水（registratsiya→depozit→start igry→vyvod）。
Chaos/Failover測試：PSP關閉/經紀人下降/區域丟失。

15）度量和SLO（最低）

服務可用性：'≥99。9%用於支付/錢包。
Latency p95：關鍵路徑的API ≤ 300-500毫秒。
Error budget: 0.1–0.每季度5%，burn-alerts。

隊列： 領先的事件時間（produce→consume），DLQ ≤ 0。1%.

業務：TTP，TtW，FTD-success，KYC-TtV。

16）支票單

服務設計

• 明確域邊界和數據所有者。
• Registry中的OpenAPI/AsyncAPI+架構合同。
• SLO/Alertes的定義；度量/treass/logi嵌入。
• Taymauts/Retraes/Idempentity政策。
• 模式遷移：擴展和合同。

發布前

• 單位/CDC/集成測試為綠色。
• 金絲雀路線和回滾計劃。
• Rate-limits/權重路由已配置。
• 保密/鑰匙/證書互換。
• Ficha-Flag和Fallbacks準備就緒。

17）反模式

網絡作為數據總線：深同步鏈代替事件。
一般的「上帝」-所有服務的DB。
缺乏相同能力→雙重註銷/權責發生制。
沒有遙測和殺手開關的黑暗版本。
隱藏的會話（粘性無處不在而不是外部狀態）。
沒有版本和CDC的「代碼」合同。
API網關而不是服務中的邏輯（網關=薄）。

18）從巨石遷移（Strangler Fig）

1.突出顯示門面網關和第一個輪廓（例如付款）。
2.從整體中刪除二進制構造（outbox）到事件。
3.逐步將底部轉換為新服務（路由/金絲雀重量）。
4.將整體壓縮到「核心」並關閉。

19）堆棧和基礎設施（示例）

通訊： REST/gRPC，Kafka/NATS；Schema Registry.

存儲： PostgreSQL，Redis，OpenSearch，S3/MinIO；OLAP — ClickHouse/BigQuery.

容器/編排：必要時的Docker，Kubernetes（Ingress/Gateway），Service Mesh（Istio/Linkerd）。
網關：Envoy/Kong/Traefik/NGINX。

CI/CD: GitHub Actions/GitLab CI + ArgoCD/Flux;Pact/OWASP/ZAP.

Observability: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki.

20）最終的spargalka

跨域和數據責任設計邊界。
同步只是現在需要答案的地方；其余的是事件。
合同/計劃/CDC-回歸保險。
Sagi+outbox+等效性是可靠性的基礎。
可觀察性和SLO不是選項，而是標準「準備就緒」。
通過金絲雀/藍綠色發布，遷移-擴展和合同。
安全/合規性：mTLS，JWT，KMS，區域數據。

首先是模塊化整體,然後是演變-如果規模和團隊準備好了.