Operațiuni și dependențe de servicii de gestionare a →

Dependențe de servicii

1) De ce aveți nevoie de ea

Orice producție-platformă este un număr: utilizatorii Edge/API servicii de domeniu transformă/fluxuri DB/caches furnizori externi (plăți, KYC, furnizori de jocuri). O eroare pe o margine a graficului adesea „merge” în întreaga rețea: întârzierile cresc, retraiele sunt declanșate, cozile sunt înfundate, apar eșecuri în cascadă. Managementul dependenței reduce „raza exploziei” și face eliberările previzibile.

• Vedeți graficul complet al apelurilor și înțelegeți cine depinde de cine.
• Preveniți eșecurile în cascadă și „furtuna din spate”.
• Planul lansează bazat pe compatibilitate și promovarea SLO.
• Raise MTTR: Găsiți adevărata cauză rădăcină mai repede.

2) Tipuri de dependențe

Sincron (RPC: REST/gRPC/GraphQL): conectivitate dură prin latenţă/disponibilitate. Avem nevoie de timeout-uri, întrerupătoare, retrage bugetul.
Asincron (Eveniment/Stream: Kafka/Iepure/Pulsar): conectivitate mai stabilă, dar există decalaj/restanțe și semantică de livrare (cel puțin o dată, idempotență).
Stocare (DB/Cache/Object store): resurse partajate → conținut, limite de conexiune/IOPS, evacuare, replicare.
Furnizori externi (PSP/KYC/furnizori de jocuri): cote, apeluri de taxare, ferestre de servicii, SLA-uri legale.
Operare (versiuni, phicheflags, configs): dependențe indirecte prin setări, secrete, registru schemă.

3) Catalog de servicii și grafice de dependență

• Proprietarii (Squad/chat/On-call rota), repo, mediu, artefacte.
• Contracte API (OpenAPI/AsyncAPI), versiuni, compatibilitate (înapoi/înainte).
• Dependențele de intrare/ieșire (în amonte/în aval) cu tipul (sincronizare/async), criticalitatea, așteptările SLO.
• Buget timeout/retragere, întrerupătoare, bazine perete.
• Date privind cotele și limitele integrărilor externe.

• 'serviciu: payments-api'
• În amonte: „profil de utilizator” (sincronizare), „scor de risc” (async).
• În aval: „PSP-X” (sincronizare, квота 2k RPS), „registru” (async).
• SLO: p99 ≤ 300ms, 99. 9% uptime.
• Timeout: 200 ms la „PSP-X”, 150 ms la „profil de utilizator”.
• Retrai: 2 cu întârziere exponențială, jitter.
• Breaker: deschis pentru 30 de ani la 5% erori/10s.

4) Propaganda SLO și „bugetul de latență”

Cu un lanț de apeluri sincrone, SLO total este format din suma de întârzieri și probabilități de eșec.

• Bugetul cererii este împărțit de sus în jos: front-end SLO 500 ms → Edge 50 ms → API 150 ms → domain services 200 ms → provider 100 ms.
• Timeout „sunt mai scurte decât în”: apelantul are un timeout mai mic decât totalul timeout intern, astfel încât resursele sunt actualizate, iar apelurile zombie nu sunt acumulate.
• Retrai numai pentru coduri/excepții sigure și cu jitter; fără retroys pentru blocarea timpilor (alias „furtună”).

5) Contracte și interoperabilitate

Versionare API: SemVer pentru contracte; schimbările compatibile înapoi prin câmpurile „opționale”, extensiile schemei; ștergerea - numai prin „perioada de depreciere”.
Contracte conduse de consumatori (CDC): testele efectuate de consumatori (cum ar fi pactul) împotriva furnizorului din IC; eliberarea este blocată dacă este incompatibilă.
Schema de înregistrare (Async): versiunea subiectelor/evenimentelor, evoluția schemelor (Avro/JSON-Schema), can-read-old/can-write-new policy.

6) Modele de stabilitate inginerie

Timeout: separarea SLA-urilor de cele tehnice; fiecare conexiune de ieșire este un timeout explicit.
Retrie + backoff + jitter: nu mai mult de 2-3 încercări, având în vedere idempotența.
Întrerupător de circuit: „cădere rapidă” în degradarea din aval; proces pe jumătate deschis.
Perete etanș (izolare bazin): pentru diferite downstreams - piscine separate de fluxuri/etaje/conexiuni.
Rate-limit/Leaky-găleată: pentru a nu ucide downstreams la vârfuri.
Idempotency & deduplication: cerere/mesaj nivel idempotency cheie; bunic-leiter și retragere-coadă.
Caching și folback-uri: cache-uri locale/distribuite, statusuri stale în timp ce revalidează, degradarea conținutului.

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) Observabilitatea dependențelor

Urme distribuite (TraceID, Baggage): vezi calea cererii prin link-uri; se întinde la apeluri de ieșire cu etichete "peer. serviciu "," reîncercare "," timeout ".
Метрики per-dependency: 'outbound _ latency _ p99', 'outbound _ error _ rate', 'open _ circuit', 'retry _ count',' queue _ lag '.

• SLO și harta de serviciu codată în culori cu margini eronate.
• „Top N dependențe problemă” pentru ultima săptămână.
• „Raza exploziei” - o listă de servicii care vor fi afectate de căderea lui X.
• Jurnalele de corespondență: includ 'trace _ id'/' span _ id' în jurnale.

8) Managementul eliberării conștiente de dependență

Conducte conștiente de dependență: Eliberarea furnizorului este blocată dacă testele CDC de consum sunt roșii.
Incluziune treptată (phicheflags): noi domenii/endoint-uri → pentru 1% dintre consumatori → 10% → 100%.
Canare: verificăm dependențele cheie și „bugetul de latență” cu privire la ponderea traficului.
Compatibilitatea sistemelor: producătorul scrie „vNew”, consumatorii citesc „vOld/vNew”; după tranziție - „colectarea gunoiului” de câmpuri vechi.

9) Incidente și escaladări pe coloane

Definim „adevăratul vinovat”: alert-corelation - dacă 'PSP-X' s-a degradat, nu punem pe pagină întregul „tufiș de plată”, ci proprietarul integrării.
Autodegradare: phicheflag „modul minim” (puncte finale mai puțin grele, pachete împodobite, dezactivarea caracteristicilor non-critice).
Garda de cascade: paralelism limită, opriți retras pe o ramură fierbinte, deschideți întrerupătorul în prealabil (pre-deschis).

• Diagnosticare: ce tablouri de bord/metrici, cum se verifică cotele/limitele.
• Acțiuni: reduceți SPR, treceți la un furnizor de backup, activați temporar răspunsurile cache.
• Rollback și validare: parametrii de returnare, asigurați-vă că norma este p95/p99 și rata de eroare.

10) Matricea critică a dependenței

• Pentru „critică” - dublă provizionare, întrerupătoare, bazine individuale, teste de haos.
• Pentru „ridicat” - cel puțin degradare și „butonul verde” pentru a opri caracteristica.
• Pentru „mediu/scăzut” - limite de retray și bugetul de coadă.

11) Proces: de la inventar la funcționare

1. Cartografiere grafic: colecta apeluri reale (urme) + dependențe declarative din directorul.
2. Atribuirea proprietarilor: pentru fiecare serviciu și integrare externă - responsabil la apel.
3. Definiți SLO-uri și bugete: latență/erori, timeout-uri/retroys/pools.
4. Formalizați contractele: OpenAPI/AsyncAPI, scheme și CDC.
5. Activați modele de stabilitate: timeouts/retries/circuit/perete.
6. Configurați tablouri de bord și alerte per dependență.
7. Instalați porți de lansare: bloc de CDC/compatibilitate/canar.
8. Zile regulate de joc: experimente haos pe care se încadrează marginile cheie.
9. Post-mortems cu accent pe comunicare: ce a întărit cascada, cum să îngusteze raza.

12) Alerte privind dependența (idei de reguli)

• ' outbound _ error _ rate {to =” X”}> 3% PENTRU 10m' → warning; '> 5% PENTRU 5m' → critic.
• ' outbound _ p99 _ latency {to =” X”}> SLO1. 3 PENTRU 10 m → avertisment.

• ' circuit _ open {to =” X „} = = 1 PENTRU 1m '→ pagină către proprietarul integrării.

• ' retry _ rate {to =” X „}> baseline2 PENTRU 5m '+ 'outbound _ rps> 0' → risc de furtună.

• ' consumer _ lag {topic =” Y”} creștere> prag PENTRU 10m' + 'hpa la max' → крит.

• ' usage _ cota {provider =” PSP-X „}> 90% fereastră 'avertizare →, rute de comutare automată.

13) Anti-modele

"O piscină flux comun pentru toate downstreams. "Total: blocarea capului de linie. Împărţiţi piscinele.
Fără pauze de timp/cu retrasări nesfârșite. Se naşte o furtună.
Retraiele oarbe ale operațiilor non-idempotente. Duplicat write-off/pariuri.
„DB partajat” ascuns ca punct de conectivitate. Concurenţă puternică şi blocaje.
Versiunea API se schimbă fără CDC și planul de depreciere. Masa de captură cade.
Observabilitate doar prin servicii, nu prin conexiuni. Nu este vizibil în cazul în care lanțul se rupe.

14) Tablouri de bord: set minim

Harta serviciilor: o hartă interactivă a serviciilor cu valori de margine (latență/eroare/volum).
În amonte/Downstream Prezentare generală: pentru proprietarul serviciului - dependențe primite (care este de asteptare), de ieșire (care este de asteptare), „probleme de top”.
Dependență Drilldown: link-ul card specific: p50/p95/p99, erori de clasă, procent întrerupător deschis, retribuții, piscină de conectare, cote/cost.
Release Context: adnotări de versiuni/phicheflags pe grafice de dependență.

15) Lista de verificare a implementării

• Director de servicii cu proprietarii și contracte (OpenAPI/AsyncAPI).
• Graficul complet al dependențelor din urme (actualizare zilnică).
• SLO prin servicii și „bugete de latență” în jos lanț.
• Timeout explicit, jitter se retrage, întrerupătoare, izolarea pereților etanși.
• Testele CDC în CI ca poartă de eliberare.
• Tablouri de bord per dependență și card de serviciu.
• Alerte pe margini + suprimarea de cauza rădăcină.
• Game-days: provider/cluster/topic drop and degradation check.
• Planul de degradare: ce caracteristici ne dezactivăm, ce cache pornim.
• Postmortems regulate cu acțiuni pentru a reduce conectivitatea.

16) KPI-uri de calitate pentru managementul dependenței

Dependenţă MTTR: recuperarea costală mediană.
Indicele de rază explozivă: numărul mediu de servicii afectate atunci când una scade.
Scor de cuplare: proporția de dependențe de sincronizare între toate; tendință descendentă.
Rata CDC Pass:% din eliberări fără încălcarea contractului.
Încercați din nou furtuni/luna țintă → 0.
Costul apelurilor externe: costul apelurilor externe pe 1k SPR (a se vedea efectul caching/folback).

17) Pornire rapidă (valori implicite)

Timeout: 70-80% din bugetul link-ului; solicita timeout superior <suma internă.
Retrai: max 2, numai pe idempotent 5xx/rețea, cu backoff + jitter.
Breaker: prag de erori de 5% în 10 s, deschis = 30 s, probe pe jumătate deschise.
Perete etanș: piscine dedicate/limite de conectare pe aval.
CDC: Obligatoriu pentru toate API-urile și subiectele publice.
Async-preferință: acolo unde este posibil - trecerea la evenimente/cozi (decuplare în timp).

18) ÎNTREBĂRI FRECVENTE

Î: Ce este mai important: o retragere sau un întrerupător?
R: Ambele. Retrai salva de la eșecuri pe termen scurt, întrerupător protejează de degradare permanentă și furtuni.

Î: De unde știi că conexiunea este „prea fragilă”?
R: Corelație de eroare ridicată, marjă de timp scăzută, retractări frecvente, fără folback/cache, lanțuri lungi sincrone.

Î: De ce CDC dacă avem teste de integrare?
R: CDC surprinde așteptările consumatorilor și rupe eliberarea furnizorului atunci când este incompatibil - înainte ca codul să intre în producție.