GH GambleHub

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.
Mini przykładowa karta:
  • „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.

Pseudo-config (idea):

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 '.

Deski rozdzielcze na wyższym/niższym poziomie:
  • 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).

Szablon książki startowej:
  • 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:
ParaTypKrytyczność (GGR/SLA)Pole roboczeKontyngenty/limityWłaściciel
„api → wypłaty”synchronizacjaWysokaczęściowy depozyt offline2k RPSpłatności squadowe
„wypłaty → PSP-X”synchronizacjaKrytycznePamięć podręczna PSP-U/token1. 5k RPSintegracje
„bets → wynik ryzyka”asyncŚredniadegradacja do wartości domyślnejryzyko
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.
Wyłącznik:
  • ' circuit _ open {to =” X „} = = 1 FOR 1m '→ strona do właściciela integracji.
Retrai:
  • 'retry _ rate {to =' X '}> baseline2 FOR 5m' + 'outbound _ rps> 0' → ryzyko burzy.
Async:
  • 'consumer _ lag {topic =' Y '} wzrost> próg FOR 10m' + 'hpa at max' → крий.
Kwoty zewnętrzne:
  • '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.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.