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 pojedynczą 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ług:

• Niepodzielność jest niepodzielnym i niepodzielnym zestawem operacji, które muszą wystąpić lub nie wystąpią żadne.
• Spójność oznacza, że transakcja przenosi dane tylko z jednego prawidłowego stanu do innego prawidłowego stanu.
• Izolacja gwarantuje, że równoczesne transakcje generują ten sam stan danych, który sekwencyjnie wykonane transakcje zostałyby wygenerowane.
• Trwałość zapewnia, ż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 pozwala każdej usłudze używać najlepszego typu i schematu magazynu danych, skalować własny magazyn danych w razie potrzeby i odizolować się od awarii 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, zanim transakcja będzie mogła kontynuować. Jednak niektóre implementacje uczestników, takie jak bazy danych NoSQL i brokering komunikatów, nie obsługują tego modelu.

Innym ograniczeniem transakcji rozproszonych jest synchronizacja i dostępność komunikacji międzyprocesowej (IPC ). Zapewniany przez system operacyjny protokół IPC umożliwia oddzielnym procesom udostępnianie 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 nie powiedzie się, saga wykonuje serię transakcji kompensacyjnych, które cofnęły zmiany wprowadzone przez poprzednie transakcje lokalne.

W wzorcach Saga:

• Kompensowalne transakcje to transakcje , które mogą być potencjalnie odwrócone, przetwarzając inną transakcję z odwrotnym skutkiem.
• 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 compensable, ani ponawiana, albo może to być ostatnia transakcja z możliwością compensable lub pierwsza ponowna transakcja w sagi.
• Transakcje z możliwością ponawiania prób to transakcje , które są zgodne z transakcją przestawną i mają gwarancję pomyślnego działania.

Istnieją dwa typowe podejścia implementacji sagi, choreografia i orkiestracja. 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. Dzięki choreografii każda lokalna transakcja publikuje zdarzenia domeny, które wyzwalają transakcje lokalne w innych usługach.

Świadczenia

• Dobre 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ą rozdzielane między uczestników sagi.

Wady

• Przepływ pracy może stać się mylący podczas dodawania nowych kroków, ponieważ trudno jest śledzić, których poleceń słuchają uczestnicy sagi.
• 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, aby symulować transakcję.

Aranżacja

Orkiestracja to sposób koordynowania sag, w których scentralizowany kontroler informuje uczestników sagi o tym, jakie transakcje lokalne mają być wykonywane. Orkiestrator saga obsługuje wszystkie transakcje i informuje uczestników, którzy operację wykonać na podstawie zdarzeń. Orkiestrator wykonuje żądania saga, przechowuje i interpretuje stany każdego zadania oraz obsługuje odzyskiwanie po awarii przy użyciu transakcji wyrównywalnych.

Świadczenia

• Dobre dla złożonych przepływów pracy obejmujących wielu uczestników lub nowych uczestników dodanych w miarę upływu czasu.
• Odpowiednie, gdy istnieje kontrola nad każdym uczestnikiem procesu i kontrolę 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.
• Istnieje dodatkowy punkt awarii, ponieważ koordynator zarządza pełnym 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 awarii 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ść obserwowania w celu monitorowania i śledzenia przepływu pracy saga.
• Brak izolacji danych uczestnika nakłada wyzwania związane z trwałością. Implementacja saga musi obejmować środki zaradcze w celu zmniejszenia anomalii.
• Transakcje wyrównywujące nie zawsze działają.

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

• Utracone aktualizacje, gdy jedna saga zapisuje bez odczytywania 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/niezrepeatable, gdy różne kroki saga odczytują różne dane, ponieważ między odczytami następuje aktualizacja danych.

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.
• Dojeżdżające aktualizacje , 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żliwej do ponawiania, co eliminuje możliwość brudnego odczytu.
• Wartość odczytu sprawdza, czy dane nie uległy zmianie, a następnie aktualizują rekord. Jeśli rekord uległ zmianie, kroki przerwania i saga może zostać uruchomiona ponownie.
• Plik wersji rejestruje operacje na rekordzie w miarę 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 wysokiego ryzyka 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ężenia.
• Wycofaj lub zrekompensuj, jeśli jedna z operacji w sekwencji zakończy się niepowodzeniem.

Deseń Saga jest mniej odpowiedni dla:

• Ściśle powiązane transakcje.
• Transakcje wyrównywujące, które występują we wcześniejszych uczestników.
• Zależności cykliczne.

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 na temat przepływu pracy transakcji biznesowej, zamiast polegać na centralnym punkcie kontroli.
• Transakcje wyrównywały 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 korzystają z tego modelu spójności ostatecznej.
• Ponawianie umożliwia aplikacji obsługę przejściowych błędów podczas próby nawiązania połączenia z usługą lub zasobem sieciowym 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 na odzyskanie sprawności 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.