Wzorzec transakcji rozproszonych saga

Wzorzec projektowy saga to sposób zarządzania spójnością danych między mikrousługami w scenariuszach transakcji rozproszonych. Saga to sekwencja transakcji, która aktualizuje każdą usługę i publikuje komunikat lub zdarzenie w celu wyzwolenia następnego kroku transakcji. Jeśli krok zakończy się niepowodzeniem, saga wykonuje transakcje wyrównywujące, które przeciwdziałają poprzednim transakcjom.

Kontekst i problem

Transakcja jest jedną jednostką logiki lub pracy, czasami składa się z wielu operacji. W ramach transakcji zdarzenie jest zmianą stanu, która występuje w jednostce, a polecenie hermetyzuje wszystkie informacje potrzebne do wykonania akcji lub wyzwolenia późniejszego zdarzenia.

Transakcje muszą być niepodzielne, spójne, izolowane i trwałe (ACID). Transakcje w ramach jednej usługi to ACID, ale spójność danych między usługami wymaga strategii zarządzania transakcjami między usługami.

W architekturach wielousługowych:

• Niepodzielność jest niepodzielnym i niepodzielnym zestawem operacji, które muszą wystąpić lub nie wystąpiły żadne operacje.
• Spójność oznacza, że transakcja przenosi dane tylko z jednego prawidłowego stanu do innego prawidłowego stanu.
• Izolacja gwarantuje, że współbieżne transakcje generują ten sam stan danych, który sekwencyjnie wykonałby transakcje.
• Trwałość gwarantuje, że zatwierdzone transakcje pozostają zatwierdzone nawet w przypadku awarii systemu lub awarii zasilania.

Model bazy danych na mikrousług zapewnia wiele korzyści dla architektur mikrousług. Hermetyzowanie danych domeny umożliwia każdej usłudze korzystanie z najlepszego typu i schematu magazynu danych, skalowania własnego magazynu danych w razie potrzeby i izolacji przed awariami innych usług. Jednak zapewnienie spójności danych w bazach danych specyficznych dla usługi stanowi wyzwanie.

Transakcje rozproszone, takie jak protokół zatwierdzania dwufazowego (2PC), wymagają od wszystkich uczestników transakcji zatwierdzenia lub wycofania przed kontynuowaniem transakcji. Jednak niektóre implementacje uczestników, takie jak bazy danych NoSQL i brokera komunikatów, nie obsługują tego modelu.

Innym ograniczeniem transakcji rozproszonej jest synchronizacja i dostępność komunikacji międzyprocesowej (IPC ). Protokół IPC dostarczany przez system operacyjny umożliwia oddzielne procesy udostępniania danych. W przypadku transakcji rozproszonych do zatwierdzenia wszystkie usługi uczestniczące muszą być dostępne, potencjalnie zmniejszając ogólną dostępność systemu. Implementacje architektury z ograniczeniami IPC lub transakcji są kandydatami do wzorca Saga.

Rozwiązanie

Wzorzec saga zapewnia zarządzanie transakcjami przy użyciu sekwencji transakcji lokalnych. Lokalna transakcja to niepodzielna praca wykonywana przez uczestnika sagi. Każda transakcja lokalna aktualizuje bazę danych i publikuje komunikat lub zdarzenie w celu wyzwolenia następnej transakcji lokalnej w sagi. Jeśli transakcja lokalna zakończy się niepowodzeniem, saga wykonuje serię transakcji wyrównywujących , które cofają zmiany wprowadzone przez poprzednie transakcje lokalne.

W wzorach Saga:

• Kompensowalne transakcje to transakcje , które mogą być potencjalnie odwrócone, przetwarzając inną transakcję z przeciwległym efektem.
• Transakcja przestawna to punkt go/no-go w sagi. Jeśli transakcja przestawna zostanie zatwierdzeń, saga zostanie uruchomiona do momentu ukończenia. Transakcja przestawna może być transakcją, która nie jest ani możliwa do ponawiania próby, ani nie może być ostatnią transakcją, którą można wykonać, lub pierwszą transakcją z możliwością ponawiania w sagi.
• Transakcje z możliwością ponawiania prób to transakcje , które są zgodne z transakcją przestawną i są gwarantowane powodzenie.

Istnieją dwa typowe podejścia implementacji sagi, choreografia i aranżacja. Każde podejście ma własny zestaw wyzwań i technologii do koordynowania przepływu pracy.

Choreografia

Choreografia to sposób koordynowania sag, w których uczestnicy wymieniają wydarzenia bez scentralizowanego punktu kontroli. Z choreografią każda transakcja lokalna publikuje zdarzenia domeny, które wyzwalają transakcje lokalne w innych usługach.

Korzyści

• Dobry dla prostych przepływów pracy, które wymagają kilku uczestników i nie potrzebują logiki koordynacji.
• Nie wymaga dodatkowej implementacji i konserwacji usługi.
• Nie wprowadza jednego punktu awarii, ponieważ obowiązki są rozłożone na uczestników sagi.

Wady

• Przepływ pracy może stać się mylący podczas dodawania nowych kroków, ponieważ trudno jest śledzić, którzy uczestnicy sagi słuchają poleceń.
• Istnieje ryzyko cyklicznej zależności między uczestnikami sagi, ponieważ muszą korzystać ze sobą poleceń.
• Testowanie integracji jest trudne, ponieważ wszystkie usługi muszą być uruchomione w celu symulowania transakcji.

Aranżacja

Orkiestracja to sposób koordynowania sag, w których scentralizowany kontroler informuje uczestników sagi o tym, co mają być wykonywane transakcje lokalne. Orkiestrator saga obsługuje wszystkie transakcje i informuje uczestników, które operacje mają być wykonywane na podstawie zdarzeń. Orkiestrator wykonuje żądania sagi, przechowuje i interpretuje stany każdego zadania i obsługuje odzyskiwanie po awarii za pomocą transakcji wyrównywalnych.

Korzyści

• Dobrze w przypadku złożonych przepływów pracy obejmujących wielu uczestników lub nowych uczestników dodanych w czasie.
• Nadaje się do kontroli nad każdym uczestnikiem procesu i kontroli nad przepływem działań.
• Nie wprowadza cyklicznych zależności, ponieważ orkiestrator jednostronnie zależy od uczestników sagi.
• Uczestnicy saga nie muszą wiedzieć o poleceniach dla innych uczestników. Jasne rozdzielenie problemów upraszcza logikę biznesową.

Wady

• Dodatkowa złożoność projektowania wymaga implementacji logiki koordynacji.
• Występuje dodatkowy punkt awarii, ponieważ koordynator zarządza kompletnym przepływem pracy.

Problemy i kwestie do rozważenia

Podczas implementowania wzorca Saga należy wziąć pod uwagę następujące kwestie:

• Wzorzec saga może początkowo być trudny, ponieważ wymaga nowego sposobu myślenia o sposobie koordynowania transakcji i utrzymania spójności danych dla procesu biznesowego obejmującego wiele mikrousług.
• Wzorzec saga jest szczególnie trudny do debugowania, a złożoność rośnie wraz ze wzrostem liczby uczestników.
• Nie można wycofać danych, ponieważ uczestnicy sagi zatwierdzają zmiany w lokalnych bazach danych.
• Implementacja musi być w stanie obsługiwać zestaw potencjalnych błędów przejściowych i zapewnić idempotencję w celu zmniejszenia skutków ubocznych i zapewnienia spójności danych. Idempotence oznacza, że ta sama operacja może być powtarzana wiele razy bez zmiany początkowego wyniku. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zapewniania idempotencji podczas przetwarzania komunikatów i aktualizowania stanu razem.
• Najlepiej zaimplementować możliwość obserwacji, aby monitorować i śledzić przepływ pracy sagi.
• Brak izolacji danych uczestnika nakłada wyzwania związane z trwałością. Implementacja sagi musi obejmować środki zaradcze w celu zmniejszenia anomalii.

Następujące anomalie mogą wystąpić bez odpowiednich miar:

• Utracone aktualizacje, gdy jedna saga zapisuje bez czytania zmian wprowadzonych przez inną sagę.
• Brudne odczyty, gdy transakcja lub saga odczytuje aktualizacje dokonane przez sagę, która nie ukończyła jeszcze tych aktualizacji.
• Odczyty rozmyte/niezwiązane, gdy różne kroki sagi odczytują różne dane, ponieważ aktualizacja danych występuje między odczytami.

Sugerowane środki zaradcze w celu zmniejszenia lub zapobiegania anomaliom obejmują:

• Blokada semantyczna, blokada na poziomie aplikacji, w której transakcja do wykonania sagi używa semafora, aby wskazać, że aktualizacja jest w toku.
• Aktualizacje zmutacyjne , które można wykonać w dowolnej kolejności i generują ten sam wynik.
• Pesymistyczny widok: Istnieje możliwość, aby jedna saga odczytywała brudne dane, podczas gdy inna saga uruchamia kompensowalne transakcje, aby wycofać operację. Pesymistyczny widok zmienia kolejność sagi tak, aby podstawowe aktualizacje danych w transakcji możliwe do ponawiania, co eliminuje możliwość brudnego odczytu.
• Wartość ponownego odczytania sprawdza, czy dane są niezmienione, a następnie aktualizuje rekord. Jeśli rekord uległ zmianie, kroki przerwania i saga może zostać uruchomiona ponownie.
• Plik wersji rejestruje operacje na rekordzie podczas ich nadejścia, a następnie wykonuje je w odpowiedniej kolejności.
• Wartość używa ryzyka biznesowego każdego żądania do dynamicznego wybierania mechanizmu współbieżności. Żądania o niskim ryzyku faworyzują sagi, podczas gdy żądania o wysokim ryzyku faworyzują transakcje rozproszone.

Kiedy używać tego wzorca

Użyj wzorca Saga, jeśli musisz:

• Zapewnij spójność danych w systemie rozproszonym bez ścisłego sprzęgania.
• Wycofaj lub zrekompensuj, jeśli jedna z operacji w sekwencji zakończy się niepowodzeniem.

Wzorzec saga jest mniej odpowiedni dla:

• Ściśle powiązane transakcje.
• Transakcje wyrównywujące, które występują we wcześniejszych uczestnikach.
• Cykliczne zależności.

Przykład

Saga oparta na orkiestracji na podstawie bezserwerowej to odwołanie do implementacji sagi przy użyciu podejścia orkiestracji, które symuluje scenariusz transferu pieniędzy z pomyślnymi i nieudanymi przepływami pracy.

Następne kroki

• Rozproszone dane
• Richardson, Chris. 2018: Wzorce mikrousług. Publikacje manning.

Powiązane zasoby

Podczas wdrażania tego wzorca przydatne mogą być następujące wzorce:

• Choreografia ma każdy składnik systemu uczestniczyć w procesie podejmowania decyzji o przepływie pracy transakcji biznesowej, zamiast polegać na centralnym punkcie kontroli.
• Transakcje kompensacyjne cofają pracę wykonywaną przez serię kroków i ostatecznie definiują spójną operację, jeśli co najmniej jeden krok zakończy się niepowodzeniem. Aplikacje hostowane w chmurze, które implementują złożone procesy biznesowe i przepływy pracy, często są zgodne z tym modelem spójności ostatecznej.
• Ponów próbę umożliwia aplikacji obsługę przejściowych błędów podczas próby nawiązania połączenia z zasobem usługi lub sieci przez przezroczyste ponawianie próby wykonania operacji, która zakończyła się niepowodzeniem. Ponawianie próby może poprawić stabilność aplikacji.
• Wyłącznik obsługuje błędy, które zajmują zmienną ilość czasu do odzyskania podczas nawiązywania połączenia z usługą zdalną lub zasobem. Wyłącznik może poprawić stabilność i odporność aplikacji.
• Monitorowanie punktu końcowego kondycji implementuje testy funkcjonalne w aplikacji, do których narzędzia zewnętrzne mogą uzyskiwać dostęp za pośrednictwem uwidocznionych punktów końcowych w regularnych odstępach czasu. Monitorowanie punktu końcowego kondycji może pomóc w sprawdzeniu, czy aplikacje i usługi działają prawidłowo.