Wzorzec nadzorcy agenta harmonogramu

Koordynuj zestaw akcji rozproszonych jako pojedynczą operację logiczną, aby operacja jako całość zakończyła się powodzeniem lub niepowodzeniem. Obsługuj błędy transparentnie, w przeciwnym razie wycofaj wykonaną pracę. Takie podejście zwiększa odporność systemów rozproszonych przez odzyskiwanie po przejściowych wyjątkach, długotrwałych błędach i awariach procesów, które przerywają wieloetapowe przepływy pracy orkiestrowane między usługami zdalnymi i zasobami.

Kontekst i problem

Aplikacje często wykonują zadania obejmujące wiele kroków, a niektóre kroki mogą wywoływać usługi zdalne lub uzyskiwać dostęp do zasobów zdalnych w ramach aranżacji logiki aplikacji. Interakcja z czymkolwiek poza procesem lokalnym naraża zadanie na różne tryby awarii. Logika aranżacji musi obsługiwać te tryby awarii bez utraty integralności operacji jako całości.

Z prostymi sytuacjami, takimi jak błędy przejściowe, które ustępują samoistnie, można sobie radzić, stosując podejścia takie jak wzorzec ponawiania. Jeśli usterki mają bardziej trwały charakter lub gdy sam orkiestrator ulegnie awarii, system musi przywrócić spójny stan na podstawie trwałych zapisów i zapewnić spójność całej operacji.

Rozwiązanie

Wzorzec Scheduler Agent Supervisor koordynuje wieloetapowe rozproszone zadanie z wykorzystaniem trzech logicznych aktorów. Ci aktorzy organizowali kroki, które mają być wykonywane w ramach ogólnego zadania, i obsługują zarówno przebiegi zakończone powodzeniem, jak i niepowodzeniem.

Harmonogram

Harmonogram organizuje kroki, które składają się na zadanie, i organizuje ich wykonywanie. Planista odpowiada za łączenie kroków w potok lub przepływ pracy oraz uruchamianie ich we właściwej kolejności. W miarę postępu poszczególnych kroków harmonogram rejestruje jego stan, na przykład krok jeszcze nie został uruchomiony, uruchomiony krok lub krok ukończony. Stan zawiera również czas zakończenia, który ogranicza, jak długo krok może trwać.

Gdy krok wymaga zdalnej usługi lub zasobu, harmonogram wywołuje odpowiedniego agenta i przekazuje do niego szczegóły pracy. Harmonogramator zwykle komunikuje się z Agentami za pomocą asynchronicznej komunikacji typu żądanie/odpowiedź, często realizowanej za pośrednictwem kolejek. Zamiast tego można użyć innych technologii obsługi komunikatów rozproszonych.

Agent

Agent obejmuje wywołanie zdalnej usługi lub dostęp do zdalnego zasobu, do którego odwołuje się krok zadania. Każdy agent zwykle opakowuje wywołania do pojedynczej usługi lub zasobu i implementuje odpowiednią obsługę błędów i logikę ponawiania prób w czasie, jaki nakłada harmonogram. W przypadku angażowania logiki ponawiania agent przekazuje stabilny identyfikator we wszystkich ponownych próbach. Kolejna usługa może użyć tego do deduplikacji.

Jeśli w przepływie pracy są używane różne usługi lub zasoby, każdy krok może odwoływać się do innego agenta. To mapowanie jest szczegółem implementacji wzorca. Aby uzyskać wskazówki dotyczące projektowania strategii ponawiania prób, zobacz Najlepsze rozwiązania dotyczące obsługi błędów przejściowych.

Opiekun

Nadzorca monitoruje status kroków wykonywanych przez planistę. Supervisor uruchamia się okresowo z częstotliwością określoną przez obciążenie i sprawdza stan kroku zarejestrowany przez Scheduler. Jeśli nadzorca znajdzie kroki, które przekroczyły limit czasu lub zakończyło się niepowodzeniem, organizuje odpowiednie działanie agenta w celu odzyskania kroku lub wyzwala inną akcję korygjącą, która może obejmować modyfikowanie stanu kroku. Nadzorca żąda tylko tych akcji odzyskiwania. Harmonogram i agenci realizują je.

Interakcje

Harmonogram, agent i nadzorca są składnikami logicznymi, a ich implementacja fizyczna zależy od używanej technologii. Na przykład możesz zaimplementować kilku agentów logicznych w ramach jednej usługi sieciowej lub jako aktywności w obrębie tego samego hostowanego procesu roboczego.

Harmonogram obsługuje postęp zadań i stan poszczególnych kroków w trwałym magazynie danych nazywanym magazynem stanów. Nadzorca używa tych informacji do określenia, czy krok zakończył się niepowodzeniem. Poniższy diagram przedstawia zależności między Planistą, Agentami, Supervisorem i magazynem stanu.

• Harmonogram organizuje i uruchamia kroki, które składają się na zadanie jako przepływ pracy.
• Krok w przepływie pracy może wysłać żądanie do agenta w celu uzyskania dostępu do zasobu zdalnego lub wywołać usługę zdalną. Żądania i odpowiedzi są zwykle wysyłane asynchronicznie.
• Agent uzyskuje dostęp do zdalnego zasobu lub usługi. Agent powinien zawierać obsługę błędów i logikę ponawiania prób.
• Harmonogram zadań przechowuje status każdego kroku w repozytorium stanów w miarę jego rozpoczynania i kończenia.
• Supervisor monitoruje status kroków w repozytorium stanów i może zażądać zaktualizowania statusu kroku.
• Supervisor prosi Scheduler o ponowienie nieudanego kroku.

Gdy aplikacja jest gotowa do uruchomienia zadania, przesyła żądanie do harmonogramu. Planista rejestruje stan początkowy zadania i jego kroków, na przykład krok jeszcze się nie rozpoczął, w repozytorium stanów, a następnie rozpoczyna wykonywanie operacji zdefiniowanych w przepływie pracy. Gdy Harmonogram rozpoczyna każdy krok, aktualizuje stan tego kroku, na przykład krok w trakcie wykonywania, w repozytorium stanów.

Jeśli krok odwołuje się do zdalnej usługi lub zasobu, harmonogram wysyła komunikat do odpowiedniego agenta. Komunikat zawiera informacje potrzebne Agentowi do wywołania usługi lub uzyskania dostępu do zasobu, a także termin zakończenia i dopuszczalną liczbę ponowień operacji.

Agent może zaimplementować dowolną logikę ponawiania prób dla swojej pracy, ale jeśli agent nie ukończy pracy w danym czasie, harmonogram zakłada, że operacja nie powiodła się i przestaje czekać na odpowiedź. Agent musi dotrzymać terminu i nie może rozpoczynać nowych działań ubocznych po upływie terminu, choć praca już będąca w toku może być kontynuowana.

Jeśli Agent pomyślnie zakończy operację, zwraca odpowiedź do Harmonogramu. Harmonogram zadań aktualizuje stan na przykład do wartości krok ukończony i rozpoczyna następny krok. Ten proces jest kontynuowany do momentu wykonania całego zadania.

Planista musi ignorować każdą opóźnioną odpowiedź, a Agent nie może samodzielnie próbować przywrócić przepływu pracy. Jeśli sam Agent ulegnie awarii, Scheduler również nie otrzyma odpowiedzi. Stan w repozytorium stanów celowo nie rozróżnia kroku, dla którego upłynął limit czasu, od kroku, który zakończył się niepowodzeniem.

Gdy wykonanie kroku przekroczy limit czasu lub zakończy się niepowodzeniem, rekord w magazynie stanów nadal wskazuje, że krok ma stan uruchomiony, ale z przekroczonym terminem ukończenia. Nadzorca skanuje rekordy w tym stanie i organizuje odzyskiwanie.

Nadzorca musi również zapobiec ponownemu ponawianiu próby na czas nieokreślony. Nadzorca utrzymuje liczbę ponownych prób dla każdego kroku wraz z informacjami o stanie w magazynie stanów. Jeśli liczba wystąpień przekroczy z góry określony próg, można skonfigurować komponent Supervisor tak, aby przed poproszeniem komponentu Scheduler o ponowienie próby wykonania kroku odczekał dłuższy czas, na wypadek gdyby w tym czasie podstawowa usterka ustąpiła.

Jedną z możliwych strategii Supervisora jest wydłużenie wartości parametru complete-by i wysłanie komunikatu do Schedulera wskazującego krok, dla którego upłynął limit czasu, aby Scheduler mógł ponowić próbę wykonania tego kroku. Ten projekt wymaga, aby logika kroku była idempotentna, ponieważ to samo zadanie może zostać wykonane więcej niż raz.

Alternatywnie Supervisor może poprosić Scheduler o cofnięcie całego zadania, uruchamiając transakcję kompensacyjną. Takie podejście opiera się na tym, że Harmonogram i Agenci dostarczają wystarczających informacji, aby wdrożyć operacje kompensujące dla każdego kroku, który został już pomyślnie ukończony. Dziennik wynagrodzeń wymaga porządkowania, a także trwałości, ponieważ operacje wyrównywujące są zwykle uruchamiane w odwrotnej kolejności kroków, które zostały ukończone. Operacja kompensująca, która sama kończy się niepowodzeniem, pozostawia zadanie w stanie, w którym nie jest ono ani ukończone, ani poprawnie wycofane. Magazyn stanu musi umożliwiać odwzorowanie tego stanu, aby operatorzy mogli go zlokalizować i zbadać.

W rzeczywistej implementacji tego wzorca wiele instancji składnika Scheduler może działać współbieżnie, a każda z nich obsługuje część zadań. Ten system może również uruchamiać wiele wystąpień każdego Agenta lub wielu Nadzorców. Gdy więcej niż jeden nadzorca jest aktywny, nadzorcy muszą koordynować, aby nie konkurowali w celu odzyskania tego samego nieudanego kroku lub zadania. Wzorzec wyboru lidera jest jednym ze sposobów koordynowania nadzorców.

Główną zaletą tego wzorca jest to, że system pozostaje odporny zarówno na błędy przejściowe, jak i nieodwracalne, i można go skompilować, aby był samonaprawialny. Jeśli Agent lub Scheduler ulegnie awarii, możesz uruchomić nową instancję, a Supervisor może doprowadzić do wznowienia zadania, którego to dotyczy. Jeśli sam Supervisor ulegnie awarii, inna instancja może przejąć działanie od momentu, w którym poprzednia została zatrzymana. Gdy Supervisor działa zgodnie z harmonogramem, nowa instancja uruchamia się automatycznie w kolejnym zaplanowanym terminie. Można również replikować magazyn stanu, aby zwiększyć odporność.

Problemy i zagadnienia

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

• Złożoność implementacji. Ten wzorzec jest trudny do zaimplementowania i wymaga dokładnego testowania każdego trybu awarii, który może wystąpić w systemie. Planowanie testowania iniekcji błędów wraz z testami funkcjonalnymi.

• Ponawianie próby wzmacniania. Niezależne limity ponawiania prób na poziomie agenta, środowiska uruchomieniowego orkiestracji, biblioteki klienckiej, warstwy komunikatów i warstwy Supervisor zwielokrotniają liczbę wywołań do zależności, która ulega awarii. Wyznacz Harmonogram jako właściciela trwałego całościowego budżetu ponowień i skonfiguruj lub wyłącz ponowienia w pozostałych warstwach tak, aby ich łączne maksimum nie mogło przekroczyć tego budżetu.

• Kontrola dostępu. Wzorzec nie ogranicza ilości pracy w locie jednocześnie. Ponieważ Scheduler został zaprojektowany tak, aby nigdy nie utracić zadań, które przyjmie, powolna lub zawodząca usługa podrzędna powoduje narastanie liczby rekordów przetwarzania zamiast wywoływać widoczny dla nadawcy sygnał przeciążenia. Ścieżka zgłoszeń wymaga własnej kontroli przyjęć, takiej jak ograniczona kolejka, limit współbieżnych zadań będących w trakcie realizacji lub odrzucanie nowych zgłoszeń, gdy liczba oczekujących zadań przekroczy określony próg. Ten mechanizm dławiący pomaga zapewnić, że incydent w dalszej części potoku nie spowoduje po cichu nieograniczonego narastania zaległości w magazynie stanu.

• Trwałość stanu odzyskiwania. Logika odzyskiwania i ponawiania prób usługi Scheduler jest złożona i zależy od stanu zapisanego w magazynie stanów. Może być również konieczne zarejestrowanie informacji wymaganych do prowadzenia transakcji wyrównywalnej w trwałym magazynie, a sama transakcja wyrównywalna może zakończyć się niepowodzeniem. Traktuj magazyn stanu oraz wszelki dziennik transakcji kompensacyjnych jako pełnoprawne, trwałe zasoby. Te zasoby muszą przeżyć harmonogram, agentów i nadzorcę i muszą być możliwe do odzyskania niezależnie od pracowników, którzy do nich zapisują.

  Important

  Dziennik kompensacji musi dziedziczyć klasyfikację danych, które ma śledzić. Jeśli krok przetwarza dane klienta lub dane dotyczące płatności, dziennik transakcji kompensacyjnej dziedziczy tę samą wrażliwość oraz odpowiadające jej zasady retencji.

• Problem z podwójnym zapisem. Przesyłanie zadania zwykle wiąże się z więcej niż jedną operacją trwałego zapisu. Na przykład zadanie może wymagać zapisania zarówno rekordu aplikacji w biznesowej bazie danych, jak i rekordu początkowego w magazynie stanu. Te operacje zapisu nie są objęte tą samą transakcją, więc jeśli powiedzie się tylko jedna z nich, rekord aplikacji może nie mieć odpowiadającego mu rekordu w magazynie stanów albo rekord w magazynie stanów może nie mieć odpowiadającego mu rekordu aplikacji. Sam bieżący wzorzec nie rozwiązuje problemu podwójnego zapisu. Typowe rozwiązania obejmują wykonywanie zapisów w ramach trwałej orkiestracji z kompensacyjnym usunięciem w przypadku niepowodzenia, zastosowanie wzorca Transactional Outbox lub użycie stabilnego identyfikatora, takiego jak własny identyfikator zadania aplikacji, aby każdy zapis można było bezpiecznie powtórzyć.

• Wersjonowanie przepływu pracy i stanu. Długotrwałe zadania mogą trwać przez wiele wdrożeń, dlatego zmiany w logice przepływu pracy lub w utrwalonym stanie mogą uniemożliwić odtworzenie, przywrócenie lub skompensowanie zadań będących w toku. Wersjonuj oba kontrakty i zachowaj zgodną obsługę kodu i stanu, dopóki nie będzie od nich zależeć żadne aktywne zadanie.

• Wyniki dotyczące wynagrodzeń. Transakcja kompensacyjna może zakończyć się powodzeniem, zakończyć się niepowodzeniem lub utknąć w trakcie. Maszyna stanu, którą obsługuje usługa Scheduler, musi reprezentować wszystkie te stany. Jeśli Error jest jedynym stanem końcowym, zablokowana kompensacja wygląda identycznie jak krok, który zakończył się niepowodzeniem przed uruchomieniem kompensacji, a operatorzy tracą sygnał potrzebny do podjęcia interwencji. Rozróżniaj kompensację w toku, kompensację zakończoną i kompensację nieudaną w schemacie magazynu stanów, zamiast sprowadzać je do jednego stanu Błąd.

• Częstotliwość nadzoru. To, jak często uruchamiać Supervisor, stanowi świadomy kompromis. Powinno być uruchamiane na tyle często, aby kroki, które zakończyły się niepowodzeniem lub przekroczyły limit czasu, nie blokowały pracy przez dłuższy czas, ale nie tak często, aby powodowało dodatkowe obciążenie i koszty dla magazynu stanów. Dostosuj interwał do typowego czasu trwania kroku i dopuszczalnego opóźnienia wykrycia zablokowanego kroku, a następnie weryfikuj go ponownie w miarę wzrostu wolumenu przepływu pracy.

• Idempotentność kroku. Agent może wykonać krok więcej niż raz. Na przykład Supervisor może wydłużyć termin ukończenia i poprosić Scheduler o ponowienie próby wykonania kroku, którego pierwotne wykonanie już wywołało skutek, którego Scheduler nigdy nie zaobserwował. W związku z tym logika, która implementuje każdy krok, musi być idempotentna.

• Widoczność operacyjna. Zachowanie wzorca w czasie działania przejawia się w przejściach stanów w magazynie stanów, a nie w odpowiedziach synchronicznych. Operatorzy widzą tylko to, co emituje magazyn stanów i procesy robocze. Zdecyduj, co harmonogram, agenci i nadzorca powinny emitować, oraz które progi powinny wyzwalać alerty.

• Ponowne uruchamianie i przywracanie harmonogramu. Jeśli Harmonogram zostanie ponownie uruchomiony po awarii lub jeśli przepływ pracy uruchomiony przez Harmonogram nieoczekiwanie się zakończy, Harmonogram musi być w stanie określić stan każdego zadania, które obsługiwał w chwili awarii, i wznowić to zadanie od tego momentu. Szczegóły implementacji tego odzyskiwania są zwykle specyficzne dla systemu. Na przykład harmonogram oparty na środowisku uruchomieniowym orkiestracji obsługującym punkty kontrolne może polegać na tym środowisku uruchomieniowym przy odtwarzaniu historii i wznawianiu działania, natomiast niestandardowy harmonogram musi samodzielnie odtworzyć bieżący stan wykonywania bezpośrednio z magazynu stanów. Jeśli nie można przywrócić zadania, może być konieczne wycofanie już wykonanej pracy związanej z tym zadaniem, co może wymagać transakcji kompensacyjnej.

Kiedy należy używać tego wzorca

Użyj tego wzorca, gdy:

• Proces działa w rozproszonym obciążeniu i musi pozostać odporny zarówno na awarie komunikacji, jak i awarie operacyjne w usługach i zasobach, które koordynuje.

• Zadania w tle organizują wieloetapowe przepływy pracy, których kroki obejmują zdalne usługi lub zasoby, a przepływy pracy jako całość muszą zostać ukończone lub cofnięte w sposób czysty. Typowe przykłady obejmują przetwarzanie zamówień i aprowizowanie zasobów. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące zadań w tle.

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

• Zadanie nie wywołuje usług zdalnych ani nie uzyskuje dostępu do zasobów zdalnych. Dla ról Scheduler, Agent i Supervisor nie występuje rozproszony obszar awarii, który należałoby ograniczać. Obciążenie związane z koordynacją wzorca zwiększa koszty bez korzyści związanych z odpornością.

Projektowanie obciążenia pracy

Oceń, jak zastosować wzorzec Scheduler Agent Supervisor w architekturze obciążenia, aby zrealizować cele i zasady omówione 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.

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

Przykład

W tym przykładzie wdrożono aplikację internetową, która implementuje system handlu elektronicznego w Microsoft Azure. Użytkownicy przeglądają produkty i składają zamówienia za pośrednictwem internetowego interfejsu użytkownika, a procesy działające w tle w procesie obsługi zamówień wywołują zdalną usługę podatną na przejściowe oraz dłużej utrzymujące się awarie. Przetwarzanie zamówień wykorzystuje wzorzec Scheduler Agent Supervisor przy użyciu Durable Functions, Azure Service Bus i Azure Cosmos DB.

Aktywność przesyłania zapisuje dane do bazy danych zamówień i magazynu stanu w usłudze Cosmos DB, koordynator Durable Functions przejmuje oczekujące rekordy stanu i przekazuje zadania agentowi za pośrednictwem pary kolejek żądań i odpowiedzi usługi Service Bus, a moduł nadzorujący skanuje magazyn stanu w poszukiwaniu wygasłych znaczników czasu CompleteBy.

Na poniższym diagramie przedstawiono ogólny widok rozwiązania Azure.

1. Aplikacja wysyła żądanie do kolejki, aby obsłużyć zamówienie.
2. Proces przesyłania pobiera żądania, wstawia szczegóły zamówienia w bazie danych zamówień i generuje rekord zamówienia w magazynie stanów.
3. Planista wyszukuje w magazynie stanów zamówienie, w przypadku którego pole LockedBy ma wartość null, a logika przepływu pracy w Planiście obsługuje to zamówienie.
4. Logika przepływu pracy wysyła żądania do agentów i odbiera odpowiedzi z agentów za pośrednictwem kolejek komunikatów.
5. Zadania przepływu pracy używają agentów do wywoływania usługi zdalnej.
6. Nadzorca wyszukuje zamówienia z wygasłą CompleteBy wartością i aktualizuje tę wartość, aby umożliwić harmonogramowi ponowne wykonanie procesu.

Zgłoszenie

Gdy klient składa zamówienie, interfejs webowy wysyła komunikat o zamówieniu do kolejki Service Bus. Funkcja przesyłania odbiera komunikat w trybie PeekLock, wstawia szczegóły zamówienia do bazy danych zamówień i tworzy rekord magazynu stanów dla procesu zamówienia.

Ponieważ baza danych zamówień i baza danych utworzona za pomocą usługi Azure Cosmos DB są różnymi zasobami i nie współdzielą transakcji, funkcja traktuje każdy zapis jako niezależnie wykonywaną operację idempotentną. Funkcja używa identyfikatora zamówienia jako stabilnego klucza, tworzy dowolny rekord, gdy go brakuje i akceptuje istniejący rekord dopiero po sprawdzeniu, czy jego niezmienne dane zamówienia są zgodne z komunikatem. Sprzeczne dane powodują, że funkcja przenosi wiadomość do kolejki wiadomości niedostarczonych i ostrzega operatora, zamiast nadpisywać rekord.

Rekord zawiera następujące pola:

Gdy działanie przesłania po raz pierwszy zapisuje rekord, kopiuje OrderID z nowego zamówienia, ustawia LockedBy i CompleteBy na null, ustawia Pending na ProcessState oraz FailureCount na 0.

Scheduling

Harmonogram jest orkiestratorem Durable Functions. Funkcja starter sonduje Azure Cosmos DB dla rekordów, w których LockedBy ma wartość null i ProcessState ma wartość Pending. Funkcja tworzy identyfikator wystąpienia orkiestracji specyficzny dla próby na podstawie OrderID i numeru następnej próby. Warunkowa aktualizacja ustawia ProcessState na Processing, a LockedBy na ten identyfikator wystąpienia, zanim moduł uruchamiający zaplanuje orkiestrację. To oświadczenie uniemożliwia zaplanowanie tej samej próby przez dwa startery.

Każda aktualizacja w ramach orkiestracji sprawdza również, czy LockedBy nadal odpowiada swojemu identyfikatorowi wystąpienia. Ta kontrola uniemożliwia wygasłą próbę zmiany stanu próby zastąpienia. Równoległość między kolejnościami pochodzi z uruchamiania wielu wystąpień orkiestracji jednocześnie, a nie z równoległości wewnątrz jednej kolejności. Orkiestracja ustawia CompleteBy i napędza przepływ pracy.

Orkiestrator pobiera szczegóły zamówienia z bazy danych zamówień i uruchamia przepływ pracy jako sekwencję funkcji działania. Gdy krok wymaga usługi zdalnej, wywołuje agenta.

Execution

Agent może być funkcją aktywności, gdy praca jest krótkotrwała i działa w tej samej aplikacji funkcji, albo oddzielnym procesem roboczym, z którym komunikacja odbywa się za pośrednictwem pary kolejek żądań/odpowiedzi usługi Service Bus, gdy działa on w innym środowisku uruchomieniowym lub po różnych stronach granicy zaufania. W obu przypadkach orkiestrator zestawia trwały czasomierz z odpowiedzią agenta, aby wykryć CompleteBy nadejście terminu.

Gdy z Agentem nawiązywana jest komunikacja za pośrednictwem usługi Service Bus, funkcja wyzwalana przez kolejkę odbiera odpowiedź i używa klienta Durable Functions, aby zgłosić zdarzenie zewnętrzne zawierające identyfikator wystąpienia orkiestracji oraz stabilny identyfikator zdarzenia. Orkiestrator eliminuje duplikaty zdarzeń zewnętrznych przez włączenie funkcji wykrywania duplikatów i ustawienie stabilnego MessageId w każdym żądaniu, dzięki czemu Service Bus może odrzucać duplikaty powstałe w wyniku ponowień.

Jeśli agent otrzyma odpowiedź z usługi zdalnej przed uruchomieniem trwałego czasomierza, agent zwróci wynik do orkiestratora. Orkiestrator kończy ten krok i aktualizuje ProcessState do Processed tylko wtedy, gdy LockedBy nadal identyfikuje bieżącą orkiestrację. Jeśli timer uruchomi się jako pierwszy, orkiestrator uznaje krok za nieudany, przestaje czekać i kończy działanie bez zmiany rekordu stanu.

Agent w sposób kontrolowany przestaje rozpoczynać nowe efekty uboczne po upływie własnego limitu czasu, ale już rozpoczęte operacje mogą być nadal wykonywane. Rekord magazynu stanu pozostaje następnie w stanie Processing z przeterminowaną wartością CompleteBy, co umożliwia Nadzorcy zorganizowanie procesu odzyskiwania. Użyj idempotentności lub tokenu odgradzającego wymuszanego przez system docelowy, aby zapobiec zduplikowaniu efektu ubocznego przez równoległą próbę lub wejściu z nim w konflikt.

Jeśli Agent wykryje podczas komunikacji ze zdalną usługą trwały błąd, którego nie można naprawić i który nie ma charakteru przejściowego, zwraca do orkiestratora odpowiedź z błędem. Orkiestrator ustawia wartość ProcessState na Error i generuje zdarzenie, które alarmuje operatora, aby mógł zbadać awarię i ponownie uruchomić nieudany etap przetwarzania.

Nadzór

Nadzorca okresowo wysyła zapytanie do magazynu stanów Azure Cosmos DB pod kątem zamówień w Processing stanie z wygasłym CompleteBy. Ponieważ OrderID jest kluczem partycji, to zapytanie osiąga każdą partycję fizyczną nawet wtedy, gdy ProcessState i CompleteBy są indeksowane. Proces ogranicza każde skanowanie za pomocą okna czasowego CompleteBy, maksymalnej liczby wyników oraz stronicowania za pomocą tokenu kontynuacji, a także monitoruje zużycie jednostek żądania (RU).

Większe obciążenia utrzymują oddzielny indeks odzyskiwania lub kolejkę partycjonowaną dla wzorca dostępu nadzorcy. Gdy nadzorca znajdzie wygasły rekord, używa aktualizacji warunkowej, która weryfikuje wygasłą LockedBy wartość przed jej wzrostem FailureCount. Jeśli FailureCount jest poniżej skonfigurowanego progu, Supervisor resetuje LockedBy do null, aktualizuje CompleteBy, ustawiając nowy czas wygaśnięcia, i ustawia ProcessState z powrotem na Pending, co pozwala modułowi startera zaplanować nową próbę. Jeśli FailureCount przekroczy próg, moduł Supervisor traktuje awarię jako trwałą, ustawia ProcessState na Error i generuje zdarzenie alarmujące operatora.

Raportowanie stanu

Orkiestrator może również potrzebować informować aplikację, która złożyła zamówienie, o postępach i statusie końcowym, czego nie pokazano na diagramie. Aplikacja i orkiestrator są celowo oddzielone. Aplikacja nie wie, która instancja orkiestracji obsługuje zamówienie, a orkiestracja nie wie, która instancja aplikacji je wysłała. Ze względu na to oddzielenie orkiestrator nie może synchronicznie zwracać aktualizacji postępu.

Aby przekazać informację zwrotną o statusie zamówienia, każda aplikacja wysyłająca udostępnia własną prywatną kolejkę odpowiedzi usługi Service Bus z kontrolą dostępu. Żądanie wysłane do działania zgłoszenia zawiera identyfikator tej kolejki, który działanie zgłoszenia zapisuje w rekordzie magazynu stanu zamówienia, dzięki czemu orkiestrator może wysłać komunikat do właściwej kolejki zamiast go rozgłaszać. Następnie orkiestrator publikuje w tej kolejce komunikaty o stanie, takie jak żądanie odebrane, zamówienie ukończone lub realizacja zamówienia nie powiodła się, dołączając także OrderID, aby aplikacja mogła powiązać każdy komunikat z pierwotnym żądaniem.

Technologie pomocnicze

Zamapuj role logiczne wzorca na usługi spełniające wymagania dotyczące przepływu pracy i działania:

• Harmonogram: Użyj Durable Functions do orkiestracji opartej na kodzie lub Azure Logic Apps na potrzeby wizualnych przepływów pracy i integracji opartej na łącznikach.

• Komunikacja agenta: Użyj kolejek Service Bus do asynchronicznej komunikacji żądań i odpowiedzi.

• Magazyn stanów: Użyj Azure Cosmos DB dla stanu dokumentu lub Azure SQL Database dla stanu relacyjnego i transakcji między rekordami.

• Supervisor: Użyj wyzwalacza czasowego usługi Functions do lekkich skanów lub zadania usługi Container Apps, gdy potrzebujesz środowiska uruchomieniowego kontenerów.

• Dziennik kompensacji: Przechowuj rekordy kompensacji wraz ze stanem zadania lub w usłudze Azure Table Storage albo w Blob Storage.

Następne kroki

• Wybierz między Azure Functions a Azure Logic Apps na potrzeby orkiestracji przepływu pracy.
• Aranżacje wersji Durable Functions w celu ochrony przepływów pracy w locie podczas wdrożeń.
• Zapobiegaj utracie komunikatów i duplikowaniu przetwarzania w Azure Service Bus, łącząc rozliczenia komunikatów, idempotentność i obsługę utraconych komunikatów.

Powiązane zasoby

Podczas implementowania tego wzorca mogą być również istotne następujące wzorce:

• Wzorzec ponawiania. Agent może użyć tego wzorca, aby w przezroczysty sposób ponowić próbę wykonania operacji, która uzyskuje dostęp do zdalnej usługi lub zasobu i wcześniej zakończyła się niepowodzeniem. Użyj go, gdy przyczyna błędu ma być przejściowa i może zostać poprawiona przez ponowną próbę.

• Wzorzec Circuit Breaker. Agent łączący się ze zdalną usługą lub zasobem może używać tego wzorca do obsługi awarii, których usunięcie może zająć różną ilość czasu, dzięki czemu ponawiane wywołania nie kumulują się względem zależności, która prawdopodobnie nie odpowie.

• Wzorzec transakcji wyrównującej. Jeśli harmonogram zadań nie może pomyślnie zakończyć przepływu pracy, konieczne może być cofnięcie już wykonanej pracy. Wzorzec transakcji kompensacyjnej opisuje, jak cofnąć skutki tej pracy w przypadku operacji opartych na modelu spójności ostatecznej, co jest powszechne w długotrwałych procesach biznesowych koordynowanych przez Scheduler.

• Wzorzec wyboru lidera. Gdy wiele instancji Supervisora działa równocześnie, muszą one koordynować swoje działania, aby nie rywalizować o przywrócenie tego samego nieudanego kroku. Wzorzec wyboru lidera opisuje sposób wybierania jednego koordynatora dla tej pracy.