Wzorzec transakcji kompensującej

Użyj tego wzorca, aby cofnąć działanie, gdy co najmniej jeden krok zakończy się niepowodzeniem w operacji ostatecznie spójnej. Aplikacje hostowane w chmurze, które implementują złożone procesy biznesowe i przepływy pracy, często używają operacji, które są zgodne z modelem spójności ostatecznej.

Kontekst i problem

Aplikacje w chmurze często modyfikują dane rozmieszczone w różnych źródłach danych w różnych lokalizacjach geograficznych. Aby uniknąć rywalizacji i zwiększyć wydajność w środowisku rozproszonym, aplikacje powinny implementować spójność ostateczną zamiast silnej spójności transakcyjnej. W przypadku modelu spójności ostatecznej typowa operacja biznesowa składa się z serii oddzielnych kroków. Podczas tych kroków ogólny widok stanu systemu może być niespójny. Jednak system powinien zostać ponownie spójny po zakończeniu wszystkich kroków.

Obsługa błędów kroków stanowi kluczowe wyzwanie w modelu spójności ostatecznej. Po niepowodzeniu może być konieczne cofnięcie efektów ukończonych kroków operacyjnych. Nie zawsze można jednak wycofać dane, ponieważ inne współbieżne wystąpienia aplikacji mogą zmieniać dane. Nawet jeśli wystąpienia współbieżne nie zmieniają danych, może to być bardziej złożone, aby cofnąć krok niż przywrócić oryginalny stan. Może być konieczne zastosowanie reguł specyficznych dla firmy. Przykład można znaleźć w przykładzie witryny internetowej podróży.

Gdy operacja implementująca spójność końcową obejmuje wiele magazynów danych, należy uzyskać dostęp do każdego z nich, aby cofnąć dokonane zmiany. Aby zapobiec zachowaniu niespójności systemu, należy niezawodnie cofnąć pracę w każdym magazynie danych.

Operacja, która implementuje spójność ostateczną, nie zawsze przechowuje dane, których dotyczy problem, w bazie danych. Na przykład w środowisku architektury zorientowanej na usługę (SOA) operacja może wywołać akcję w usłudze i zmienić stan przechowywany przez usługę. Aby cofnąć operację, należy również cofnąć tę zmianę stanu, co może obejmować ponowne wywołanie usługi w celu odwrócenia efektów pierwszej akcji.

Rozwiązanie

Zaimplementuj transakcję wyrównywczą, która cofa efekty wykonanych kroków w pierwotnej operacji. Można pomyśleć, że można po prostu przywrócić system do stanu pierwotnego, ale takie podejście może zastąpić zmiany z innych współbieżnych wystąpień aplikacji. Zamiast tego transakcja wyrównywająca musi inteligentnie uwzględniać współbieżną pracę. Ten proces jest zwykle specyficzny dla aplikacji i zależy od oryginalnej operacji.

Możesz użyć przepływu pracy, aby zaimplementować ostatecznie spójną operację, która wymaga odszkodowania. Podczas uruchamiania oryginalnej operacji system rejestruje informacje o każdym kroku i sposobie jego cofnięcia. Jeśli operacja zakończy się niepowodzeniem, przepływ pracy ponownie przechodzi przez ukończone kroki i odwraca każdy krok.

Diagram przedstawiający przepływ pracy z krokami do przodu i akcjami kompensacyjnymi. Użytkownik inicjuje operację, która uruchamia krok 1, krok 2 i krok 3 sekwencyjnie. Jeśli wszystkie kroki zakończą się pomyślnie, proces zostanie ukończony. Jeśli awaria wystąpi po dowolnym kroku, działania kompensacyjne są uruchamiane w odwrotnej kolejności, aby odwrócić zakończoną pracę, co kończy się w stanie skompensowanym.

Chociaż każdy krok jest oddzielną akcją, tworzą ostatecznie spójną operację. System musi przeprowadzić kroki oraz odpowiadające im operacje cofania dla każdego z nich. Jeśli klient anuluje, operacje cofania mogą zostać uruchomione jako transakcje kompensacyjne.

Awaria jednoetapowa nie zawsze wymaga wycofania całego systemu przy użyciu transakcji wyrównywczej. Na przykład w scenariuszu witryny podróży klient rezerwuje loty F1, F2 i F3, ale nie rezerwuje pokoju w hotelu H1. Preferowane jest zaoferowanie klientowi pokoju w innym hotelu niż anulowanie lotów. Klient nadal może zdecydować się na anulowanie, co wyzwala transakcję wyrównywczą w celu cofnięcia rezerwacji lotów. Jednak klient powinien podjąć tę decyzję, a nie system. Gdy decyzje mają duży wpływ lub są trudne do niezawodnego zautomatyzowania, uwzględnij człowieka w procesie podejmowania decyzji.

Rozważ następujące ważne kwestie:

• Transakcja wyrównawcza może nie wymagać dokonania cofnięcia pracy dokładnie w odwrotnej kolejności niż oryginalna operacja.

• Możesz wykonać kilka kroków cofania równolegle.

• Może być konieczne zastosowanie reguł specyficznych dla firmy. Na przykład anulowanie rezerwacji lotów może nie uprawniać klienta do całkowitego zwrotu kosztów.

Takie podejście jest podobne do wzorca transakcji rozproszonych Saga.

Transakcje kompensacyjne są docelowo spójne i mogą zakończyć się niepowodzeniem. System powinien rejestrować postęp, aby można było wznowić transakcję wyrównywczą z punktu awarii. Krok może być uruchamiany wielokrotnie przy ponownej próbie, dlatego każdy krok powinien być zaprojektowany jako polecenie idempotentne.

Czasami interwencja ręczna jest jedynym sposobem odzyskania po nieudanym kroku. W takich sytuacjach system powinien zgłosić alert zawierający szczegółowe informacje o przyczynie awarii.

Problemy i zagadnienia

Podczas podejmowania decyzji o zaimplementowaniu tego wzorca należy wziąć pod uwagę następujące kwestie:

• Ustalenie, kiedy krok operacji implementujący spójność ostateczną kończy się niepowodzeniem, może nie być łatwe. Krok może nie zakończyć się niepowodzeniem natychmiast, ale zamiast tego zostanie zablokowany. Może być konieczne zaimplementowanie mechanizmu przekroczenia limitu czasu.

• Nie jest łatwo uogólnić logikę kompensacji. Transakcja wyrównywająca jest specyficzna dla aplikacji. Opiera się on na aplikacji, która ma wystarczające informacje, aby cofnąć skutki każdego kroku w operacji, która zakończyła się niepowodzeniem.

• Transakcje wyrównywujące nie zawsze działają. Zdefiniuj kroki transakcji kompensującej jako polecenia idempotentne, aby można je było powtórzyć, jeśli transakcja kompensująca się nie powiodła.

• Infrastruktura, która obsługuje kroki, musi spełniać następujące kryteria:

  • Jest odporny zarówno w oryginalnej operacji, jak i w transakcji wyrównywjącej.

  • Nie traci informacji wymaganych do zrekompensowania nieudanego kroku.

  • Niezawodnie monitoruje postęp logiki kompensacji. Transakcje wyrównywujące są uruchamiane po zatwierdzeniu oryginalnych operacji, a inne transakcje mogą zmieniać stany pośrednie. W związku z tym upewnij się, że można skorelować i przeprowadzić inspekcję zarówno oryginalnej operacji, jak i jej kompleksowej rekompensaty.

• Transakcja wyrównywająca nie musi zwracać danych systemowych do stanu na początku oryginalnej operacji. Zamiast tego transakcja rekompensuje pracę, którą operacja zdołała zakończyć pomyślnie przed jej niepowodzeniem.

• Kroki transakcji kompensujące nie zawsze odwracają oryginalną operację w dokładnie odwrotnej kolejności działań. Jeśli na przykład jeden magazyn danych jest bardziej wrażliwy na niespójności niż inny, cofnij najpierw zmiany w tym magazynie.

• Niektóre miary mogą pomóc w zwiększeniu współczynników powodzenia. Możesz umieścić krótkoterminową blokadę z limitem czasu dla każdego zasobu wymaganego do ukończenia operacji. Te zasoby można uzyskać z wyprzedzeniem, a następnie wykonać pracę dopiero po uzyskaniu wszystkich zasobów. Finalizuj wszystkie akcje przed wygaśnięciem blokad.

• Logika ponawiania prób, która traktuje więcej błędów jako przejściowych, może pomóc zminimalizować błędy, które wyzwalają transakcję wyrównywalną. Gdy krok operacji implementujący spójność ostateczną kończy się niepowodzeniem, obsłuż go jako wyjątek przejściowy i ponów próbę wykonania kroku. Zatrzymaj operację i wyzwól kompensację tylko wtedy, gdy krok nieustannie ulega awarii lub nie można go odzyskać. Aby uzyskać więcej informacji na temat strategii ponawiania prób, zobacz Obsługa błędów przejściowych.

• Podczas implementowania transakcji wyrównywczej napotykasz wiele wyzwań podobnych do implementacji spójności ostatecznej. Aby uzyskać więcej informacji, zobacz Minimalizuj koordynację.

• Zdefiniuj jasne punkty bez zwrotu i nieodwracalne kroki. W złożonych przepływach pracy nie można bezpiecznie ani znacząco cofnąć niektórych operacji, takich jak zewnętrzne skutki uboczne lub prawnie wiążące działania. Zidentyfikuj kroki kompensowalne w porównaniu z nieodwracalnymi. Zaprojektuj przepływ pracy tak, aby kroki nieodwracalne wystąpiły dopiero po pomyślnym zakończeniu wszystkich krytycznych walidacji.

Kiedy należy używać tego wzorca

Użyj tego wzorca, gdy:

• Operacja biznesowa obejmuje wiele kroków, usług lub magazynów danych i musi zostać cofniętą w przypadku niepowodzenia późniejszego kroku. Taki scenariusz często występuje w długotrwałych procesach roboczych, które są zgodne z modelem spójności ostatecznej i nie mogą polegać na transakcjach atomowych.

• Odzyskiwanie po awarii często wymaga logiki specyficznej dla domeny, a nie prostego wycofywania danych. Korzystanie z działań kompensujących podczas wycofania działań wymaga zastosowania reguł biznesowych, takich jak anulowanie rezerwacji lub wystawianie częściowych zwrotów.

Ten wzorzec może nie być odpowiedni w następujących przypadkach:

• Operacje mogą być bezpiecznie ponawiane, a większość błędów jest przejściowych. Sama logika ponawiania prób jest często wystarczająca w tych przypadkach, a transakcje wyrównywujące dodają niepotrzebną złożoność.

• System nie może tolerować tymczasowej niespójności lub rekompensata nie może niezawodnie przywrócić prawidłowego stanu. Zamiast tego należy używać mechanizmów silnej spójności lub transakcji atomowych we wszystkich krokach.

Projektowanie obciążenia pracy

Oceń sposób użycia transakcji wyrównywającej w projekcie obciążenia w celu rozwiązania celów i zasad omówionych w filarach Azure Well-Architected Framework. Poniższa tabela zawiera wskazówki dotyczące tego, jak ten wzorzec obsługuje cele poszczególnych filarów.

Filar	Jak ten wzorzec obsługuje cele filaru
Decyzje projektowe dotyczące niezawodności pomagają obciążeniom stały się odporne na awarię i zapewniają, że zostanie ono przywrócone do w pełni funkcjonalnego stanu po wystąpieniu awarii.	Akcje kompensacji dotyczą awarii w krytycznych ścieżkach obciążenia przy użyciu procesów, takich jak bezpośrednie wycofywanie zmian danych, przerywanie blokad transakcji, a nawet uruchamianie natywnego zachowania systemu w celu odwrócenia efektu. - RE:02 Przepływy krytyczne - RE:09 Odzyskiwanie po awarii

Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.

Przykład

Na poniższym diagramie przedstawiono praktyczną implementację Azure wzorca transakcji wyrównujących. Inne implementacje mogą również spełniać wymagania dotyczące obciążenia. Orkiestrator działający w Azure Container Apps koordynuje każdy krok długotrwałego przepływu pracy, wysyłając polecenia za pośrednictwem Azure Service Bus. Gdy każdy krok do przodu się powiedzie, orkiestrator rejestruje zarówno stan wykonania, jak i odpowiednie działanie kompensacyjne w Azure Cosmos DB, aby przepływ pracy mógł być wznowiony, skorelowany i poddany audytowi.

Diagram przedstawiający przepływ pracy w środowisku Azure Container Apps. Klient wysyła żądanie do kontenera orkiestratora, który koordynuje działanie usługi A i usługi B oraz rejestruje operacje. Komunikaty kroku 1 i kroku 2 przepływają przez Service Bus. Jeśli krok zakończy się niepowodzeniem, akcje wyrównywujące są uruchamiane w odwrotnej kolejności. Komunikaty, które zakończyły się niepowodzeniem, przechodzą do kolejki martwych listów. Środowisko integruje się z Microsoft Entra ID w celu zarządzania tożsamością oraz z usługami Application Insights i Azure Monitor w zakresie obserwowalności.

Ten model najpierw używa ponownych prób, aby zachować postęp naprzód. Jeśli krok zakończy się niepowodzeniem, koordynator stosuje logikę ponawiania prób dla błędów przejściowych i próbuje kontynuować oryginalną operację. Kompensacja jest wywoływana tylko wtedy, gdy postęp staje się niemożliwy, na przykład w przypadku wyczerpania ponownych prób lub gdy awaria jest klasyfikowana jako nietrwała.

Zasady specyficzne dla działalności mogą również preferować postępy zamiast natychmiastowego odszkodowania. Jeśli krok zakończy się niepowodzeniem, koordynator może wybrać alternatywną ścieżkę, taką jak zastąpienie równoważnej usługi lub opcji rezerwowej, zamiast wycofywania przepływu pracy. W przypadku przypadków o dużym wpływie lub niejednoznacznym można wstrzymać przepływ pracy dla przeglądu przez człowieka przed podjęciem decyzji o kontynuowaniu alternatywnej ścieżki lub wyzwalania rekompensaty. To podejście traktuje rekompensatę jako ostateczność i pozwala regułom domeny kierować decyzjami dotyczącymi odzyskiwania.

W typowej kolejności orkiestrator wysyła komunikaty dotyczące etapów przez Service Bus (kroki 1 i 2), otrzymuje pomyślne wyniki i przechowuje metadane dotyczące przekazywania i kompensacji w Azure Cosmos DB.

Kompensację można wyzwolić na dwa sposoby:

• Jeśli późniejszy krok w tym samym obciążeniu zakończy się niepowodzeniem i musisz cofnąć wcześniej pomyślne kroki. Ta kompensacja może nastąpić natychmiast, gdy krok zwróci błąd biznesowy, taki jak niepowodzenie weryfikacji reguły, lub po wyczerpaniu prób technicznych, a komunikat zostanie przeniesiony do kolejki martwych listów.

• Gdy kolejny klient jawnie zażąda anulowania ukończonej operacji.

W obu przypadkach orkiestrator odczytuje przechowywane rekordy kompensacji i wysyła polecenia kompensacji do odpowiedniej usługi. Jeśli krok rekompensaty zakończy się przejściowym niepowodzeniem, próby ponownego podjęcia przez Service Bus mogą je zakończyć bez eskalacji problemu.

Jeśli powtarzające się próby nadal kończą się niepowodzeniem, Service Bus przenosi komunikat do kolejki utraconych komunikatów i zachowuje szczegóły niepowodzenia. Orkiestrator lub dedykowany procesor wiadomości nieudanych zgłasza alert i emituje ustrukturyzowane dane telemetryczne, w tym przyczynę awarii i identyfikatory korelacji, do Azure Monitor i Log Analytics, które mogą być widoczne w usłudze Application Insights. Ta ścieżka operacyjna pomaga zespołom diagnozować błędy, określać potrzebę ręcznej interwencji i zachować możliwość śledzenia zarówno w przepływach pierwotnych, jak i wyrównywujących.

Przepływ pracy może automatycznie uruchomić rekompensatę dla jasnych, niskiego ryzyka warunków lub zatrzymać się na przegląd przez człowieka, gdy sytuacja jest niejednoznaczna, ma duży wpływ lub wymaga ręcznej decyzji.

Użyj tożsamości zarządzanych i autoryzacji opartej na Microsoft Entra ID między składnikami, aby uniknąć wspólnych sekretów i wymusić dostęp z minimalnymi uprawnieniami. Podczas tworzenia uproszczonego diagramu referencyjnego należy traktować te kontrolki tożsamości i autoryzacji jako podstawowe kwestie implementacji, a nie jawne kroki przepływu. Zachowaj diagram skoncentrowany na orkiestracji, ponawianiu prób, kompensacji i obsłudze awarii.

Powiązane zasoby

• Zagadnienia dotyczące danych dla mikrousług: dowiedz się, dlaczego spójność ostateczna i częściowa awaria są związane z systemami rozproszonymi. Wzorzec transakcji wyrównywczej zapewnia konkretny mechanizm obsługi tych błędów, gdy operacje obejmują wiele usług.

• wzorzec Transactional Outbox z Azure Cosmos DB: Użyj tego wzorca, gdy transakcje wyrównujące muszą niezawodnie publikować zdarzenia lub polecenia. Dzięki temu można zagwarantować, że zmiany stanu i wiadomości są rejestrowane atomowo, co zapobiega utracie wiadomości.

• Projektowanie pod kątem samonaprawiania: użyj transakcji wyrównywujących w ramach podejścia samonaprawiania dla aplikacji.

• Wzorzec nadzorcy agenta harmonogramu: ten wzorzec służy do implementowania odpornych systemów wykonujących operacje biznesowe w usługach i zasobach rozproszonych. Te systemy czasami wymagają transakcji kompensacyjnych, aby cofnąć wykonane czynności.

• Wzorzec ponawiania: ten wzorzec służy do obsługi błędów przejściowych i minimalizowania potrzeby transakcji wyrównywalnych.

• Wzorzec transakcji rozproszonych saga: ten wzorzec służy do zarządzania spójnością danych między mikrousługami w transakcjach rozproszonych. Saga używa transakcji kompensacyjnych na potrzeby odzyskiwania po awarii.

• Wzorzec potoków i filtrów: użyj tego wzorca z wzorcem transakcji wyrównywalnych jako alternatywy dla transakcji rozproszonych podczas rozpadu złożonych zadań na możliwe do ponownego użycia kroki.