Historia pytania
Wykrywanie zakleszczeń rozproszonych stało się krytycznym zagadnieniem podczas przejścia z architektur monolitycznych do drobnoziarnistych mikroserwisów w połowie lat 2010. Wczesne systemy rozproszone polegały na przerywaniach na podstawie czasów oczekiwania lub centralnych menedżerach blokad, które okazały się niewystarczające dla środowisk chmurowych wymagających wysokiej dostępności i tolerancji na podziały. Algorytm Chandy-Misra-Haas ustanowił teoretyczne podstawy dla ścigania krawędzi w rozproszonych grafach, jednak praktyczne implementacje borykały się z hałasem sieciowym i heterogenicznymi stosami usług. Nowoczesne architektury wymagają autonomicznych mechanizmów detekcji, które działają bez centralnej koordynacji, szanując jednocześnie ściśle określone cele poziomu usług.
Problem
W ekosystemie mikroserwisowym transakcje często rozciągają się na wiele usług i technologii przechowywania, tworząc rozproszone cykle, w których Usługa A posiada blokadę w PostgreSQL, czekając na Usługę B, która z kolei posiada blokadę MongoDB, czekając na Usługę A. Centralne detektory zakleszczeń wprowadzają pojedyncze punkty awarii i gorące miejscami sieciowe, naruszając zasady autonomii mikroserwisów. Podejścia oparte na czasach oczekiwania cierpią na fałszywe alarmy w warunkach wysokiej latencji i nie mogą odróżnić między wolnymi operacjami a rzeczywistymi zakleszczeniami. Fundamentalne wyzwanie wymaga wykrywania cykli w dynamicznym, podzielonym grafie, gdzie węzły mogą zawieść lub stać się niedostępne bez ostrzeżenia.
Rozwiązanie
Architektura wykorzystuje algorytm ścigania krawędzi Chandy-Misra-Haas osadzony w sidecarach Envoy, wdrażanych za pomocą Kubernetes. Każdy sidecar utrzymuje lokalny graf oczekiwań i propaguje wiadomości probe z czasami Lamporta wzdłuż łańcuchów wywołań gRPC w celu wykrywania cykli. Klaster Redis przechowuje przejrzystą relację oczekiwania z wygaśnięciem TTL, aby obsłużyć utratę probe, podczas gdy Kafka przesyła polecenia rozwiązania dla wyboru ofiary na podstawie zapisów priorytetów biznesowych przechowywanych w etcd. System wykorzystuje protokoły plotkowe do rozpowszechniania probe podczas podziałów płaszczyzny kontrolnej, zapewniając żywotność bez poświęcania bezpieczeństwa.
Opis problemu
Podczas wydarzenia Black Friday na platformie handlu o wysokiej częstotliwości, usługa orkiestracji płatności doświadczyła kaskadowych awarii podczas blokowania kursów walutowych. Usługa FX oparta na Java zsynchronizowana z walidatorem zgodności opartym na Go, tworzyła cykliczną zależność, która zamarła 15,000 równoczesnych transakcji przez osiemnaście minut. Straty przychodów przekroczyły 2 miliony dolarów, gdy synchroniczne wywołania REST między usługami zgubiły się w zakleszczeniu, uruchamiając kaskadowe awarie wyłączników obwodowych w infrastrukturze AWS. Incydent ujawnił niezdolność detekcji czasów oczekiwania na poziomie bazy danych do wykrywania cykli między usługami obejmującymi heterogeniczne technologie.
Rozwiązania rozważane
Pierwotnie rozważaliśmy wdrożenie centralnej bazy danych Oracle RAC jako globalnego koordynatora transakcji śledzącego wszystkie blokady zasobów między usługami. Podejście to oferowało prostą detekcję cykli za pomocą standardowych algorytmów grafowych i bezpośrednie rozwiązanie konfliktów. Jednakże wprowadzało katastrofalny pojedynczy punkt awarii, wymagający gwarancji dostępności na poziomie 99.999% i dodawania 200 ms opóźnienia do każdej transakcji z powodu podróży między regionami. Podczas podziałów sieciowych koordynator stałby się niedostępny, zamrażając całe przetwarzanie płatności na świecie, a nie izolując awarię.
Zespół ocenił agresywną strategię ograniczeń czasowych z wykładniczym opóźnieniem, przerywając wszelkie transakcje przekraczające pięć sekund i próbując ponownie z drganiem. To wyeliminowało narzut koordynacji i nie wymagało zmian w infrastrukturze poza konfiguracjami wirtualnych usług Istio. Niestety, spowodowało to masowe grzebanie pod obciążeniem z fałszywymi alarmami na poziomie 40%, ponieważ uzasadnione wolne zapytania były mylone z zakleszczeniami. Powstające burze retry przeciążały sieć usług i powodowały gorszy zator niż pierwotne zakleszczenia, naruszając SLA latencji.
Analizowaliśmy mechanizm ścigania krawędzi rozproszonej z wykorzystaniem filtrów Envoy WASM do wstrzykiwania logiki probe w sieć usług bez modyfikacji kodu aplikacji. Każdy sidecar publikowałby krawędzie oczekiwania na lokalny strumień Redis z 30-sekundowymi TTL, podczas gdy agent w tle sprawdzałby cykle używając probe Chandy-Misra-Haas oznaczonych zegarami wektorowymi. Wybór ofiary priorytetowałby transakcje o wysokich przychodach, zapytując etcd o wyniki krytyczności biznesowej, zapewniając, że najpierw przerywane byłyby niskopriorytetowe zadania wsadowe. Ta architektura obiecywała detekcję poniżej 100 ms przy zachowaniu odporności na całkowite awarie regionalne AWS poprzez przekazywanie probe oparte na plotkach.
Wybrane rozwiązanie i dlaczego
Wybraliśmy podejście ścigania krawędzi, ponieważ zachowało autonomię usług i wyeliminowało ryzyko dostępności koordynacji centralnej. Rozwiązanie skalowało się horyzontalnie wraz z liczbą instancji usługi, nie wymagając kosztownych aktualizacji mainframe, a filtry WASM pozwalały na wsparcie poliglotów zarówno dla mikroserwisów Java, jak i Go bez zmian kodu. Osadzając detekcję w warstwie infrastrukturalnej, odłączyliśmy rozwiązanie zakleszczeń od ewolucji logiki biznesowej, co umożliwiło niezależne skalowanie możliwości detekcji.
Wynik
Po wdrożeniu, awarie spowodowane zakleszczeniami zmniejszyły się do zera w ciągu sześciu miesięcy eksploatacji, w tym podczas dwóch dużych wydarzeń sprzedażowych. Latencja detekcji pozostała stabilna na poziomie 85 ms p99 nawet podczas 20-krotnego pikowania ruchu, podczas gdy automatyczne rozwiązanie zachowało 99,98% transakcji wysokopriorytetowych w czasie symulowanych awarii regionalnych. Produktywność deweloperów wzrosła, gdy zespoły usunęły własną logikę czasu oczekiwania, skracając czas reakcji na incydenty z godzin do automatycznych sekund i zapobiegając szacunkowej stracie rocznej na poziomie 5 milionów dolarów.
Jak odróżniasz prawdziwe zakleszczenia rozproszone od fałszywych pozytywów spowodowanych drganiem latencji sieci lub dostarczeniem probe w nieodpowiedniej kolejności?
Kandydaci często pomijają konieczność użycia zegarów wektorowych lub czasów Lamporta w wiadomościach probe, aby ustalić porządek przyczynowy zależności oczekiwania. Bez logicznych znaczników czasowych, opóźniony probe mógłby dotrzeć po tym, jak transakcja zwolni swoje blokady, fałszywie wskazując cykl i powodując niepotrzebne przerywania. Rozwiązanie wymaga wdrożenia liczników TTL dla probe oraz wymagania potwierdzenia drogi odwrotnej przed ogłoszeniem zakleszczenia, zapewniając, że przejrzyste opóźnienia sieciowe nie wywołują fałszywego wyboru ofiar.
Dlaczego detekcja zakleszczenia na poziomie bazy danych nie rozwiązuje zakleszczeń między usługami w architekturze z persystencją poligloty?
PostgreSQL i MongoDB wykrywają cykle tylko w obrębie swoich procesów, pozostając ślepi na sytuacje, gdy transakcja posiada blokadę wiersza w PostgreSQL, czekając na blokadę dokumentu w MongoDB lub wiadomość w RabbitMQ. Kandydaci muszą wyjaśnić, że wymagane jest instrumentowanie na poziomie aplikacji lub siatki usług, aby śledzić zależności między zasobami, zazwyczaj przez instrumentowanie spanów OpenTelemetry w celu rekonstrukcji rozproszonych grafów oczekiwań w heterogenicznych systemach przechowywania.
Jak utrzymujesz żywotność systemu podczas podziałów sieciowych, jednocześnie zapobiegając rozdzieleniu dwóch grup w celu rozwiązania tego samego zakleszczenia?
To ujawnia napięcie między dostępnością a bezpieczeństwem w systemach rozproszonych. Podczas podziałów usługi nie mogą odróżnić między zakleszczonymi rówieśnikami a niedostępnymi, co skłania kandydatów do proponowania rozwiązań, które albo poświęcają dostępność, albo ryzykują duplikatowe przerywania. Poprawne podejście stosuje konsensus odporny na błędy Byzantine do wyboru ofiary tylko wśród osiągalnych węzłów, w połączeniu z CRDT (Conflict-free Replicated Data Types) do rekonsolidacji grafu oczekiwań, zapewniając, że po naprawie podziałów system zbiega się na spójnym rozwiązaniu bez ręcznej interwencji.