運營和管理→服務依賴性

服務依賴性

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捕捉消費者的期望，並在不兼容的情況下打破提供商的發布--比代碼早。