Operacje i → Zależność od usług zarządzania
Zależności od usług
1) Dlaczego go potrzebujesz
Każda platforma produkcyjna jest licznikiem: użytkownicy → Krawędź/API → usługi domeny → obroty/strumienie → DB/caches → dostawcy zewnętrzni (płatności, KYC, dostawcy gier). Błąd na jednej krawędzi wykresu często „idzie” po sieci: opóźnienia rosną, przekładki są uruchamiane, kolejki są zatykane, pojawiają się awarie kaskadowe. Zarządzanie zależnością zmniejsza „promień wybuchu” i sprawia, że uwolnienia są przewidywalne.
Cele:- Zobacz pełny wykres połączeń i zrozumieć, kto zależy od kogo.
- Zapobiegaj awariom kaskady i „burza retray”.
- Wersje planu oparte na kompatybilności i promocji SLO.
- Podnieś MTTR: Znajdź prawdziwą przyczynę korzenia szybciej.
2) Rodzaje zależności
Synchroniczny (RPC: REST/gRPC/GraphQL): twarda łączność według opóźnienia/dostępności. Potrzebujemy terminów, przełamań, przekwalifikowania budżetu.
Asynchroniczny (Event/Stream: Kafka/Królik/Pulsar): bardziej stabilna łączność, ale istnieje opóźnienie/zaległości i semantyka dostawy (co najmniej raz, idempotencja).
Przechowywanie (DB/Cache/Object store): udostępnione zasoby → zawartość, limity połączeń/IOPS, eksmisja, replikacja.
Dostawcy zewnętrzni (PSP/KYC/dostawcy gier): kwoty, połączenia płatne, okna serwisowe, prawne SLA.
Działanie (wersje, ficheflagi, konfiguracje): pośrednie zależności poprzez ustawienia, sekrety, rejestr schematów.
3) Katalog usług i wykresy zależności
Co naprawiamy w katalogu (Backstage/Service Catalog/CMDB):- Właściciele (Squad/chat/On-call rota), repo, środowisko, artefakty.
- Umowy API (OpenAPI/AsyncAPI), wersje, kompatybilność (back/forward).
- Zależność przychodząca/wychodząca (w górę/w dół) z typem (synchronizacja/async), krytyczność, oczekiwania SLO.
- Budżet czasu/rekolekcji, wyłączniki, baseny grodziowe.
- Dane dotyczące kwot i limitów integracji zewnętrznych.
- „służba: płatności-api”
- W górnym biegu: 'profil użytkownika' (synchronizacja), 'wynik ryzyka' (async).
- Poniżej: „PSP-X” (sync, квота 2k RPS), „ledger” (async).
- SLO: p99 ≤ 300 ms, 99. 9% uptime.
- Terminy: 200 ms do 'PSP-X', 150 ms do 'profilu użytkownika'.
- Retrai: 2 z wykładniczym opóźnieniem, jitter.
- Wyłącznik: otwarty dla 30s przy 5% błędów/10s.
4) propaganda SLO i „budżet opóźnienia”
Z łańcuchem wywołań synchronicznych, całkowite SLO powstaje z sumy opóźnień i prawdopodobieństwa awarii.
Zasady:- Budżet wniosku jest podzielony od góry do dołu: front-end SLO 500 ms → Edge 50 ms → API 150 ms → usługi domeny 200 ms → dostawca 100 ms.
- Timeouts „out są krótsze niż w”: rozmówca ma czas krótszy niż całkowity wewnętrzny czas, tak aby zasoby były aktualizowane, a połączenia zombie nie są gromadzone.
- Retrai tylko dla bezpiecznych kodów/wyjątków i z jitter; brak retras dotyczących czasowych wąskich gardeł (zwanych dalej „burzą”).
5) Umowy i interoperacyjność
Weryfikacja API: SemVer w przypadku umów; zmiany kompatybilne wstecz poprzez pola „opcjonalne”, rozszerzenia schematu; usunięcie - tylko przez „okres deprecate”.
Umowy konsumenckie (CDC): Testy konsumenckie (podobne do paktu) prowadzone przeciwko dostawcy w CI; uwolnienie jest zablokowane, jeśli jest niezgodne.
Schemat rejestrowania (Async): wersja tematów/zdarzeń, ewolucja schematów (Avro/JSON-Schema), can-read-old/can-write-new policy.
6) Modele stabilności inżynierii
Terminy: oddzielenie SLA dla przedsiębiorstw od oczekiwań technicznych; każde połączenie wychodzące jest wyraźnym terminem.
Retries + backoff + jitter: nie więcej niż 2-3 próby, biorąc pod uwagę idempotencję.
Wyłącznik: „szybki spadek” w dalszej degradacji; w połowie otwartego procesu.
Grodzisko (izolacja basenu): dla różnych poniżej - oddzielne baseny strumieni/podłóg/połączeń.
Tempo-limit/Wyciek-wiadro: aby nie zabijać niższych strumieni na szczytach.
Idempotence & deduplication: request/message level idempotence key; dziadek-leiter i odwrót-kolejka.
Buforowanie i pęcherzyki: bufory lokalne/rozproszone, statusy przewlekłe, degradacja zawartości.
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) Obserwowalność zależności
Dystrybuowane ślady (TraceID, Bagaż): patrz ścieżka żądania linkami; przęsła do rozmów wychodzących z 'peer tags. usługi "," retry "," timeout ".
Метрика-per-dependency: 'outbound _ latency _ p99', 'outbound _ error _ rate', 'open _ circuit', 'retry _ count',' queue _ lag '.
- SLO i błędna mapa usługi kodowana kolorem krawędzi.
- „Zależność od problemu Top N” na ostatni tydzień.
- „Blast promień” - lista usług, na które wpłynie upadek X.
- Dzienniki korelacji: w dziennikach wpisz 'trace _ id'/' span _ id'.
8) Zarządzanie uwolnieniem ze względu na zależność
Rurociągi zależnościowe: Zwolnienie dostawcy jest zablokowane, jeśli konsumenckie testy CDC są czerwone.
Stopniowa integracja (phicheflags): nowe pola/punkty końcowe → dla 1% konsumentów → 10% → 100%.
Kanaryjskie wydania: sprawdzamy kluczowe zależności i „budżet opóźnienia” od udziału ruchu.
Zgodność systemów: producent pisze „vNew”, konsumenci czytają „vOld/vNew”; po przejściu - „zbieranie śmieci” starych pól.
9) Incydenty i eskalacje według kolumn
Definiujemy „prawdziwy winowajca”: alert-correlation - jeśli 'PSP-X' uległ degradacji, nie zakładamy całego „buszu płatniczego”, ale właściciela integracji.
Autodegradacja: phicheflag „tryb minimalny” (mniej ciężkie punkty końcowe, przycięte wiązki, wyłączanie funkcji niekrytycznych).
Ochrona przed kaskadami: ograniczyć równoległość, wyłączyć retras na gorącej gałęzi, otworzyć wyłącznik z wyprzedzeniem (pre-open).
- Diagnostyka: jakie deski rozdzielcze/mierniki, jak sprawdzić limity/limity.
- Akcje: zmniejszyć RPS, przejść do dostawcy kopii zapasowych, tymczasowo włączyć odpowiedzi pamięci podręcznej.
- Rollback i walidacja: parametry zwrotu, upewnij się, że norma jest p95/p99 i szybkość błędów.
10) Matryca krytyki zależności
Ocenić każdy link wzdłuż osi: Zasady:- Dla „krytycznych” - podwójne zaopatrzenie, wyłączniki, pojedyncze baseny, testy chaosu.
- Dla „wysokiego” - przynajmniej degradacja i „zielony przycisk”, aby wyłączyć funkcję.
- „Średnie/niskie” - limity przekwalifikowania i budżet kolejki.
11) Proces: od inwentarza do eksploatacji
1. Mapowanie wykresu: zbierz rzeczywiste połączenia (ślady) + deklaracyjne zależności z katalogu.
2. Przypisz właścicieli: dla każdej usługi i integracji zewnętrznej - odpowiedzialny dyżur.
3. Zdefiniuj SLO i budżety: opóźnienia/błędy, timeouts/retrays/pools.
4. Formalizuj umowy: OpenAPI/AsyncAPI, schematy i CDC.
5. Włączyć wzorce stabilności: timeouts/retries/circuit/bulkhead.
6. Konfiguruj deski rozdzielcze i alerty na zależność.
7. Instalacja bram uwalniających: blok przez CDC/kompatybilność/canary.
8. Regularne dni gry: eksperymenty chaosu na spadających krawędziach kluczy.
9. Zwłoki z naciskiem na komunikację: co wzmocniło kaskadę, jak zawęzić promień.
12) Wpisy dotyczące uzależnienia (pomysły na zasady)
Składniki synchroniczne:- ' outbound _ error _ rate {to =” X”}> 3% FOR 10m' → warning; '> 5% FOR 5m' → critical.
- "outbound _ p99 _ latency {do =" X "}> SLO1. 3 DLA 10m' → ostrzeżenie.
- ' circuit _ open {to =” X „} = = 1 FOR 1m '→ strona do właściciela integracji.
- 'retry _ rate {to =' X '}> baseline2 FOR 5m' + 'outbound _ rps> 0' → ryzyko burzy.
- 'consumer _ lag {topic =' Y '} wzrost> próg FOR 10m' + 'hpa at max' → крий.
- 'usage _ quota {provider =' PSP-X '}> 90% window' → warning, auto-switch routes.
13) Anty-wzory
"Jeden wspólny strumień dla wszystkich poniżej. "Razem: blokowanie głowicy linii. Podziel baseny.
Brak terminów/z niekończącymi się relacjami. Więc narodziła się burza.
Ślepy przekaz zabiegów nieidempotentnych. Duplikat odpisów/zakładów.
Ukryty „wspólny DB” jako punkt łączności. Silna konkurencja i blokady.
Wersja API zmienia się bez CDC i deprecate plan. Masa połowowa spada.
Obserwowalność tylko przez usługi, a nie przez połączenia. Nie widać, gdzie łańcuch pęka.
14) Deski rozdzielcze: minimalny zestaw
Mapa usług: interaktywna mapa usług z metrykami krawędzi (opóźnienie/błąd/wolumin).
Przegląd upstream/Downstream: dla właściciela usługi - przychodzące zależności (kto dzwoni), wychodzące (kto dzwoni), „top problems”.
Zależność Drilldown: szczegółowa karta linku: p50/p95/p99, błędy klasy, procent otwarcia wyłącznika, przekładki, pula połączeń, kwoty/koszt.
Kontekst wydania: adnotacje wersji/ficheflagów na wykresach zależności.
15) Lista kontrolna wdrażania
- Katalog usług z właścicielami i kontraktami (OpenAPI/AsyncAPI).
- Pełny wykres zależności od śladów (aktualizacja dzienna).
- SLO według usług i „budżetów opóźnień” w łańcuchu.
- Wyraźne timeouts, jitter retreats, breakers, gródź izolacji.
- Testy CDC w CI jako brama uwolnienia.
- Deski rozdzielcze na zależność i kartę serwisową.
- Wpisy na krawędziach + tłumienie przez przyczynę korzenia.
- Dni gry: dostawca/klaster/topic drop and degradation check.
- Plan degradacji: które cechy wyłączamy, które bufory włączamy.
- Regularne postmortemy z działaniami na rzecz zmniejszenia łączności.
16) KPI jakości zarządzania zależnością
Zależność MTTR: mediana odzysku żeber.
Wskaźnik Blast Radius: średnia liczba usług dotkniętych spadkiem.
Wynik sprzężenia: odsetek zależności synchronizacji wśród wszystkich; tendencja spadkowa.
CDC Pass Rate:% zwolnień bez naruszeń umowy.
Retry Storms/Month Target → 0.
Koszt połączeń zewnętrznych: koszt połączeń zewnętrznych na 1k RPS (patrz efekt buforowania/pęcherzyków).
17) Szybki start (domyślne)
Harmonogram: 70-80% budżetu na łącza; zażądać górnego limitu czasu <sumy wewnętrznej.
Retrai: max 2, tylko na idempotent 5xx/sieć, z backoff + jitter.
Wyłącznik: próg 5% błędów w 10 s, otwarty = 30 s, próbki w połowie otwarte.
Grodzisko: dedykowane baseny/limity połączeń na niższy szczebel.
CDC: Obowiązkowe dla wszystkich publicznych API i tematów.
Preferencja async: w miarę możliwości - przejście na zdarzenia/kolejki (oddzielenie od produkcji w czasie).
18) FAQ
P: Co jest ważniejsze: odosobnienie lub wyłącznik?
Odp.: Obie. Retrai oszczędza przed krótkotrwałymi awariami, wyłącznik chroni przed trwałą degradacją i burzami.
P: Skąd wiesz, że połączenie jest „zbyt kruche”?
Odp.: Wysoka korelacja błędów, niski margines czasu, częste przekaźniki, brak pęcherzyków/buforów, synchroniczne długie łańcuchy.
P: Dlaczego CDC, jeśli mamy testy integracyjne?
Odp.: CDC przechwytuje oczekiwania konsumentów i łamie zwolnienie dostawcy, gdy jest niezgodny - zanim kod dostanie się do produkcji.