Wzorzec projektowy Saga pomaga zachować spójność danych w systemach rozproszonych, koordynując transakcje w wielu usługach. Saga to sekwencja transakcji lokalnych, w których każda usługa wykonuje operację i inicjuje następny krok za pośrednictwem zdarzeń lub komunikatów. Jeśli krok w sekwencji zakończy się niepowodzeniem, saga wykonuje transakcje wyrównywujące, aby cofnąć ukończone kroki. Takie podejście pomaga zachować spójność danych.
Kontekst i problem
Transakcja reprezentuje jednostkę pracy, która może obejmować wiele operacji. W ramach transakcji zdarzenie odnosi się do zmiany stanu, która ma wpływ na jednostkę. Polecenie hermetyzuje wszystkie informacje potrzebne do wykonania akcji lub wyzwolenia kolejnego zdarzenia.
Transakcje muszą być zgodne z zasadami niepodzielności, spójności, izolacji i trwałości (ACID).
- Niepodzielność: Wszystkie operacje kończą się powodzeniem lub nie powiodły się żadne operacje.
- Spójność: Dane przechodzą z jednego prawidłowego stanu do innego prawidłowego stanu.
- Izolacja: Transakcje współbieżne dają te same wyniki co transakcje sekwencyjne.
- trwałość: zmiany są utrwalane po ich zatwierdzeniu, nawet w przypadku wystąpienia awarii.
W jednej usłudze transakcje są zgodne z zasadami ACID, ponieważ działają w ramach pojedynczej bazy danych. Jednak bardziej złożone może być osiągnięcie zgodności ACID w wielu usługach.
Wyzwania związane z architekturami mikrousług
Architektury mikrousług zwykle przypisują dedykowaną bazę danych do każdej mikrousługi. Takie podejście zapewnia kilka korzyści:
- Każda usługa hermetyzuje własne dane.
- Każda usługa może używać najbardziej odpowiedniej technologii bazy danych i schematu dla określonych potrzeb.
- Bazy danych dla każdej usługi można skalować niezależnie.
- Błędy w jednej usłudze są odizolowane od innych usług.
Pomimo tych zalet ta architektura komplikuje spójność danych między usługami. Tradycyjne gwarancje bazy danych, takie jak ACID, nie mają bezpośredniego zastosowania do wielu niezależnych zarządzanych magazynów danych. Ze względu na te ograniczenia architektury, które opierają się na komunikacji międzyprocesowej lub tradycyjnych modelach transakcji, takich jak protokół zatwierdzania dwufazowego, są często lepiej dostosowane do wzorca Saga.
Rozwiązanie
Wzorzec Saga zarządza transakcjami, dzieląc je na sekwencję transakcji lokalnych .
Każda transakcja lokalna:
- Wykonuje swoją pracę niepodzielnie w ramach jednej usługi.
- Aktualizuje bazę danych usługi.
- Inicjuje następną transakcję za pośrednictwem zdarzenia lub komunikatu.
Jeśli transakcja lokalna zakończy się niepowodzeniem, saga wykonuje serię transakcji wyrównywujących , aby odwrócić zmiany wprowadzone w poprzednich transakcjach lokalnych.
Kluczowe pojęcia w wzorcu Saga
Kompensowalne transakcje można cofnąć lub zrekompensować przez inne transakcje z odwrotnym skutkiem. Jeśli krok w sagi zakończy się niepowodzeniem, transakcje wyrównywalne cofają zmiany, które dokonały współzadowolenia transakcji.
transakcji przestawnych służyć jako punkt braku zwrotu w sagi. Po pomyślnym zakończeniu transakcji przestawnej transakcje nie są już istotne. Aby system osiągnął spójny stan końcowy, należy wykonać wszystkie kolejne akcje. Transakcja przestawna może przyjąć różne role w zależności od przepływu sagi:
nieodwracalne lub niekompensowalne transakcje, nie można cofnąć ani ponowić próby.
Granica między odwracalnym i zatwierdzonym oznacza, że transakcja przestawna może być ostatnią cofniętą transakcją lub kompensalną. Może to być pierwsza operacja, która można ponowić próbę w sagi.
transakcji z możliwością ponawiania próby wykonaj transakcję przestawną. Transakcje możliwe do ponawiania są idempotentne i pomagają zapewnić, że saga może osiągnąć swój stan końcowy, nawet jeśli wystąpią tymczasowe awarie. Pomagają sagi w końcu osiągnąć spójny stan.
Podejścia implementacji saga
Dwa typowe podejścia implementacji sagi to choreografia i orkiestracja . Każde podejście ma własny zestaw wyzwań i technologii do koordynowania przepływu pracy.
Choreografia
W podejściu choreografii usługi wymieniają zdarzenia bez scentralizowanego kontrolera. Dzięki choreografii każda lokalna transakcja publikuje zdarzenia domeny, które wyzwalają transakcje lokalne w innych usługach.
| Zalety choreografii | Wady choreografii |
|---|---|
| Dobre dla prostych przepływów pracy, które mają kilka usług i nie potrzebują logiki koordynacji. | Przepływ pracy może być mylący podczas dodawania nowych kroków. Trudno jest śledzić, na które polecenia odpowiada każdy uczestnik sagi. |
| Żadna inna usługa nie jest wymagana do koordynacji. | Istnieje ryzyko cyklicznej zależności między uczestnikami sagi, ponieważ muszą korzystać ze sobą poleceń. |
| Nie wprowadza jednego punktu awarii, ponieważ obowiązki są dystrybuowane między uczestników sagi. | Testowanie integracji jest trudne, ponieważ wszystkie usługi muszą być uruchamiane w celu symulowania transakcji. |
Aranżacji
W orkiestracji scentralizowany kontroler lub orkiestratorobsługuje wszystkie transakcje i informuje uczestników, którzy operację wykonać na podstawie zdarzeń. Orkiestrator wykonuje żądania sagi, przechowuje i interpretuje stany każdego zadania oraz obsługuje odzyskiwanie po awarii przy użyciu transakcji wyrównywalnych.
| Zalety orkiestracji | Wady aranżacji |
|---|---|
| Lepiej nadaje się do złożonych przepływów pracy lub podczas dodawania nowych usług. | Inna złożoność projektowania wymaga implementacji logiki koordynacji. |
| Unika cyklicznych zależności, ponieważ orkiestrator zarządza przepływem. | Wprowadza punkt awarii, ponieważ koordynator zarządza pełnym przepływem pracy. |
| Jasne rozdzielenie obowiązków upraszcza logikę usługi. |
Problemy i zagadnienia
Podczas podejmowania decyzji o zaimplementowaniu tego wzorca należy wziąć pod uwagę następujące kwestie:
Shift w myśleniu projektowym: Przyjęcie wzorca Saga wymaga innego podejścia. Wymaga ona skupienia się na koordynacji transakcji i spójności danych w wielu mikrousługach.
Złożoność debugowania sag: Debugowanie sagi mogą być złożone, szczególnie w miarę wzrostu liczby uczestniczących usług.
nieodwracalne zmiany lokalnej bazy danych: Nie można wycofać danych, ponieważ uczestnicy sagi zatwierdzają zmiany w odpowiednich bazach danych.
Obsługa przejściowych błędów i idempotencji: System musi efektywnie obsługiwać błędy przejściowe i zapewnić idempotencję, gdy powtarzanie tej samej operacji nie zmienia wyniku. Aby uzyskać więcej informacji, zobacz idempotentnego przetwarzania komunikatów.
Potrzeba monitorowania i śledzenia sag: Monitorowanie i śledzenie przepływu pracy sagi są podstawowymi zadaniami utrzymania nadzoru operacyjnego.
ograniczenia transakcji wyrównywczych: transakcje wyrównywujące mogą nie zawsze zakończyć się powodzeniem, co może pozostawić system w stanie niespójnym.
Potencjalne anomalie danych w sagach
Anomalie danych to niespójności, które mogą wystąpić, gdy sagi działają w wielu usługach. Ponieważ każda usługa zarządza własnymi danymi, nazywanymi danych uczestnika, nie ma wbudowanej izolacji między usługami. Ta konfiguracja może spowodować niespójności danych lub problemy z trwałością, takie jak częściowo zastosowane aktualizacje lub konflikty między usługami. Typowe problemy obejmują:
Utracone aktualizacje: Gdy jedna saga modyfikuje dane bez uwzględnienia zmian wprowadzonych przez inną sagę, powoduje zastąpienie lub brak aktualizacji.
Brudne odczyty: Gdy saga lub transakcja odczytuje dane zmodyfikowane przez inną saga, ale modyfikacja nie jest kompletna.
rozmyte lub niezwiązane, odczytuje: Gdy różne kroki sagi odczytują niespójne dane, ponieważ aktualizacje występują między operacjami odczytu.
Strategie rozwiązywania anomalii danych
Aby zmniejszyć lub zapobiec tym anomaliom, rozważ następujące środki zaradcze:
blokada semantyczna: Użyj blokad na poziomie aplikacji, gdy transakcja do wykonania sagi używa semafora, aby wskazać, że aktualizacja jest w toku.
aktualizacje zmutacyjne: aktualizacje projektu, aby można je było stosować w dowolnej kolejności, jednocześnie generując ten sam wynik. Takie podejście pomaga zmniejszyć konflikty między sagami.
pesymistyczny widok: zmień kolejność sekwencji sagi, aby aktualizacje danych występowały w transakcjach z możliwością ponawiania prób w celu wyeliminowania zanieczyszczonych operacji odczytu. W przeciwnym razie jedna saga może odczytywać brudne dane lub niezatwierdzonych zmian, podczas gdy inna saga jednocześnie wykonuje transakcję do współkompensowania, aby wycofać aktualizacje.
Ponowne odczytywanie wartości: Upewnij się, że dane pozostają niezmienione przed wprowadzeniem aktualizacji. Jeśli dane się zmienią, zatrzymaj bieżący krok i uruchom ponownie sagę zgodnie z potrzebami.
pliki wersji: zachować dziennik wszystkich operacji wykonywanych na rekordzie i upewnić się, że są wykonywane w odpowiedniej kolejności, aby zapobiec konfliktom.
współbieżność oparta na ryzyku na podstawie wartości: Dynamicznie wybiera odpowiedni mechanizm współbieżności na podstawie potencjalnego ryzyka biznesowego. Na przykład używaj sag do aktualizacji o niskim ryzyku i transakcji rozproszonych w przypadku aktualizacji wysokiego ryzyka.
Kiedy należy używać tego wzorca
Użyj tego wzorca, gdy:
- Należy zapewnić spójność danych w systemie rozproszonym bez ścisłego sprzęgania.
- Należy wycofać lub zrekompensować, jeśli jedna z operacji w sekwencji zakończy się niepowodzeniem.
Ten wzorzec może nie być odpowiedni w następujących przypadkach:
- Transakcje są ściśle powiązane.
- Transakcje wyrównywujące występują we wcześniejszych uczestników.
- Istnieją cykliczne zależności.
Następny krok
Powiązane zasoby
Podczas implementowania tego wzorca mogą być istotne następujące wzorce:
Wzorzec choreografii ma każdy składnik systemu uczestniczyć w procesie podejmowania decyzji na temat przepływu pracy transakcji biznesowej, zamiast polegać na centralnym punkcie kontroli.
Wzorzec transakcji wyrównywczej cofa pracę wykonywaną przez serię kroków i ostatecznie definiuje 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.
Wzorzec ponawiania 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. Ten wzorzec może poprawić stabilność aplikacji.
Wzorzec wyłącznika obsługuje błędy, które zajmują zmienną ilość czasu na odzyskanie sprawności po nawiązaniu połączenia z usługą zdalną lub zasobem. Ten wzorzec może poprawić stabilność i odporność aplikacji.
Wzorzec monitorowania punktu końcowego kondycji implementuje kontrole 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. Ten wzorzec może pomóc w sprawdzeniu, czy aplikacje i usługi działają prawidłowo.