Ciągłość działania i odzyskiwanie po awarii dla usługi Azure Logic Apps

  • Artykuł

Aby pomóc zmniejszyć wpływ i skutki, które nieprzewidywalne zdarzenia mają na firmę i klientów, upewnij się, że masz rozwiązanie odzyskiwania po awarii (DR), aby można było chronić dane, szybko przywrócić zasoby, które obsługują krytyczne funkcje biznesowe, i zachować działanie operacji w celu utrzymania ciągłości działalności biznesowej (BC). Na przykład zakłócenia mogą obejmować awarie, straty w podstawowej infrastrukturze lub składnikach, takich jak magazyn, sieć lub zasoby obliczeniowe, nieodwracalne awarie aplikacji, a nawet pełna utrata centrum danych. Dzięki gotowemu rozwiązaniu do zapewnienia ciągłości działania i odzyskiwania po awarii (BCDR) twoje przedsiębiorstwo lub organizacja może szybciej reagować na przerwy, planowane lub nieplanowane oraz zmniejszyć przestoje dla klientów.

Ten artykuł zawiera wskazówki i strategie bcDR, które można zastosować podczas tworzenia zautomatyzowanych przepływów pracy przy użyciu usługi Azure Logic Apps. Przepływy pracy aplikacji logiki ułatwiają integrację i organizowanie danych między aplikacjami, usługami w chmurze i systemami lokalnymi przez zmniejszenie ilości kodu, który trzeba napisać. Podczas planowania bcDR upewnij się, że rozważasz nie tylko aplikacje logiki, ale także te zasoby platformy Azure, które są używane z aplikacjami logiki:

Lokalizacje podstawowe i pomocnicze

Każda aplikacja logiki musi określić lokalizację, której chcesz użyć do wdrożenia. Ta lokalizacja jest regionem publicznym na globalnej platformie Azure z wieloma dzierżawami, takimi jak "Zachodnie stany USA" lub środowisko usługi integracji (ISE), które zostało wcześniej utworzone i wdrożone w sieci wirtualnej platformy Azure. Uruchamianie aplikacji logiki w środowisku ISE jest podobne do uruchamiania aplikacji logiki w globalnym regionie świadczenia usługi Azure, co oznacza, że strategia odzyskiwania po awarii może być stosowana w obu scenariuszach. Jednak dostawcy ises mają inne zagadnienia, takie jak konfigurowanie dostępu do zasobów, które są dostępne tylko dla ises.

Uwaga

Jeśli aplikacja logiki współpracuje również z artefaktami B2B, takimi jak partnerzy handlowi, umowy, schematy, mapy i certyfikaty, które są przechowywane na koncie integracji, zarówno twoje konto integracji, jak i aplikacje logiki muszą określić tę samą lokalizację.

Ta strategia odzyskiwania po awarii koncentruje się na konfigurowaniu podstawowej aplikacji logiki w celu przejścia w tryb failover na aplikację logiki rezerwowej lub kopii zapasowej w alternatywnej lokalizacji, w której jest również dostępna usługa Azure Logic Apps. W ten sposób, jeśli podstawowa poniesie straty, zakłócenia lub awarie, pomocnicza może podjąć pracę. Ta strategia wymaga, aby pomocnicza aplikacja logiki i zasoby zależne zostały już wdrożone i gotowe w lokalizacji alternatywnej.

Jeśli zastosujesz się do dobrych rozwiązań devOps, szablony usługi Azure Resource Manager są już używane do definiowania i wdrażania aplikacji logiki oraz ich zasobów zależnych. szablony Resource Manager umożliwiają korzystanie z jednej definicji wdrożenia, a następnie używanie plików parametrów w celu udostępnienia wartości konfiguracji do użycia dla każdego miejsca docelowego wdrożenia. Ta funkcja oznacza, że można wdrożyć tę samą aplikację logiki w różnych środowiskach, na przykład programistyczne, testowe i produkcyjne. Możesz również wdrożyć tę samą aplikację logiki w różnych regionach platformy Azure lub środowiskach ISE, które obsługują strategie odzyskiwania po awarii korzystające z sparowanych regionów.

W przypadku strategii trybu failover aplikacje logiki i lokalizacje muszą spełniać następujące wymagania:

  • Wystąpienie pomocniczej aplikacji logiki ma dostęp do tych samych aplikacji, usług i systemów co podstawowe wystąpienie aplikacji logiki.

  • Oba wystąpienia aplikacji logiki mają ten sam typ hosta. W związku z tym oba wystąpienia są wdrażane w regionach w globalnej wielodostępnej platformie Azure lub oba wystąpienia są wdrażane w środowiskach ISE, co umożliwia aplikacjom logiki bezpośredni dostęp do zasobów w sieci wirtualnej platformy Azure. Aby uzyskać najlepsze rozwiązania i więcej informacji na temat sparowanych regionów dla bcDR, zobacz Replikacja między regionami na platformie Azure: ciągłość działania i odzyskiwanie po awarii.

    Na przykład zarówno lokalizacje podstawowe, jak i pomocnicze muszą być lokalizacjami ISE, gdy podstawowa aplikacja logiki działa w środowisku ISE i używa łączników z wersją ISE, akcji HTTP do wywoływania zasobów w sieci wirtualnej platformy Azure lub obu tych elementów. W tym scenariuszu pomocnicza aplikacja logiki musi również mieć podobną konfigurację w lokalizacji pomocniczej jako podstawową aplikację logiki.

    Uwaga

    W przypadku bardziej zaawansowanych scenariuszy można mieszać platformę Azure z wieloma dzierżawami i platformę ISE jako lokalizacje. Upewnij się jednak, że rozważasz i rozumiesz różnice między sposobem działania aplikacji logiki w środowisku ISE a wielodostępną platformą Azure.

  • Jeśli używasz ise, upewnij się, że są one skalowane w poziomie lub mają wystarczającą pojemność do obsługi obciążenia.

Przykład: platforma Azure z wieloma dzierżawami

W tym przykładzie przedstawiono wystąpienia podstawowej i pomocniczej aplikacji logiki, które są wdrażane w oddzielnych regionach w globalnej wielodostępnej platformie Azure w tym scenariuszu. Pojedynczy szablon Resource Manager definiuje zarówno wystąpienia aplikacji logiki, jak i zasoby zależne wymagane przez te aplikacje logiki. Oddzielne pliki parametrów określają wartości konfiguracji do użycia dla każdej lokalizacji wdrożenia:

Wystąpienia podstawowej i pomocniczej aplikacji logiki w oddzielnych lokalizacjach

Przykład: środowisko usługi integracji

W tym przykładzie przedstawiono poprzednie wystąpienia aplikacji podstawowej i pomocniczej aplikacji logiki, ale wdrożone w oddzielnych środowiskach ISE. Pojedynczy szablon Resource Manager definiuje zarówno wystąpienia aplikacji logiki, zasoby zależne wymagane przez te aplikacje logiki, jak i środowiska ISE jako lokalizacje wdrożenia. Oddzielne pliki parametrów definiują wartości konfiguracji do użycia do wdrożenia w każdej lokalizacji:

Podstawowe i pomocnicze aplikacje logiki w różnych lokalizacjach

Połączenia z zasobami

Usługa Azure Logic Apps udostępnia wiele setek operacji łącznika, których przepływ pracy aplikacji logiki może używać do pracy z innymi aplikacjami, usługami, systemami i innymi zasobami, takimi jak konta usługi Azure Storage, SQL Server bazy danych, służbowe konta e-mail itd. Jeśli aplikacja logiki potrzebuje dostępu do tych zasobów, należy utworzyć połączenia, które uwierzytelniają dostęp do tych zasobów. Każde połączenie jest oddzielnym zasobem platformy Azure, który istnieje w określonej lokalizacji i nie może być używany przez zasoby w innych lokalizacjach.

W przypadku strategii odzyskiwania po awarii rozważ lokalizacje, w których istnieją zasoby zależne względem wystąpień aplikacji logiki:

  • Wystąpienie podstawowe i zasoby zależne istnieją w różnych lokalizacjach. W takim przypadku wystąpienie pomocnicze może łączyć się z tymi samymi zasobami zależnymi lub punktami końcowymi. Należy jednak utworzyć połączenia specjalnie dla wystąpienia pomocniczego. W ten sposób, jeśli lokalizacja podstawowa stanie się niedostępna, połączenia pomocnicze nie będą miały wpływu.

    Załóżmy na przykład, że podstawowa aplikacja logiki łączy się z usługą zewnętrzną, taką jak Salesforce. Zwykle dostępność i lokalizacja usługi zewnętrznej są niezależne od dostępności aplikacji logiki. W takim przypadku wystąpienie pomocnicze może nawiązać połączenie z tą samą usługą, ale powinno mieć własne połączenie.

  • Zarówno wystąpienie podstawowe, jak i zasoby zależne istnieją w tej samej lokalizacji. W takim przypadku zasoby zależne powinny mieć kopie zapasowe lub replikowane wersje w innej lokalizacji, aby wystąpienie pomocnicze mogło nadal uzyskiwać dostęp do tych zasobów.

    Załóżmy na przykład, że podstawowa aplikacja logiki łączy się z usługą znajdującą się w tej samej lokalizacji lub regionie, na przykład Azure SQL Database. Jeśli cały region stanie się niedostępny, usługa Azure SQL Database w tym regionie jest również prawdopodobnie niedostępna. W takim przypadku chcesz, aby wystąpienie pomocnicze używało replikowanej lub kopii zapasowej bazy danych wraz z oddzielnym połączeniem z tą bazą danych.

Lokalne bramy danych

Jeśli aplikacja logiki działa na platformie Azure z wieloma dzierżawami i potrzebuje dostępu do zasobów lokalnych, takich jak SQL Server baz danych, musisz zainstalować lokalną bramę danych na komputerze lokalnym. Następnie możesz utworzyć zasób bramy danych w Azure Portal, aby aplikacja logiki mogła używać bramy podczas tworzenia połączenia z zasobem.

Zasób bramy danych jest skojarzony z lokalizacją lub regionem platformy Azure, podobnie jak zasób aplikacji logiki. W strategii odzyskiwania po awarii upewnij się, że brama danych pozostaje dostępna dla aplikacji logiki do użycia. Wysoką dostępność bramy można włączyć , jeśli masz wiele instalacji bramy.

Uwaga

Jeśli aplikacja logiki działa w środowisku usługi integracji (ISE) i używa tylko łączników ISE w wersji dla lokalnych źródeł danych, nie potrzebujesz bramy danych, ponieważ łączniki ISE zapewniają bezpośredni dostęp do zasobu lokalnego.

Jeśli dla żądanego zasobu lokalnego nie jest dostępny łącznik ISE, aplikacja logiki nadal może utworzyć połączenie przy użyciu łącznika innego niż ISE, który działa w globalnej wielodostępnej platformie Azure, a nie w środowisku ISE. Jednak to połączenie wymaga lokalnej bramy danych.

Role aktywne-aktywne i aktywne-pasywne

Możesz skonfigurować lokalizacje podstawowe i pomocnicze, aby wystąpienia aplikacji logiki w tych lokalizacjach mogły odgrywać następujące role:

Rola pomocnicza podstawowa Opis
Aktywny-aktywny Wystąpienia podstawowej i pomocniczej aplikacji logiki w obu lokalizacjach aktywnie obsługują żądania, wykonując jedną z następujących wzorców:

- Równoważenie obciążenia: oba wystąpienia mogą nasłuchiwać punktu końcowego i równoważyć obciążenie ruchu do każdego wystąpienia w razie potrzeby.

- Konkurujący konsumenci: oba wystąpienia mogą działać jako konkurujący konsumenci, aby wystąpienia rywalizowały o komunikaty z kolejki. Jeśli jedno wystąpienie zakończy się niepowodzeniem, drugie wystąpienie przejmie obciążenie.
Aktywne-pasywne Wystąpienie podstawowej aplikacji logiki aktywnie obsługuje całe obciążenie, podczas gdy wystąpienie pomocnicze jest pasywne (wyłączone lub nieaktywne). Pomocnicza czeka na sygnał, że podstawowy jest niedostępny lub nie działa z powodu zakłóceń lub awarii i przejmuje obciążenie jako aktywne wystąpienie.
Połączenie Niektóre aplikacje logiki odgrywają aktywną-aktywną rolę, podczas gdy inne aplikacje logiki odgrywają aktywną-pasywną rolę.

Przykłady aktywne-aktywne

W tych przykładach pokazano konfigurację aktywne-aktywne, w której oba wystąpienia aplikacji logiki aktywnie obsługują żądania lub komunikaty. Inny system lub usługa dystrybuuje żądania lub komunikaty między wystąpieniami, na przykład jedną z następujących opcji:

  • "Fizyczny" moduł równoważenia obciążenia, taki jak sprzęt, który kieruje ruchem

  • "miękki" moduł równoważenia obciążenia, taki jak Azure Load Balancer lub Azure API Management. Za pomocą API Management można określić zasady określające sposób równoważenia obciążenia ruchu przychodzącego. Możesz też użyć usługi obsługującej śledzenie stanu, na przykład Azure Service Bus.

    Chociaż w tym przykładzie przedstawiono przede wszystkim Azure Load Balancer, można użyć opcji najlepiej odpowiadającej potrzebom scenariusza:

    Konfiguracja

  • Każde wystąpienie aplikacji logiki działa jako użytkownik i ma oba wystąpienia rywalizują o komunikaty z kolejki:

    Konfiguracja

Przykłady aktywne-pasywne

W tym przykładzie przedstawiono konfigurację aktywne-pasywne, w której główne wystąpienie aplikacji logiki jest aktywne w jednej lokalizacji, podczas gdy wystąpienie pomocnicze pozostaje nieaktywne w innej lokalizacji. Jeśli podstawowe wystąpią zakłócenia lub awarie, możesz uruchomić operator, który aktywuje pomocniczą akcję, aby przejąć obciążenie.

Konfiguracja

Połączenie z aktywne-aktywne i aktywne-pasywne

W tym przykładzie przedstawiono połączoną konfigurację, w której lokalizacja podstawowa ma zarówno aktywne wystąpienia aplikacji logiki, jak i lokacja pomocnicza ma wystąpienia aplikacji logiki aktywne-pasywne. Jeśli lokalizacja podstawowa wystąpi zakłócenia lub awaria, aktywna aplikacja logiki w lokalizacji pomocniczej, która obsługuje już częściowe obciążenie, może przejąć całe obciążenie.

  • W lokalizacji podstawowej aktywna aplikacja logiki nasłuchuje kolejki Azure Service Bus dla komunikatów, podczas gdy inna aktywna aplikacja logiki sprawdza wiadomości e-mail przy użyciu wyzwalacza sondowania programu Office 365 Outlook.

  • W lokalizacji pomocniczej aktywna aplikacja logiki współpracuje z aplikacją logiki w lokalizacji podstawowej przez nasłuchiwanie i konkurowanie o komunikaty z tej samej kolejki usługi Service Bus. Tymczasem pasywna nieaktywna aplikacja logiki czeka na wstrzymanie, aby sprawdzić wiadomości e-mail, gdy lokalizacja podstawowa stanie się niedostępna, ale jest wyłączona , aby uniknąć ponownego odczytywania wiadomości e-mail.

Kombinacja

Stan i historia aplikacji logiki

Po wyzwoleniu i uruchomieniu aplikacji logiki stan aplikacji jest przechowywany w tej samej lokalizacji, w której uruchomiono aplikację i nie można jej przenieść do innej lokalizacji. Jeśli wystąpi awaria lub zakłócenia, wszystkie wystąpienia przepływu pracy w toku zostaną porzucone. Jeśli masz skonfigurowane lokalizacje podstawowe i pomocnicze, nowe wystąpienia przepływu pracy zaczynają działać w lokalizacji pomocniczej.

Zmniejszanie porzuconych wystąpień w toku

Aby zminimalizować liczbę porzuconych wystąpień przepływu pracy w toku, możesz wybrać spośród różnych wzorców komunikatów, które można zaimplementować, na przykład:

  • Naprawiono wzorzec poślizgu routingu

    Ten wzorzec komunikatów przedsiębiorstwa, który dzieli proces biznesowy na mniejsze etapy. Dla każdego etapu skonfigurujesz aplikację logiki, która obsługuje obciążenie dla tego etapu. Aby komunikować się ze sobą, aplikacje logiki używają asynchronicznego protokołu obsługi komunikatów, takiego jak kolejki lub tematy Azure Service Bus. Po podzieleniu procesu na mniejsze etapy można zmniejszyć liczbę procesów biznesowych, które mogą zostać zablokowane w wystąpieniu aplikacji logiki, które zakończyło się niepowodzeniem. Aby uzyskać więcej ogólnych informacji na temat tego wzorca, zobacz Wzorce integracji dla przedsiębiorstw — poślizg routingu.

    W tym przykładzie przedstawiono wzorzec poślizgu routingu, w którym każda aplikacja logiki reprezentuje etap i używa kolejki usługi Service Bus do komunikowania się z następną aplikacją logiki w procesie.

    Dzielenie procesu biznesowego na etapy reprezentowane przez aplikacje logiki, które komunikują się ze sobą przy użyciu kolejek Azure Service Bus

    Jeśli zarówno wystąpienia aplikacji podstawowej, jak i pomocniczej aplikacji logiki są zgodne ze wzorcem poślizgu routingu w ich lokalizacjach, możesz zaimplementować konkurencyjny wzorzec konsumentów , konfigurując aktywne-aktywne role dla tych wystąpień.

  • Wzorzec menedżera procesów (brokera)

  • Podgląd blokady bez wzorca limitu czasu

Dostęp do historii wyzwalacza i uruchamiania

Aby uzyskać więcej informacji na temat poprzednich wykonań przepływu pracy aplikacji logiki, możesz przejrzeć historię wyzwalacza i uruchamiania aplikacji. Historia wykonywania aplikacji logiki jest przechowywana w tej samej lokalizacji lub regionie, w którym uruchomiono tę aplikację logiki, co oznacza, że nie można migrować tej historii do innej lokalizacji. Jeśli wystąpienie podstawowe przechodzi w tryb failover do wystąpienia pomocniczego, możesz uzyskać dostęp tylko do wyzwalacza każdego wystąpienia i historii uruchamiania w odpowiednich lokalizacjach, w których uruchomiono te wystąpienia. Możesz jednak uzyskać niezależne od lokalizacji informacje o historii aplikacji logiki, konfigurując aplikacje logiki w celu wysyłania zdarzeń diagnostycznych do obszaru roboczego usługi Azure Log Analytics. Następnie możesz przejrzeć kondycję i historię w aplikacjach logiki uruchamianych w wielu lokalizacjach.

Wskazówki dotyczące typów wyzwalaczy

Typ wyzwalacza używany w aplikacjach logiki określa opcje konfigurowania aplikacji logiki w różnych lokalizacjach w strategii odzyskiwania po awarii. Poniżej przedstawiono dostępne typy wyzwalaczy, których można używać w aplikacjach logiki:

Wyzwalacz cyklu

Wyzwalacz cyklu jest niezależny od dowolnej konkretnej usługi lub punktu końcowego i uruchamia wyłącznie określony harmonogram i nie ma żadnych innych kryteriów, na przykład:

  • Stała częstotliwość i interwał, na przykład co 10 minut
  • Bardziej zaawansowany harmonogram, taki jak ostatni poniedziałek każdego miesiąca o godzinie 17:00

Gdy aplikacja logiki rozpoczyna się od wyzwalacza cyklu, musisz skonfigurować wystąpienia podstawowej i pomocniczej aplikacji logiki z rolami aktywne-pasywne. Aby skrócić cel czasu odzyskiwania (RTO), który odnosi się do docelowego czasu trwania przywracania procesu biznesowego po zakłóceniu lub awarii, można skonfigurować wystąpienia aplikacji logiki z kombinacją aktywnych-pasywnych ról i ról pasywnych-aktywnych. W tej konfiguracji harmonogram jest podzielony między lokalizacje.

Załóżmy na przykład, że masz aplikację logiki, która musi działać co 10 minut. Możesz skonfigurować aplikacje logiki i lokalizacje, aby jeśli lokalizacja podstawowa stanie się niedostępna, lokalizacja pomocnicza może przejąć pracę:

Kombinacja

  • W lokalizacji podstawowej skonfiguruj role aktywne-pasywne dla tych aplikacji logiki:

    • W przypadku aktywnej aplikacji logiki z włączoną obsługą ustaw wyzwalacz Cykl, aby rozpocząć w górnej części godziny i powtarzać co 20 minut, na przykład 9:00, 9:20 i tak dalej.

    • W przypadku pasywnej wyłączonej aplikacji logiki ustaw wyzwalacz Cykl na taki sam harmonogram, ale zacznij od 10 minut po godzinie i powtarzaj co 20 minut, na przykład 9:10 am, 9:30 i tak dalej.

  • W lokalizacji pomocniczej skonfiguruj aktywną pasywnie dla tych aplikacji logiki:

    • W przypadku pasywnej wyłączonej aplikacji logiki ustaw wyzwalacz Cykl na taki sam harmonogram jak aktywna aplikacja logiki w lokalizacji podstawowej, która znajduje się w górnej części godziny i powtarzaj co 20 minut, na przykład 9:00, 9:10 i tak dalej.

    • Dla aktywnej aplikacji logiki z włączoną obsługą ustaw wyzwalacz Cykl na taki sam harmonogram jak pasywna aplikacja logiki w lokalizacji podstawowej, która ma rozpoczynać się od 10 minut po godzinie i powtarzać co 20 minut, na przykład 9:10 am, 9:20 i tak dalej.

Jeśli teraz w lokalizacji podstawowej wystąpi zdarzenie zakłócające, aktywuj pasywną aplikację logiki w alternatywnej lokalizacji. W ten sposób, jeśli znalezienie błędu zajmuje czas, ta konfiguracja ogranicza liczbę nieodebranych cykli w tym opóźnieniu.

Wyzwalacz sondowania

Aby regularnie sprawdzać, czy nowe dane do przetwarzania są dostępne w określonej usłudze lub punkcie końcowym, aplikacja logiki może używać wyzwalacza sondowania , który wielokrotnie wywołuje usługę lub punkt końcowy na podstawie stałego harmonogramu cyklu. Dane, które udostępnia usługa lub punkt końcowy, mogą mieć jeden z następujących typów:

  • Dane statyczne, które opisują dane, które są zawsze dostępne do odczytu
  • Dane nietrwałe, które opisują dane, które nie są już dostępne po odczytaniu

Aby uniknąć wielokrotnego odczytywania tych samych danych, aplikacja logiki musi pamiętać, które dane były wcześniej odczytywane, zachowując stan po stronie klienta lub po stronie serwera, usługi lub systemu.

  • Aplikacje logiki, które współpracują ze stanem po stronie klienta, używają wyzwalaczy, które mogą obsługiwać stan.

    Na przykład wyzwalacz, który odczytuje nową wiadomość ze skrzynki odbiorczej poczty e-mail, wymaga, aby wyzwalacz zapamiętał ostatnio odczytywaną wiadomość. W ten sposób wyzwalacz uruchamia aplikację logiki tylko wtedy, gdy pojawi się następny nieprzeczytany komunikat.

  • Aplikacje logiki, które działają z serwerem, usługą lub stanem po stronie systemu, używają wartości właściwości lub ustawień, które znajdują się po stronie serwera, usługi lub systemu.

    Na przykład wyzwalacz oparty na zapytaniach, który odczytuje wiersz z bazy danych, wymaga, aby wiersz miał kolumnę ustawioną isRead na FALSE. Za każdym razem, gdy wyzwalacz odczytuje wiersz, aplikacja logiki aktualizuje ten wiersz, zmieniając kolumnę isRead z FALSE na TRUE.

    Takie podejście po stronie serwera działa podobnie w przypadku kolejek lub tematów usługi Service Bus, które mają semantyka kolejkowania, gdzie wyzwalacz może odczytywać i blokować komunikat, gdy aplikacja logiki przetwarza komunikat. Po zakończeniu przetwarzania aplikacji logiki wyzwalacz usuwa komunikat z kolejki lub tematu.

Z perspektywy odzyskiwania po awarii podczas konfigurowania wystąpień podstawowych i pomocniczych aplikacji logiki upewnij się, że uwzględniasz te zachowania na podstawie tego, czy aplikacja logiki śledzi stan po stronie klienta, czy po stronie serwera:

  • W przypadku aplikacji logiki, która współpracuje ze stanem po stronie klienta, upewnij się, że aplikacja logiki nie odczytuje tego samego komunikatu więcej niż raz. Tylko jedna lokalizacja może mieć aktywne wystąpienie aplikacji logiki w dowolnym momencie. Upewnij się, że wystąpienie aplikacji logiki w lokalizacji alternatywnej jest nieaktywne lub wyłączone, dopóki wystąpienie podstawowe nie przełączy się w tryb failover do lokalizacji alternatywnej.

    Na przykład wyzwalacz Office 365 Outlook zachowuje stan po stronie klienta i śledzi sygnaturę czasową ostatniego odczytu wiadomości e-mail, aby uniknąć odczytywania duplikatu.

  • W przypadku aplikacji logiki, która działa ze stanem po stronie serwera, można skonfigurować wystąpienia aplikacji logiki do odtwarzania ról aktywne-aktywne , w których działają jako konkurujący konsumenci lub role aktywne-pasywne , w których wystąpienie alternatywne czeka aż wystąpienie podstawowe przełączy się w tryb failover do lokalizacji alternatywnej.

    Na przykład odczyt z kolejki komunikatów, taki jak kolejka Azure Service Bus, używa stanu po stronie serwera, ponieważ usługa kolejkowania zachowuje blokady komunikatów, aby uniemożliwić innym klientom odczytywanie tych samych komunikatów.

    Uwaga

    Jeśli aplikacja logiki musi odczytywać komunikaty w określonej kolejności, na przykład z kolejki usługi Service Bus, możesz użyć konkurencyjnego wzorca konsumenta, ale tylko w połączeniu z sesjami usługi Service Bus, który jest również znany jako wzorzec konwoju sekwencyjnego. W przeciwnym razie należy skonfigurować wystąpienia aplikacji logiki z rolami aktywne-pasywne.

Wyzwalacz żądania

Wyzwalacz Żądanie sprawia, że aplikacja logiki może być wywoływana z innych aplikacji, usług i systemów i jest zwykle używana do zapewniania tych możliwości:

  • Bezpośredni interfejs API REST dla aplikacji logiki, którą inni mogą wywołać

    Na przykład użyj wyzwalacza Żądania, aby uruchomić aplikację logiki, aby inne aplikacje logiki mogły wywołać wyzwalacz przy użyciu akcji Wywołaj przepływ pracy — Logic Apps .

  • Mechanizm elementu webhook lub wywołania zwrotnego dla aplikacji logiki

  • Sposób ręcznego uruchamiania operacji użytkownika lub procedur w celu wywołania aplikacji logiki, na przykład przy użyciu skryptu programu PowerShell wykonującego określone zadanie

Z perspektywy odzyskiwania po awarii wyzwalacz żądania jest pasywnym odbiornikiem, ponieważ aplikacja logiki nie wykonuje żadnej pracy i czeka, aż jakaś inna usługa lub system jawnie wywoła wyzwalacz. Jako pasywny punkt końcowy można skonfigurować wystąpienia podstawowe i pomocnicze w następujący sposób:

  • Aktywny-aktywny: Oba wystąpienia aktywnie obsługują żądania lub wywołania. Obiekt wywołujący lub router równoważy lub dystrybuuje ruch między tymi wystąpieniami.

  • Aktywne-pasywne: tylko wystąpienie podstawowe jest aktywne i obsługuje całą pracę, podczas gdy wystąpienie pomocnicze czeka na zakłócenia lub awarie podstawowego środowiska. Obiekt wywołujący lub router określa, kiedy wywołać wystąpienie pomocnicze.

Zalecana architektura umożliwia korzystanie z usługi Azure API Management jako serwera proxy dla aplikacji logiki korzystających z wyzwalaczy żądania. API Management zapewnia wbudowaną odporność między regionami i możliwość kierowania ruchu między wieloma punktami końcowymi.

Wyzwalacz elementu webhook

Wyzwalacz elementu webhook umożliwia aplikacji logiki subskrybowanie usługi przez przekazanie adresu URL wywołania zwrotnego do tej usługi. Aplikacja logiki może następnie nasłuchiwać określonego zdarzenia i czekać na to zdarzenie w tym punkcie końcowym usługi. Po wystąpieniu zdarzenia usługa wywołuje wyzwalacz elementu webhook przy użyciu adresu URL wywołania zwrotnego, który następnie uruchamia aplikację logiki. Po włączeniu wyzwalacz elementu webhook subskrybuje usługę. Po wyłączeniu wyzwalacz anuluje subskrypcję usługi.

Z perspektywy odzyskiwania po awarii skonfiguruj wystąpienia podstawowe i pomocnicze, które używają wyzwalaczy elementu webhook do odtwarzania aktywnych-pasywnych ról, ponieważ tylko jedno wystąpienie powinno odbierać zdarzenia lub komunikaty z subskrybowanego punktu końcowego.

Ocena kondycji wystąpienia podstawowego

Aby strategia odzyskiwania po awarii działała, rozwiązanie wymaga sposobów wykonywania następujących zadań:

W tej sekcji opisano jedno rozwiązanie, którego można użyć wprost lub jako podstawy dla własnego projektu. Oto ogólne omówienie wizualizacji dla tego rozwiązania:

Tworzenie aplikacji logiki watchdog, która monitoruje aplikację logiki sprawdzania kondycji w lokalizacji podstawowej

Sprawdzanie dostępności wystąpienia podstawowego

Aby określić, czy wystąpienie podstawowe jest dostępne, uruchomione i może działać, możesz utworzyć aplikację logiki "health-check", która znajduje się w tej samej lokalizacji co wystąpienie podstawowe. Następnie możesz wywołać tę aplikację sprawdzania kondycji z lokalizacji alternatywnej. Jeśli aplikacja sprawdzania kondycji pomyślnie odpowie, podstawowa infrastruktura usługi Azure Logic Apps w tym regionie jest dostępna i działa. Jeśli aplikacja sprawdzania kondycji nie odpowie, możesz założyć, że lokalizacja nie jest już w dobrej kondycji.

W tym zadaniu utwórz podstawową aplikację logiki sprawdzania kondycji, która wykonuje następujące zadania:

  1. Odbiera wywołanie z aplikacji watchdog przy użyciu wyzwalacza Żądanie.

  2. Odpowiedz ze stanem wskazującym, czy sprawdzona aplikacja logiki nadal działa przy użyciu akcji Odpowiedź.

    Ważne

    Aplikacja logiki sprawdzania kondycji musi używać akcji Odpowiedź, aby aplikacja odpowiadała synchronicznie, a nie asynchronicznie.

  3. Opcjonalnie, aby dodatkowo określić, czy lokalizacja podstawowa jest w dobrej kondycji, można uwzględnić kondycję innych usług, które wchodzą w interakcję z docelową aplikacją logiki w tej lokalizacji. Po prostu rozwiń aplikację logiki sprawdzania kondycji, aby ocenić kondycję tych innych usług.

Tworzenie aplikacji logiki watchdog

Aby monitorować kondycję wystąpienia podstawowego i wywoływać aplikację logiki sprawdzania kondycji, utwórz aplikację logiki "watchdog" w alternatywnej lokalizacji. Możesz na przykład skonfigurować aplikację logiki watchdog, aby w przypadku niepowodzenia wywołania logiki sprawdzania kondycji usługa Watchdog mogła wysłać alert do zespołu operacji, aby mogli zbadać błąd i dlaczego wystąpienie podstawowe nie odpowiada.

Ważne

Upewnij się, że aplikacja logiki watchdog znajduje się w lokalizacji, która różni się od lokalizacji podstawowej. Jeśli usługa Azure Logic Apps w lokalizacji podstawowej napotka problemy, przepływ pracy aplikacji logiki watchdog może nie zostać uruchomiony.

W przypadku tego zadania w lokalizacji pomocniczej utwórz aplikację logiki watchdog, która wykonuje następujące zadania:

  1. Uruchom polecenie na podstawie stałego lub zaplanowanego cyklu przy użyciu wyzwalacza cyklu.

    Cykl można ustawić na wartość poniżej poziomu tolerancji celu czasu odzyskiwania (RTO).

  2. Wywołaj przepływ pracy aplikacji logiki sprawdzania kondycji w lokalizacji podstawowej przy użyciu akcji HTTP.

Możesz również utworzyć bardziej zaawansowaną aplikację logiki watchdog, która po wielu awariach wywołuje inną aplikację logiki, która automatycznie obsługuje przełączanie do lokalizacji pomocniczej, gdy podstawowa awaria zakończy się niepowodzeniem.

Aktywowanie wystąpienia pomocniczego

Aby automatycznie aktywować wystąpienie pomocnicze, możesz utworzyć aplikację logiki, która wywołuje interfejs API zarządzania, taki jak łącznik azure Resource Manager, aby aktywować odpowiednie aplikacje logiki w lokalizacji pomocniczej. Możesz rozszerzyć aplikację watchdog, aby wywołać tę aplikację logiki aktywacji po wystąpieniu określonej liczby awarii.

Nadmiarowość strefy ze strefami dostępności

W każdym regionie świadczenia usługi Azure strefy dostępności są fizycznie oddzielnymi lokalizacjami, które są odporne na awarie lokalne. Takie awarie mogą wahać się od awarii oprogramowania i sprzętu do zdarzeń, takich jak trzęsienia ziemi, powodzie i pożary. Te strefy osiągają tolerancję dzięki nadmiarowości i logicznej izolacji usług platformy Azure.

Aby zapewnić odporność i dostępność rozproszoną, co najmniej trzy oddzielne strefy dostępności istnieją w dowolnym regionie świadczenia usługi Azure, który obsługuje i włącza nadmiarowość strefy. Platforma Azure Logic Apps dystrybuuje te strefy i obciążenia aplikacji logiki w tych strefach. Ta funkcja jest kluczowym wymaganiem dotyczącym włączania odpornych architektur i zapewnienia wysokiej dostępności w przypadku awarii centrum danych w regionie.

Obecnie ta funkcja jest dostępna w wersji zapoznawczej i dostępna dla nowych aplikacji logiki Zużycie w określonych regionach. Aby uzyskać więcej informacji, zobacz następującą dokumentację:

Zbieranie danych diagnostycznych

Możesz skonfigurować rejestrowanie dla przebiegów aplikacji logiki i wysłać wynikowe dane diagnostyczne do usług takich jak Azure Storage, Azure Event Hubs i Azure Log Analytics w celu dalszej obsługi i przetwarzania.

Następne kroki