微服务体系结构

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，区域数据。

首先是模块化整体,然后是演变-如果规模和团队准备好了.