Wzorzec rozproszonych transakcji Saga

Azure

Zachowaj spójność danych w systemach rozproszonych, koordynując sekwencję transakcji lokalnych w wielu usługach. Każda usługa wykonuje operację i wyzwala następny krok za pośrednictwem zdarzeń lub komunikatów. Jeśli krok zakończy się niepowodzeniem, szereg transakcji wyrównywujących cofa zmiany, które zostały wykonane.

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 obejmuje 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).

• Atomowość: Wszystkie operacje kończą się powodzeniem albo żadna operacja nie kończy się powodzeniem.
• 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 zapewnienie zgodności z ACID w wielu usługach jednocześnie może być bardziej złożone.

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:

1. Wykonuje swoje zadanie atomowo w ramach jednej usługi.
2. Aktualizuje bazę danych usługi.
3. Inicjuje następną transakcję za pośrednictwem zdarzenia lub komunikatu.

Jeśli transakcja lokalna zakończy się niepowodzeniem, saga wykonuje serię transakcji kompensacyjnych, aby odwrócić zmiany wprowadzone przez poprzedzające ją transakcje lokalne.

Kluczowe pojęcia w wzorcu Saga

• Kompensowalne transakcje można cofnąć lub zrekompensować przez inne transakcje z odwrotnym skutkiem. Jeśli krok w sadze zakończy się niepowodzeniem, transakcje kompensujące cofają zmiany wprowadzone przez transakcje kompensowalne.

• Transakcje pivotowe służą jako punkt bez powrotu w sadze. Po pomyślnym zakończeniu transakcji centralnej transakcje kompensacyjne nie są już istotne. Aby system osiągnął spójny stan końcowy, należy wykonać wszystkie kolejne akcje. Transakcja pivotowa może przyjmować różne role w zależności od przebiegu sagi:

  • Nieodwracalne lub niepodlegające kompensacie transakcje nie mogą zostać cofnięte ani ponowione.

  • Granica między odwracalnością a zatwierdzeniem oznacza, że transakcja graniczna może być ostatnią transakcją, którą można wycofać, lub transakcją podlegającą kompensacji. Albo może to być pierwsza operacja, którą można ponowić w sadze.

• Transakcje ponawialne następują po transakcji pivotowej. Transakcje z możliwością ponawiania są idempotentne i pomagają zagwarantować, że saga może osiągnąć stan końcowy, nawet jeśli wystąpią tymczasowe błędy. Pomagają sadze ostatecznie osiągnąć stan spójności.

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.	Po dodaniu nowych kroków przepływ pracy może stać się niejasny. 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ą nawzajem przetwarzać swoje polecenia.
Nie wprowadza pojedynczego punktu awarii, ponieważ obowiązki są rozdzielone pomiędzy uczestników sagi.	Testowanie integracji jest trudne, ponieważ wszystkie usługi muszą być uruchamiane w celu symulowania transakcji.

Orkiestracja

W przypadku orkiestracji scentralizowany kontroler, czyli orkiestrator, obsługuje wszystkie transakcje i informuje uczestników, jaką operację mają wykonać na podstawie zdarzeń. Orkiestrator wykonuje żądania w ramach sagi, przechowuje i interpretuje stan każdego zadania oraz obsługuje przywracanie po awarii za pomocą transakcji kompensacyjnych.

Zalety orkiestracji	Wady orkiestracji
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:

• Zmiana w podejściu do projektowania: 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 sag może być złożone, zwłaszcza gdy rośnie liczba 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 Idempotentne przetwarzanie komunikatów.

• Konieczność monitorowania i śledzenia sag: Monitorowanie i śledzenie przepływu pracy sagi są niezbędne do 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ą sagę, ale modyfikacja nie została jeszcze zakończona.

• Rozmyte lub niepowtarzalne odczyty: Gdy różne kroki sagi odczytują niespójne dane, ponieważ aktualizacje zachodzą między kolejnymi odczytami.

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 kompensowalna sagi używa semafora do wskazania, że trwa aktualizacja.

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

• Pesymistyczne podejście: Zmień kolejność kroków sagi, aby aktualizacje danych odbywały się w transakcjach, które można ponawiać, w celu wyeliminowania brudnych odczytów. W przeciwnym razie jedna saga może odczytywać brudne dane lub niezatwierdzone zmiany, podczas gdy inna saga jednocześnie wykonuje transakcję kompensowalną, aby wycofać wprowadzone przez nią zmiany.

• 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: Prowadzić rejestr wszystkich operacji wykonywanych na rekordzie i upewnić się, że są one wykonywane we właściwej kolejności, aby zapobiec konfliktom.

• Współbieżność oparta na wartości i ryzyku: Dynamicznie dobieraj odpowiedni mechanizm współbieżności na podstawie potencjalnego ryzyka biznesowego. Na przykład używaj sag w przypadku aktualizacji o niskim ryzyku, a transakcji rozproszonych — w przypadku aktualizacji o wysokim ryzyku.

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ć zmiany lub je skompensować, 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 kompensacyjne występują u wcześniejszych uczestników.
• Istnieją cykliczne zależności.

Następny krok

• wzorce danych natywnych dla chmury

Powiązane zasoby

Podczas implementowania tego wzorca mogą być istotne następujące wzorce:

• Wzorzec choreografii zakłada, że każdy element systemu uczestniczy w procesie podejmowania decyzji dotyczących przebiegu transakcji biznesowej, zamiast opierać się na centralnym punkcie sterowania.

• 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 obwodu obsługuje awarie, po których odzyskanie sprawności może zająć różną ilość czasu, podczas nawiązywania połączenia ze zdalną usługą lub zasobem. Ten wzorzec może poprawić stabilność i odporność aplikacji.

• Wzorzec monitorowania punktu końcowego kondycji wdraża kontrole funkcjonalne w aplikacji, do których narzędzia zewnętrzne mogą uzyskiwać dostęp za pośrednictwem udostępnionych 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.

Zachowaj spójność danych w systemach rozproszonych, koordynując sekwencję transakcji lokalnych w wielu usługach. Każda usługa wykonuje operację i wyzwala następny krok za pośrednictwem zdarzeń lub komunikatów. Jeśli krok zakończy się niepowodzeniem, szereg transakcji wyrównywujących cofa zmiany, które zostały wykonane.

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 obejmuje 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).

• Atomowość: Wszystkie operacje kończą się powodzeniem albo żadna operacja nie kończy się powodzeniem.
• 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 zapewnienie zgodności z ACID w wielu usługach jednocześnie może być bardziej złożone.

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:

1. Wykonuje swoje zadanie atomowo w ramach jednej usługi.
2. Aktualizuje bazę danych usługi.
3. Inicjuje następną transakcję za pośrednictwem zdarzenia lub komunikatu.

Jeśli transakcja lokalna zakończy się niepowodzeniem, saga wykonuje serię transakcji kompensacyjnych, aby odwrócić zmiany wprowadzone przez poprzedzające ją transakcje lokalne.

Kluczowe pojęcia w wzorcu Saga

• Kompensowalne transakcje można cofnąć lub zrekompensować przez inne transakcje z odwrotnym skutkiem. Jeśli krok w sadze zakończy się niepowodzeniem, transakcje kompensujące cofają zmiany wprowadzone przez transakcje kompensowalne.

• Transakcje pivotowe służą jako punkt bez powrotu w sadze. Po pomyślnym zakończeniu transakcji centralnej transakcje kompensacyjne nie są już istotne. Aby system osiągnął spójny stan końcowy, należy wykonać wszystkie kolejne akcje. Transakcja pivotowa może przyjmować różne role w zależności od przebiegu sagi:

  • Nieodwracalne lub niepodlegające kompensacie transakcje nie mogą zostać cofnięte ani ponowione.

  • Granica między odwracalnością a zatwierdzeniem oznacza, że transakcja graniczna może być ostatnią transakcją, którą można wycofać, lub transakcją podlegającą kompensacji. Albo może to być pierwsza operacja, którą można ponowić w sadze.

• Transakcje ponawialne następują po transakcji pivotowej. Transakcje z możliwością ponawiania są idempotentne i pomagają zagwarantować, że saga może osiągnąć stan końcowy, nawet jeśli wystąpią tymczasowe błędy. Pomagają sadze ostatecznie osiągnąć stan spójności.

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.	Po dodaniu nowych kroków przepływ pracy może stać się niejasny. 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ą nawzajem przetwarzać swoje polecenia.
Nie wprowadza pojedynczego punktu awarii, ponieważ obowiązki są rozdzielone pomiędzy uczestników sagi.	Testowanie integracji jest trudne, ponieważ wszystkie usługi muszą być uruchamiane w celu symulowania transakcji.

Orkiestracja

W przypadku orkiestracji scentralizowany kontroler, czyli orkiestrator, obsługuje wszystkie transakcje i informuje uczestników, jaką operację mają wykonać na podstawie zdarzeń. Orkiestrator wykonuje żądania w ramach sagi, przechowuje i interpretuje stan każdego zadania oraz obsługuje przywracanie po awarii za pomocą transakcji kompensacyjnych.

Zalety orkiestracji	Wady orkiestracji
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:

• Zmiana w podejściu do projektowania: 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 sag może być złożone, zwłaszcza gdy rośnie liczba 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 Idempotentne przetwarzanie komunikatów.

• Konieczność monitorowania i śledzenia sag: Monitorowanie i śledzenie przepływu pracy sagi są niezbędne do 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ą sagę, ale modyfikacja nie została jeszcze zakończona.

• Rozmyte lub niepowtarzalne odczyty: Gdy różne kroki sagi odczytują niespójne dane, ponieważ aktualizacje zachodzą między kolejnymi odczytami.

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 kompensowalna sagi używa semafora do wskazania, że trwa aktualizacja.

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

• Pesymistyczne podejście: Zmień kolejność kroków sagi, aby aktualizacje danych odbywały się w transakcjach, które można ponawiać, w celu wyeliminowania brudnych odczytów. W przeciwnym razie jedna saga może odczytywać brudne dane lub niezatwierdzone zmiany, podczas gdy inna saga jednocześnie wykonuje transakcję kompensowalną, aby wycofać wprowadzone przez nią zmiany.

• 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: Prowadzić rejestr wszystkich operacji wykonywanych na rekordzie i upewnić się, że są one wykonywane we właściwej kolejności, aby zapobiec konfliktom.

• Współbieżność oparta na wartości i ryzyku: Dynamicznie dobieraj odpowiedni mechanizm współbieżności na podstawie potencjalnego ryzyka biznesowego. Na przykład używaj sag w przypadku aktualizacji o niskim ryzyku, a transakcji rozproszonych — w przypadku aktualizacji o wysokim ryzyku.

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ć zmiany lub je skompensować, 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 kompensacyjne występują u wcześniejszych uczestników.
• Istnieją cykliczne zależności.

Następny krok

• wzorce danych natywnych dla chmury

Powiązane zasoby

Podczas implementowania tego wzorca mogą być istotne następujące wzorce:

• Wzorzec choreografii zakłada, że każdy element systemu uczestniczy w procesie podejmowania decyzji dotyczących przebiegu transakcji biznesowej, zamiast opierać się na centralnym punkcie sterowania.

• 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 obwodu obsługuje awarie, po których odzyskanie sprawności może zająć różną ilość czasu, podczas nawiązywania połączenia ze zdalną usługą lub zasobem. Ten wzorzec może poprawić stabilność i odporność aplikacji.

• Wzorzec monitorowania punktu końcowego kondycji wdraża kontrole funkcjonalne w aplikacji, do których narzędzia zewnętrzne mogą uzyskiwać dostęp za pośrednictwem udostępnionych 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.