Jak wzorzec Saga koordynuje odwracalne działania domowej sztucznej inteligencji?

Saga koordynuje odwracalne działania domowej sztucznej inteligencji, dzieląc jeden przepływ pracy na uporządkowane kroki i uruchamiając działania kompensacyjne, gdy późniejszy krok zakończy się niepowodzeniem.

Jest to przydatne, gdy agent korzysta z kilku niezależnych usług, które nie mogą współdzielić jednej transakcji. Przepływ pracy rejestruje postęp, wykrywa punkt awarii i celowo wycofuje kroki, które można odwrócić.

Saga dzieli jedno działanie domowe na kilka lokalnych kroków

Saga koordynuje przepływ pracy obejmujący niezależne systemy, traktując każdy krok jako lokalną transakcję lub efekt uboczny. Cała operacja kończy się powodzeniem dopiero po wykonaniu wymaganych kroków.

Wzorzec Saga jest definiowany jako sekwencja lokalnych transakcji koordynowanych za pomocą komunikatów lub orkiestracji. Jest przydatny, gdy jedna globalna transakcja ACID nie może objąć wszystkich uczestników. Wzorzec Saga rozkłada większą transakcję na sekwencję lokalnych transakcji, co dobrze pasuje do wieloetapowych działań domowych opisanych w przeglądzie wzorca Saga.

Domowy przepływ pracy oparty na sztucznej inteligencji może zatrzymać usługę multimedialną, przenieść bibliotekę, zaktualizować punkt montowania, odświeżyć metadane i ponownie uruchomić usługę.

Każdy komponent zatwierdza zmiany lokalnie, mimo że cały przepływ pracy nie jest atomowy.

Każdy odwracalny krok definiuje działanie kompensacyjne

Saga nie wycofuje zmian we wszystkich usługach za pomocą jednego polecenia bazy danych. Kroki, które można odwrócić, definiują działania kompensacyjne przywracające poprzedni stan w sensie semantycznym lub równoważące wcześniejsze działania.

Microservices.io wyjaśnia, że awaria uruchamia transakcje kompensacyjne dla wcześniej ukończonych kroków. Kompensacja przywraca spójność, a nie usuwa historii. Azure opisuje działania kompensacyjne dla odwracalnych kroków sagi, wspierając model kompensacji zastosowany we wzorcu Saga platformy Azure.

MoveFile może mieć kompensację w postaci MoveFileBack, a DisableShare — w postaci EnableShare. Niektóre działania zewnętrzne mogą nie mieć idealnego odpowiednika odwrotnego i należy je odpowiednio oznaczyć.

Orkiestrator może ustalać kolejność wykonywania i wycofywania

W sadze opartej na orkiestracji jeden komponent przepływu pracy zna sekwencję, wysyła polecenia, rejestruje odpowiedzi i decyduje, czy kontynuować, czy rozpocząć kompensację.

Microservices.io pokazuje orkiestrator sagi wywołujący kroki i kompensacje. Centralna maszyna stanów jest często łatwiejsza do audytowania na serwerze domowym niż sieć niezależnych reakcji. Wytyczne Temporal dotyczące sagi pokazują, jak orkiestrator może rejestrować kompensacje i wywoływać je, gdy późniejszy krok zakończy się niepowodzeniem, co odpowiada koordynacji w odwrotnej kolejności opisanej we wzorcu Saga platformy Temporal.

Gdy późny krok zakończy się niepowodzeniem, kompensacje zwykle są uruchamiane w odwrotnej kolejności zależności.

Jeśli punkt montowania został zmieniony po przeniesieniu plików, przepływ pracy powinien najpierw przywrócić punkt montowania, a dopiero potem przenieść dane z powrotem.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Choreografia rozprasza koordynację między zdarzeniami

Saga oparta na choreografii pozwala każdemu uczestnikowi reagować na zdarzenia i emitować kolejne zdarzenie. Eliminuje to centralnego koordynatora, ale rozprasza logikę przepływu pracy między subskrybentami.

Wzorzec Saga wyraźnie rozróżnia choreografię i orkiestrację. Oba podejścia mogą koordynować kompensacje, ale zapewniają różny poziom obserwowalności. AWS rozróżnia orkiestrację od sterowanej zdarzeniami choreografii, co wspiera kompromis opisany w materiale AWS na temat orkiestracji sagi.

W przypadku niewielkiego przepływu pracy utrzymywanego samodzielnie orkiestracja jest często łatwiejsza do przeanalizowania. Choreografia może jednak dobrze pasować do systemów, w których niezależne usługi już komunikują się za pośrednictwem magistrali zdarzeń.

Kompensacja wymaga idempotencji i stabilnej identyfikacji działań

Kompensacja może zostać ponowiona po przekroczeniu limitu czasu lub awarii, dlatego powinna być bezpieczna przy ponownym uruchomieniu albo wykrywać, że stan docelowy został już przywrócony.

Model sagi zakłada jawne znaczenie lokalnej transakcji i transakcji kompensacyjnej. Stabilne identyfikatory przepływu pracy i kroków pomagają odróżnić ponowienie od wielokrotnego wykonania. Wytyczne IBM dotyczące sagi podkreślają znaczenie lokalnych transakcji i zachowania kompensacyjnego, wzmacniając argument, że ponowienia i kompensacje wymagają stabilnych identyfikatorów oraz idempotentnego wykonania, co opisano w wytycznych IBM dotyczących implementacji sagi.

Łączy się to z opisanymi przez ZimaSpace powtarzającymi się pętlami wywołań narzędzi przez agenta: przepływ odzyskiwania musi wiedzieć, czy bezpiecznie wznawia działanie, czy ponownie wykonuje efekt uboczny.

Saga nie może sprawić, że każde działanie stanie się naprawdę odwracalne

Niektóre działania domowe mają nieodwracalne skutki zewnętrzne.

Dostarczonej wiadomości, bezpiecznie usuniętego pliku ani zakupu dokonanego u zewnętrznego dostawcy nie zawsze da się cofnąć za pomocą odwrotnego wywołania API.

Sagi opierają się na kompensacji, a nie na uniwersalnym rozproszonym wycofywaniu. Dlatego kroki nieodwracalne powinny być wykonywane późno i podlegać starannej kontroli. Omówienie wzorców transakcji rozproszonych przez Red Hat podkreśla, że kompensacja jest działaniem korygującym na poziomie biznesowym, a nie uniwersalnym wycofaniem, co wyznacza granicę opisaną w materiale Red Hat na temat wzorców transakcji rozproszonych.

Strategia agenta ZimaSpace oparta najpierw na narzędziach tylko do odczytu zapewnia bezpieczną ścieżkę od obserwacji do modyfikacji; saga koordynuje następnie zmiany, na które celowo zezwolono.