健康检查机制

1）为什么

健康检查是防止级联故障的第一个障碍：它们正确地将节点从旋转中移出，防止回火风暴，简化退化并加快恢复，同时保持SLO并降低MTTR。

2）基本检查类型

Liveness是"活着"的过程（没有死锁/泄漏/恐慌）。错误→恢复实例。
Readiness-该服务能够通过目标SLO（提升池、高速缓存、正常依赖资源）来服务流量。此错误→从平衡中排除,但不重启。
Startup-该服务已准备就绪，可以过渡到liveness/readiness（长引导程序，迁移，warmup）。防止过早重启。
深度健康（域特异性）：业务不变性（利率通过端到端,存款从活动的PSP授权）。用于降级信号，但不用于立即重新启动。
外部/合成：外部活动ping （API路径,前脚本,PSP/KYC）-测量用户可用性。

3）样品设计： 一般规则

1.廉价的生活：不适合外部依赖；检查事件循环，heap/FD，看门狗。
2.通过SLO进行准备：检查维护所需的本地资源（DB池、高速缓存、限制）。外部依赖关系-通过非锁定"can-serve？"信号。
3.Latency-budget：每个样本都有自己的SLA（例如≤100 -200 ms）；超过时-"degraded"，但不是5xx on liveness。
4.Backoff＆Jitter：采样间隔5-15秒，超时1-2秒，具有指数误差延迟，以避免同步风暴。
5.滞后：N成功的/错误的响应以改变状态（例如，"successThreshold=2"，"failureThreshold=3"）。
6.转化："/healthz"，"/readyz"，"/startupz"的端点稳定；"/health/……"之下的深层检查，并带有命名的检查。
7.没有秘密和PII：答桉只是状态和短代码。

8.Explainability： JSON附有子检查列表："{"status"："degraded", checks"： ［{"name"："db", ok"： true", latencyMs"：18}{"name"："psp。eu","ok":false,"reason":"timeout"}]}`.

4）按层进行深度检查的示例

4.1 DB/缓存/存储

DB：对读副本和池检查进行简短的"SELECT 1"事务处理；latency/replic-lag阈值。
缓存："GET"/"SET"测试密钥+命中率后卫（低命中→警告）。
对象存储：现有对象的HEAD（无下载）。

4.2个队列/流媒体

经纪人：本地分区内ping-topic publish+consume；consumer-lag阈值。
DLQ：窗口后面的死信中没有消息激增。

4.3外部提供商（PSP/KYC/AML）

PSP：轻量级auth-probe（非金钱），合同/证书/配额验证；如果没有安全样本-使用代理指标（银行/GEO 5-10分钟授权成功）。
KYC/AML：健康API和SLA队列；降解-切换到备用流/提供程序。

4.4个API/前端

合成：EU/LATAM/APAC中的交易路径（登录→存款启动→"沙子"费率）。
RUM信号：JS/HTTP和LCP/TTFB误差比例是"外部"触发器。

5）与平台集成

5.1 Kubernetes / Cloud

"startupProbe"保护引导程序（迁移/缓存扭曲）。
"livenessProbe"是极简主义的；"readinessProbe"考虑了池/缓存/本地队列。

Параметры: `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `failureThreshold`, `successThreshold`.

PodDisruptionBudget和maxUnavailable，考虑到准备就绪。
HPA/KEDA：按队列/SLI缩放；准备就绪会影响路由。

5.2 平衡器/网关/mesh

L7级健康路线（HTTP 200/429/503 semantics）。
Outlier检测（envoy/mesh）：从池中取出错误率/后置注释。
电路断路器：同时查询/依赖连接限制，与健康信号集成。

5.3自动滑行和退化

Readiness=FALSE →流量被删除,但pod还活着（可能晒黑）。
Deep-degrade （PSP） → graceful模式的特征标记（例如,暂时隐藏付款方法,启用待机室）。

6）超时和休假政策

超时<SLO预算：同步依赖性的"timeout=min（⅓ p99，1-2s）"。
相等性：retrais强制性；使用idempotency-keys。
指数backoff+jitter：防止同步轴效应。
Retray预算：caps per-request/tenant，保护"retry-storms"。

7）状态信号与警报

绿色/黄色/红色：服务行列上的摘要状态。
SLO上的烧伤率差：快速（1小时）和缓慢（6-24小时）。
Correlation-hints：关于发行/幻灯片/计划工作的标记。
Auto-actions：在"红色"深度检查中,启用后退提供程序,提高轨道采样。

8） iGaming的智能策略

薪资准备就绪：投注服务的可用性考虑到PSP 路由器的状态和银行/GEO的限制。
Odds/Lines publishing： Publischer 的就绪性取决于按线路来源和分发到缓存/edge的时间顺序的摘要。
Tournament spikes：更激进的outlier检测和等待室的临时策略。

9）反模式

进入DB/PSP的Liveness →在外部问题上大规模重启。
单个"通用"健康端口，不分开startup/readiness/liveness。
强硬的超时没有后卫/喷气机→暴风雨。
缺乏滞后→阻塞路由。
触发重启的深度检查（其目标是诊断和路由，不重新启动）。
在健康残局中隐藏5xx（掩盖真实状态）。

10）接口模板

/startupz → `200 OK {"uptimeSec":..., "version":"..."}`

检查：init脚本，迁移完成，密钥和configs加载。

/healthz (liveness) → `200 OK {"heapOk":true,"fdOk":true,"eventLoop":"ok"}`

检查：事件周期，过程资源，没有恐慌/国旗。

/readyz (readiness) →

`200 OK/503 {"canServe":true,"db":{"ok":true,"latencyMs":12},"cache":{"ok":true},"queue":{"ok":true,"lag":0},"localQuota":{"ok":true}}`

/health/payments (deep) →

`200/206/503 {"psp.eu":{"ok":false,"reason":"timeout"}, "psp.alt":{"ok":true}, "routerMode":"failover"}`

11）健康循环质量指标（KPI/KRI）

从"NotReady"到"Ready"（warmup-SLO）的发布时间。
"flapping" readiness per服务的频率。
错误重新安排的pod （root-cause-外部依赖）的百分比。
MTTR事件，其中健康机制发挥了作用（之前/之后）。
不涉及呼叫的自动失误/功能分类的比例。
合成vs RUM（假阳性/失误）的准确性。

12）实施路线图（4-8周）

奈德。1-2：关键路径清单；分离起点/liveness/准备；引入JSON反应与下检查和滞后。
奈德。3-4：添加深度检查：DB/缓存/经纪人；2-3 GEO中用于登录的合成/存款/投注；在/mesh网关中启用outlier检测。
奈德。5–6: payment-aware readiness и PSP-fallback;前面的服务室；通过拉格/队列进行自动滑行；按燃烧率计算。
奈德。7-8： chaos days（禁用PSP/DB复制副本）,backoff/jitter检查；超时，PDB；KPI报告和调整。

13）文物

健康规格（按服务）：检查清单、时间预算、滞后、红色状态活动。

Runbooks： "Readiness=FALSE：我们做什么？"，"PSP-fallback：步骤和返回标准。"

路由政策：无处检测规则，电路断路器，触发阈值。
合成剧本：剧本和地理，SLO合成，时间表。
Release Gate：红色深度检查关键依赖项的发布块。

结果

精心设计的健康检查回路是一个分层的信号系统：易于生存以实现过程的可行性，可满足交通需求的就绪能力，可安全启动的启动以及用于托管降解和路由的特定于域的深度检查。结合自动缓解，断路器，合成和SLO评分，它降低了级联故障的风险，减少了MTTR，并稳定了iGaming平台的业务关键路径。