运营和管理→服务依赖性

服务依赖性

1）为什么需要它

任何生产平台都是图形：Edge/API 用户 队列/流域服务 DB/缓存 外部提供商（支付，KYC，游戏提供商）。图的一个边缘上的错误通常在整个网络中"散步"：延迟增加，中继触发，队列堵塞，级联故障发生。依赖项管理降低了"爆炸半径"，并使发行版可预测。

• 查看呼叫的完整图并了解谁依赖谁。
• 防止级联故障和"后退风暴"。
• 根据兼容性和SLO宣传计划发布。
• 提高MTTR：更快地找到真正的初学者节点（root cause）。

2）依存关系类型

同步（RPC：REST/gRPC/GraphQL）：通过潜力/可用性进行硬连接。我们需要taymauts，breakers，retrais预算。
异步（Event/Stream： Kafka/Rabbit/Pulsar）：更稳定的连通性,但存在传单/回传和传递语义（at-least-once, idempotency）。
存储（DB/Cache/Object Store）：可共享资源→ 扭曲、连接限制/IOPS、事件、复制。
外部提供商（PSP/KYC/游戏提供商）：配额，付费电话，服务窗口，法律SLA。
运营（发行版，ficheflagi，configi）：通过设置，秘密，计划注册间接依赖。

3）服务目录和约束图

• 所有者（Squad/聊天/On-call rota），回购，环境，文物。
• API合同（OpenAPI/AsyncAPI），版本，兼容性（后退/前进）。
• 类型为（sync/async）的入站/出站（upstream/downstream）、临界值、SLO期望值。
• Taymauts/Retraes预算，破折号，bulkhead池。
• 外部集成的配额和限制数据。

• `service: payments-api`
• Upstream: `user-profile` (sync), `risk-score` (async).
• Downstream: `PSP-X` (sync, квота 2k RPS), `ledger` (async).
• SLO：p99 ≤ 300毫秒，99。9% uptime.
• 时间：200毫秒对"PSP-X"，150毫秒对"用户配置文件"。
• Retrai： 2具有指数延迟,jitter。
• Breaker：以5%/10的错误开放30秒。

4）SLO宣传和"潜伏预算"

在同步调用链中，最终SLO由延迟和故障概率之和组成。

• 请求预算从上到下细分：前SLO 500 ms ed ge 50 ms API 150 ms 域服务200 ms 提供商100 ms。
• Taymout"向外短于向内"：呼叫的taymout的总内部较少，因此可以更新资源而不是复制僵尸呼叫。
• 仅针对安全代码/异常并带有抖动的Retrai；没有回溯到瓶颈（否则为"风暴"）的时间。

5）合同和兼容性

API验证：合同的SemVer；通过方案扩展"选择性"字段进行反向匹配更改；删除-仅通过"deprekate期"。
消费者驱动合同（CDC）：消费者测试（类似Pact）在CI中针对提供商运行；不兼容时会阻止发行。
寄存器方案（Async）：拓扑/事件版本，方案演变（Avro/JSON-Schema），"can-read-old/can-write-new"策略。

6）工程可持续性模式

Timeouts：将SLA业务与技术期望分开；每个出站连接都是显式的taymout。
Retries+backoff+jitter：给定等效性，最多不超过2-3次尝试。
Circuit Breaker：downstream降解时"迅速下降"；半开放样本。
Bulkhead（池隔离）：对于不同的下游-单独的流/pod/连接池。
Rate-limit/Leaky-bucket：不要在高峰时杀死downstrims。
Idempotency&重复数据消除：请求/消息级别的等效性密钥；祖父和转发队列。
缓存和漏洞：本地/分布式缓存，"stale-wile-revalidate"状态，内容降级。

outbound:
psp-x:
timeout_ms: 200 retries: 2 retry_on: [5xx, connect_error]
backoff: exponential jitter: true circuit_breaker:
error_rate_threshold: 0. 05 window_s: 10 open_s: 30 pool: dedicated-psp (max_conns: 200)

7）依赖性可观察性

分布式轨迹（TraceID, Baggage）： 通过链接查看查询路径；带有'peer标签的出站呼叫。service`, `retry`, `timeout`.

Метрики per-dependency: `outbound_latency_p99`, `outbound_error_rate`, `open_circuit`, `retry_count`, `queue_lag`.

• 带有SLO颜色指示和错误边的服务卡。
• 过去一周的"问题成瘾前N"。
• "Blast radius"是在X下降时会受到影响的服务的列表。
• 相关性日志：在日志中包含"trace_id"/"span_id"。

8）根据相关性管理发布

Dependency-aware piplines：如果CDC消费者测试为红色,则提供商的发布将被阻止。
逐步加入（ficheflagi）：1％的消费者→新的领域/内含物→ 10％→ 100％。
金丝雀发布：检查关键依赖性和流量份额的"潜伏预算"。
电路兼容性：制作人撰写"vNew"，制片人阅读"vOld/vNew"；过渡后-旧字段的"垃圾收集"。

9）事件和逐项升级

我们定义"真正的罪魁祸首"：警报相关性-如果降级了"PSP-X"，我们不会分页整个"支付灌木丛"，而是集成的所有者。
自动评级：ficheflag"最小模式"（较轻的残局，精简的乐队，非关键的幻影）。
级联的加尔达斯：限制并发，关闭热分支上的后退，提前打开断路器（打开前）。

• 诊断：哪些仪表板/指标，如何检查配额/限额。
• 操作：降低RPS,切换到备用提供商,暂时启用缓存响应。
• 回滚和验证：返回参数,确保p95/p99规范和error-rate。

10）依赖关系关键性矩阵

• 对于"关键"-双重提供者，断路器，单个池，混沌测试。
• 对于"高"-至少降级和"绿色按钮"关闭菲奇。
• 对于"中低/中低"，限制回程和队列预算。

11）流程： 从库存到操作

1.绘图：从目录中收集实际调用（跟踪）+声明约束。
2.为每个服务和外部集成指定所有者-负责呼叫。
3.定义SLO和预算：潜伏期/错误，taymout/retrai/池。
4.正式化合同：OpenAPI/AsyncAPI，方案和CDC。
5.启用弹性模式：timeouts/retries/circuit/bulkhead。
6.自定义dashbords和alerta per-dependency。
7.提供发布门：CDC/兼容性/金丝雀块。
8.常规比赛日：关键肋骨坠落的溷乱实验。
9.以通信为重点的验尸程序：如何缩小半径来增强级联。

12）成瘾（规则思想）

• `outbound_error_rate{to="X"} > 3% FOR 10m` → warning; `>5% FOR 5m` → critical.
• `outbound_p99_latency{to="X"} > SLO1.3 FOR 10m` → warning.
• Circuit breaker:
• "circuit_open{to="X"}==1 FOR 1m' → page集成所有者。

• 'retry_rate {to='X'}> baseline2 FOR 5m'+'outbound_rps> 0' →风暴风险。
• Async:
• `consumer_lag{topic="Y"} growth > threshold FOR 10m` + `hpa at max` → крит.

• 'usage_quota {provider='PSP-X'}> 90% window '→警报,自动重新连接路由。

13）反模式

"每个下游一个共享流池。"总计：线头块。分享池。
没有Taymauts/具有无限的回溯。所以风暴诞生了。
盲人隐身手术。注销/费率双倍。
隐藏的"共享DB"作为连接点。激烈的竞争和封锁。
API版本在没有CDC和删除计划的情况下进行更改。捕捉大跌。
仅通过服务，不通过链接进行观察。没有看到链条在哪里撕裂。

14）Dashbords： 最低设置

服务地图：带有边缘度量的交互式服务地图（latency/error/volume）。
Upstream/Downstream Overview：对于服务所有者-传入的依存关系（呼叫者）,传出（呼叫者）"顶级问题"。
Dependency Drilldown：特定链接卡：p50/p95/p99，类错误，开放式断路器百分比，中继器，连接池，配额/海岸。
Release Context： 在依存关系图上注释版本/ficheflags。

15）实施支票

• 拥有所有者和合同的服务目录（OpenAPI/AsyncAPI）。
• 来自跟踪的完整依赖项图（每日更新）。
• 服务上的SLO和"潜伏预算"沿着链条下降。
• 显而易见的taymauts，带挤压器的转发，断路器，bulkhead隔离。
• CI中的CDC测试作为发布门。
• Dashbords per-dependency和服务卡。
• Alerta在肋骨上+在根本原因上的支持。
• Game-days：提供商/集群/拓扑的下降以及降级检查。
• 退化计划：我们禁用哪些仙女,我们包括哪些缓存。
• 具有减少连通性的活动的定期验尸。

16）依赖性管理质量的KPI

Dependency MTTR：肋骨恢复中位数。
Blast Radius Index：一个下降时受影响的服务的平均数量。
Coupling得分：同步依赖性在所有人中的比例；下降趋势。
CDC Pass Rate：不违反合同的发行百分比。
Retry Storms/月：目标值→ 0。
外部呼叫成本：1k RPS上的外部呼叫成本（查看缓存/fallback效果）。

17）快速启动（默认）

Taymauts：占链接预算的70-80％；请求的顶部taymout<内部总和。
Retrai： max 2,仅适用于等效的5xx/network,带有backoff+jitter。
破解者：阈值为5%误差为10秒,open=30秒,半开样本。
Bulkhead：每个下游的专用池/连接限制。
CDC：所有公共API和拓扑都是强制性的。
Async-preferences：在哪里可以切换到事件/队列（时间互换）。

18) FAQ

Q： 更重要的是：retrai还是断路器?

A：两者。Retrai可以避免短暂的干扰，断路器可以防止永久退化和暴风雨。

问：如何理解这种联系"太脆弱"？
答：误差相关性高，时空库存少，频繁的休假，没有后卫/缓存，同步的长链。

问：如果我们有集成测试，疾病预防控制中心为什么呢？
答：CDC捕捉消费者的期望，并在不兼容的情况下打破提供商的发布--比代码早。