Operazioni e Gestione delle dipendenze dei servizi

Dipendenze dei servizi

1) Perché è necessario

Ogni piattaforma di produzione è un grafico: gli utenti di Edge/API, i servizi di dominio, le code/striam, il database/cache, i provider esterni (pagamenti, KYC, provider di giochi). Un errore sulla singola nervatura del grafico spesso «scorre» su tutta la rete, con ritardi in aumento, ritai in esecuzione, code bloccate, guasti a cascata. La gestione delle dipendenze riduce il raggio di esplosione e rende prevedibili i rilasci.

• Vedere un conte completo di chiamate e capire chi dipende da chi.
• Prevenire guasti a cascata e «tempesta di retro».
• Pianificare le release in base alla compatibilità e alla presentazione SLO.
• Aumenta MTTR: trova più velocemente il nodo principale (root cause).

2) Tipi di dipendenze

Sincrono (RPC): connettività rigida per latenza/disponibilità. Ci servono timeout, breaker, budget dei retroscena.
Asincrona (Event/Stream: Kafka/Rabbit/Pulsar): connettività più sostenibile, ma ci sono lag/backlog e semantica di spedizione (at-least-once, idempotency).
Storage (DB/Cache/Object Store) - Risorse condivise di contest, limiti di connettività/IOPS, eviction, replica.
Provider esterni (PSP/KYC/Games Provider): quote, chiamate a pagamento, finestre di servizio, SLA legali.
Operative (release, ficcoflagi, confighi): dipendenze indirette attraverso impostazioni, segreti, schema registry.

3) Catalogo dei servizi e grafico delle dipendenze

• Proprietari (Squad/chat/On-call rota), repo, ambiente, manufatti.
• Appalti API (OpenAPI/AsyncAPI), versioni, compatibilità (back/forward).
• Dipendenze in entrata/uscita (upstream/downstream) con tipo (sync/async), criticità, attesa SLO.
• Budget di timeout/retrai, breaker, bullkhead pool.
• Dati sulle quote e sui limiti delle integrazioni esterne.

• `service: payments-api`
• Upstream: `user-profile` (sync), `risk-score` (async).
• Downstream: `PSP-X` (sync, квота 2k RPS), `ledger` (async).
• SLO: p99, 300 ms, 99. 9% uptime.
• Timeout: 200 ms a «PSP-X», 150 ms a «user-profile».
• Retrai: 2 con ritardo esponenziale, jitter.
• Breaker: aperto a 30 s con il 5% di errori/10 s

4) Scienze SLO e «budget della latitanza»

Con la catena di chiamate sincrone, il risultato SLO viene generato dalla somma dei ritardi e delle probabilità di guasto.

• Il budget della richiesta è frammentato dall'alto verso il basso: il fronte SLO 500 mc Edge 50 ms API 150 ms servizi di dominio 200 ms provider 100 mc.
• Timeout «fuori più breve che dentro»: il timeout del chiamante ha meno tempo interno totale per aggiornare le risorse anziché scavare chiamate zombie.
• Retrai solo per codici/eccezioni sicuri e con jitter; senza retrachi per i timeout delle strette (altrimenti tempesta).

5) Contratti e compatibilità

Versioning API: SemVer per i contratti; backward-compatibile modifiche tramite i campi optional, estensioni dello schema l'eliminazione è solo dopo il periodo di deprecazione.
Consumer-driven contracts (CDC) - I test dei consumatori (Pact-simili) vengono avviati contro il provider di CA; il rilascio viene bloccato in caso di incompatibilità.
Diagrammi di registro (Async): versione dei topic/eventi, evoluzione degli schemi (Avro/JSON-Schema), politica «can-read-old/can-write-new».

6) Modelli di stabilità dell'ingegneria

Timeouts: separiamo le aziende SLA dalle aspettative tecniche; Ogni connessione in uscita è un timeout.
Retries + backoff + jitter: non più di 2-3 tentativi, data l'idampotenza.
Circuito Breaker: «caduta rapida» durante il degrado del downstream; prova half-open.
Boolkhead (isolamento dei pool) - Per i diversi downstream, i singoli pool di thread/pool/connessioni.
Rate-limit/Leaky-bucket - per non uccidere downstream ai picchi.
Idempotency & deduplicazione: la chiave di idampotenza a livello di richiesta/messaggio; Nonno Leiter e Retrae Code.
Cache e follback: cache locale/distribuita, states stale-while-revalidate, degrado dei contenuti.

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) Osservazione delle dipendenze

Tracciati distribuiti (TraceID, Baggage) - Consente di visualizzare il percorso della query attraverso gli anelli. sonno alle chiamate in uscita con tag peer. service`, `retry`, `timeout`.
Метрики per-dependency: `outbound_latency_p99`, `outbound_error_rate`, `open_circuit`, `retry_count`, `queue_lag`.

• Mappa dei servizi con indicatore di colore SLO e costole errate.
• «Top N delle dipendenze problematiche» nell'ultima settimana.
• Blast radius è l'elenco dei servizi che verranno danneggiati dalla caduta di X.
• I loghi di correlazione includono «trace _ id »/« span _ id» nei registri.

8) Gestione delle release in base alle dipendenze

Dipendency-aware pipline - Il rilascio del provider viene bloccato se i test CDC dei consumatori sono rossi.
Accensione graduale (phicheflagi): nuovi campi/endoint per l' 1% dei consumatori 10% 100%.
Rilasci canari: controlliamo le principali dipendenze e il budget della latitanza sulla quota di traffico.
Compatibilità degli schemi: il produttore scrive «vNew», le consolle leggono «vOld/vNew»; dopo il passaggio, «raccolta rifiuti» dei vecchi campi.

9) Incidenti e escalation sul conte

Definiamo il «vero responsabile»: la correlazione alert - se il «PSP-X» è degradato, non il cercapersone dell'intero «arbusto», ma il proprietario dell'integrazione.

Modalità minima (endpoint meno pesanti, bandi tagliati, disattivazione di fiocchi non critici)

Garda a cascata: limitiamo il parallelismo, spegniamo i retrai su un ramo caldo, apriamo il breaker in anticipo (pre-open).

• Diagnostica: quali dashboard/metriche, come controllare quote/limiti.
• Azioni: ridurre RPS, passare al provider di backup, attivare temporaneamente le risposte cache.
• Reimpostazione e convalida: restituisci i parametri, assicurati che la norma p95/p99 e la regola error-rate siano ripristinate.

10) Matrice di criticità delle dipendenze

• Per i «critici» - doppio provider, breaker, pool singoli, test di caos.
• Per le «alte», almeno la degradazione e il pulsante verde per spegnere i fili.
• Per «medio-basso», i limiti per i retrai e il budget delle code.

11) Processo: dall'inventario all'utilizzo

1. Mappatura grafica - Raccogli chiamate effettive (ricalco) + dipendenze dichiarative dalla directory.
2. Assegnare i proprietari a ogni servizio e all'integrazione esterna - responsabile on-call.
3. Definisci SLO e budget: latitanza/errore, timeout/retrai/pool.
4. Formalizzare i contratti: OpenAPI/AsyncAPI, schemi e CDC.
5. Abilita i modelli di stabilità timeouts/retries/circuito/bulkhead.
6. Configura i dashboard e gli alert per-dipendency.
7. Inserisci release-gate come unità CDC/compatibilità/canarino.
8. Game-days regolari: esperimenti di caos per la caduta delle costole chiave.
9. Postmortem con un focus sulla comunicazione, che ha aumentato la cascata, come restringere il raggio.

12) Alerti di dipendenza (idee di regole)

• `outbound_error_rate{to="X"} > 3% FOR 10m` → warning; `>5% FOR 5m` → critical.
• `outbound_p99_latency{to="X"} > SLO1. 3 FOR 10m` → warning.

• ' circuito _ open {to =» X»} = = 1 FOR 1m's per il proprietario dell'integrazione.

• "retry _ rate {to =" X "}> baseline2 FOR 5m '+' outbound _ rps> 0 '→ il rischio tempesta.

• `consumer_lag{topic="Y"} growth > threshold FOR 10m` + `hpa at max` → крит.

• ' usage _ quota {provider =» PSP-X «}> 90% window' → l'avviso, la connessione automatica delle rotte.

13) Anti-pattern

«Un pool totale di flussi su tutti i downstream». Totale: head-of-line blocking. Dividete i pool.
Senza timeout/con ritai infiniti. È così che nasce la tempesta.
Ritraci ciechi di operazioni non idonee. Prese di prelievi/rate.
L'OBD nascosto è un punto di connettività. Una forte competizione e un blocco.
La versione API viene modificata senza CDC o deprecato. Catturate cadute di massa.
L'osservazione è solo sui servizi, non sulle comunicazioni. Non si vede dov'è la catena.

14) Dashboard: set minimo

Servizio Map: mappa interattiva dei servizi con metriche di costola (latency/error/volume).
Upstream/Downstream Overview: per il proprietario del servizio, dipendenze in entrata (chi chiama), in uscita (chi chiama), «top problemi».
Dipendency Drilldown: scheda di collegamento specifica: p50/p95/p99, errori di classe, percentuale di breaker aperto, retrai, pool di connessioni, quote/coast.
Release Text - Annotazioni di release/ficcaflagi nei grafici delle dipendenze.

15) Assegno-foglio di implementazione

• Catalogo dei servizi con proprietari e contratti (OpenAPI/AsyncAPI).
• Grafico completo delle dipendenze dai tracciati (aggiorna ogni giorno).
• SLO di servizio e «budget di latitanza» verso il basso della catena.
• Timeout esplicito, retrai con jitter, breaker, bulkhead-isolamento.
• Test CDC in CI come release gate.
• Dashboard per-dipendency e la mappa del servizio.
• Alert sulle costole + suppressione per la causa primaria.
• Game-days: riduzione del provider/cluster/topic e controllo della degradazione.
• Piano di degrado: quali feci disattiviamo, quali cache accendiamo.
• Regolari post-mortem con azioni di riduzione della connettività.

16) KPI di qualità per la gestione delle dipendenze

Dipendency MTTR - Mediana di recupero nervatura.
Blast Radius Index: numero medio di servizi interessati in caso di calo di uno.
Cupling Score: quota di dipendenze sync su tutti; trend al ribasso.
CDC Pass Rate:% di comunicati senza violazione di contratto.
Retry Storms/mese - Destinazione 0.
Cost of Esternal Calls - Costo delle chiamate esterne su 1k RPS (vedere l'effetto cache/follback).

17) Partenza rapida (default)

Timeout: 70-80% del budget; il timeout superiore della richiesta <importo interno.
Retrai: max 2, solo per Idempotent 5xx/rete, con backoff + jitter.
Breaker: soglia del 5% di errori in 10 s, open = 30 s, half-open test.
Bullkhead: pool/limiti di connessione selezionati per ogni downstream.
CDC obbligatorio per tutte le API pubbliche e topic.
Preferenza Async - Dove è possibile passare a eventi/code (finale temporale).

18) FAQ

Cosa c'è di più importante, retrai o breaker?
A: Entrambi. I retrai salvano dai guasti a breve termine, il breaker protegge dal degrado permanente e dalle tempeste.

Come si capisce che il legame è troppo fragile?
A: Elevata correlazione di errori, bassa quantità di timeout, frequenti retrai, mancanza di folleback/cache, catene lunghe sincronizzate.

Q: Perché il CDC se abbiamo dei test di integrazione?
A: Il CDC registra le aspettative del consumatore e rompe il rilascio del provider in caso di incompatibilità, prima che il codice entri in un provino.