Udostępnij za pośrednictwem

Wdrożenia w wielu regionach na potrzeby odzyskiwania po awarii w usłudze Azure Logic Apps

  • Artykuł

Ten artykuł zawiera wskazówki i strategie konfigurowania wdrożenia w wielu regionach dla przepływów pracy aplikacji logiki w usłudze Azure Logic Apps. Wdrożenie obejmujące wiele regionów pomaga chronić dane, szybko odzyskiwać dane po awariach i innych zdarzeniach zakłócających działanie, przywracać zasoby wymagane przez krytyczne funkcje biznesowe i utrzymywać ciągłość działania.

Aby uzyskać więcej informacji na temat funkcji niezawodności w usłudze Azure Logic Apps, w tym odporności wewnątrz regionalnej za pośrednictwem stref dostępności, zobacz Niezawodność w usłudze Azure Logic Apps.

Kwestie wymagające rozważenia

Przepływy pracy aplikacji logiki ułatwiają integrowanie i organizowanie danych między aplikacjami, usługami w chmurze i systemami lokalnymi dzięki zmniejszeniu ilości kodu, który trzeba napisać. Podczas planowania nadmiarowości w wielu regionach upewnij się, że rozważasz nie tylko aplikacje logiki, ale także te zasoby platformy Azure używane z aplikacjami logiki:

Aby uzyskać więcej informacji na temat niezawodności w usłudze Azure Logic Apps, w tym odporności wewnątrz regionów za pośrednictwem stref dostępności i wdrożeń w wielu regionach, zobacz Niezawodność w usłudze Azure Logic Apps.

Wdrożenie podstawowe i pomocnicze

Wdrożenie obejmujące wiele regionów składa się z podstawowej i pomocniczej aplikacji logiki. Podstawowa aplikacja logiki jest skonfigurowana do przełączania w tryb failover do pomocniczej aplikacji logiki w innym regionie, w którym jest również dostępna usługa Azure Logic Apps. W ten sposób, jeśli podstawowy poniesie straty, zakłócenia lub awarie, pomocnicza może przejąć pracę. Ta strategia wdrażania wymaga, aby pomocnicza aplikacja logiki i zasoby zależne zostały już wdrożone i gotowe w regionie pomocniczym.

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 konto integracji, jak i aplikacje logiki muszą używać tej samej lokalizacji.

Jeśli zastosujesz dobre rozwiązania devOps, do definiowania i wdrażania aplikacji logiki i ich zasobów zależnych używasz już szablonów Bicep lub Azure Resource Manager. Szablony Bicep i 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 możliwość oznacza, że można wdrożyć tę samą aplikację logiki w różnych środowiskach, na przykład programowanie, testowanie i produkcja. Tę samą aplikację logiki można również wdrożyć w różnych regionach świadczenia usługi Azure, które obsługują wdrożenia w wielu regionach, na przykład w przypadku strategii odzyskiwania po awarii.

Aby przejście w tryb failover powiodło się, 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. Dlatego oba wystąpienia są wdrażane w regionach w globalnej wielodostępnej usłudze Azure Logic Apps lub regionach w usłudze Azure Logic Apps z jedną dzierżawą. Aby uzyskać najlepsze rozwiązania i więcej informacji na temat używania wielu regionów na potrzeby ciągłości działania i odzyskiwania po awarii (BC/DR), zobacz Replikacja między regionami na platformie Azure: ciągłość działania i odzyskiwanie po awarii.

Przykład: wielodostępna platforma Azure

W tym przykładzie przedstawiono wystąpienia podstawowej i pomocniczej aplikacji logiki, które są wdrażane w oddzielnych regionach na globalnej wielodostępnej platformie Azure. Pojedynczy szablon usługi 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

Połączenia z zasobami

Usługa Azure Logic Apps udostępnia operacje dla ponad 1000 łączników , 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, bazy danych programu SQL Server, 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 to oddzielny zasób platformy Azure, który istnieje w określonej lokalizacji i nie może być używany przez zasoby w innych lokalizacjach.

W przypadku strategii nadmiarowości w wielu regionach należy wziąć pod uwagę 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. Zazwyczaj 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 w regionie pomocniczym.

  • 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 zreplikowane 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 z usługą 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 należy użyć replikowanej lub zapasowej bazy danych w regionie pomocniczym, a także oddzielnego połączenia z tą bazą danych, która znajduje się również w regionie pomocniczym.

Lokalne bramy danych

Jeśli aplikacja logiki działa na wielodostępnej platformie Azure i potrzebuje dostępu do zasobów lokalnych, takich jak bazy danych programu SQL Server, musisz zainstalować lokalną bramę danych na komputerze lokalnym. Następnie możesz utworzyć zasób bramy danych w witrynie 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 nadmiarowości w wielu regionach upewnij się, że brama danych pozostaje dostępna do użycia przez aplikację logiki. Wysoką dostępność bramy można włączyć, jeśli masz wiele instalacji bramy.

Role aktywne-aktywne a 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
Aktywne-aktywne Wystąpienia podstawowej i pomocniczej aplikacji logiki w obu lokalizacjach aktywnie obsługują żądania, postępując zgodnie z jednym 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 odbiorcy: oba wystąpienia mogą działać jako konkurujący odbiorcy, aby wystąpienia rywalizowały o komunikaty z kolejki. Jeśli jedno wystąpienie ulegnie awarii, drugie wystąpienie przejmuje obciążenie.
Aktywny-pasywny Wystąpienie podstawowej aplikacji logiki aktywnie obsługuje całe obciążenie, a wystąpienie pomocnicze jest pasywne (wyłączone lub nieaktywne). Pomocniczy 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.
Kombinacja Niektóre aplikacje logiki odgrywają rolę aktywne-aktywne, a inne aplikacje logiki odgrywają rolę aktywne-pasywne.

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:

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

  • "miękki" moduł równoważenia obciążenia, taki jak usługa Azure Load Balancer lub usługa Azure API Management. Za pomocą usługi 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 usługi Azure Service Bus.

    Chociaż w tym przykładzie przedstawiono głównie usługę Azure Load Balancer, możesz użyć opcji, która najlepiej odpowiada potrzebom scenariusza:

    Konfiguracja

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

    Konfiguracja

Przykłady aktywne-pasywne

W tym przykładzie pokazano konfigurację aktywne-pasywne, w której główne wystąpienie aplikacji logiki jest aktywne w jednej lokalizacji, a wystąpienie pomocnicze pozostaje nieaktywne w innej lokalizacji. Jeśli w przypadku wystąpienia zakłóceń lub awarii, operator może uruchomić skrypt, który aktywuje pomocniczą, aby przejąć obciążenie.

Konfiguracja

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

W tym przykładzie pokazano połączoną konfigurację, w której lokalizacja podstawowa ma zarówno aktywne wystąpienia aplikacji logiki, jak i wystąpienie 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 usługi Azure Service Bus dla komunikatów, podczas gdy inna aktywna aplikacja logiki sprawdza wiadomości e-mail przy użyciu wyzwalacza sondowania usługi Office 365 Outlook.

  • W lokalizacji pomocniczej aktywna aplikacja logiki współpracuje z aplikacją logiki w lokalizacji podstawowej, słuchając i konkurując o komunikaty z tej samej kolejki usługi Service Bus. W międzyczasie 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. Po skonfigurowaniu lokalizacji podstawowej i pomocniczej 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:

  • Stały 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 usługi Azure Service Bus. Podczas dzielenia procesu na mniejsze etapy zmniejsza się liczbę procesów biznesowych, które mogą zostać zablokowane w wystąpieniu aplikacji logiki, które zakończyły 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 pokazano 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.

    Podziel proces biznesowy na etapy reprezentowane przez aplikacje logiki, które komunikują się ze sobą przy użyciu kolejek usługi Azure Service Bus

    Jeśli zarówno podstawowe, jak i pomocnicze wystąpienia aplikacji logiki są zgodne z tym samym wzorcem poślizgu routingu w ich lokalizacjach, możesz zaimplementować wzorzec konkurujących odbiorców, konfigurując role aktywne-aktywne dla tych wystąpień.

  • Wzorzec menedżera procesów (brokera)

  • Podgląd blokady bez wzorca przekroczenia limitu czasu

Dostęp do historii wyzwalaczy i przebiegów

Aby uzyskać więcej informacji na temat poprzednich wykonań przepływu pracy aplikacji logiki, możesz przejrzeć wyzwalacz i historię przebiegów 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 przebiegów w odpowiednich lokalizacjach, w których uruchomiono te wystąpienia. Można 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 typu wyzwalacza

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 przepływach pracy aplikacji 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 innych kryteriów, na przykład:

  • Stała częstotliwość i interwał, taki jak 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 Cykl, musisz skonfigurować wystąpienia podstawowej i pomocniczej aplikacji logiki z rolami aktywny-pasywny. Aby skrócić cel czasu odzyskiwania (RTO), który odnosi się do docelowego czasu trwania przywracania procesu biznesowego po przerwie lub awarii, możesz skonfigurować wystąpienia aplikacji logiki z kombinacją ról aktywne-pasywne i role pasywne-aktywne. 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 włączonej aplikacji logiki ustaw wyzwalacz Cykl, aby rozpoczynał się w górnej części godziny i powtarzał się co 20 minut, na przykład 9:00, 9:20 itd.

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

  • W lokalizacji pomocniczej skonfiguruj pasywne aktywne 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 itd.

    • W przypadku aktywnej włączonej aplikacji logiki ustaw wyzwalacz Cykl na taki sam harmonogram jak pasywna aplikacja logiki w lokalizacji podstawowej, która ma zaczynać się od 10 minut po godzinie i powtarzać co 20 minut, na przykład 9:10, 9:20 i tak dalej.

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

Wyzwalacz sondowania

Aby regularnie sprawdzać, czy nowe dane do przetwarzania są dostępne z określonej usługi lub punktu końcowego, 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 współpracujące ze stanem po stronie klienta używają wyzwalaczy, które mogą obsługiwać stan.

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

  • Aplikacje logiki współpracujące 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 FALSEwartość . Za każdym razem, gdy wyzwalacz odczytuje wiersz, aplikacja logiki aktualizuje ten wiersz, zmieniając kolumnę isRead z FALSE na TRUE.

    To 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 punktu widzenia odzyskiwania po awarii podczas konfigurowania podstawowych i pomocniczych wystąpień 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 działa 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 ulegnie awarii w lokalizacji alternatywnej.

    Na przykład wyzwalacz usługi Office 365 Outlook zachowuje stan po stronie klienta i śledzi sygnaturę czasową ostatnio odczytywanej 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 odbiorcy lub role aktywne-pasywne, w których wystąpienie alternatywne czeka, aż wystąpienie podstawowe ulegnie awarii do lokalizacji alternatywnej.

    Na przykład odczyt z kolejki komunikatów, taki jak kolejka usługi Azure Service Bus, używa stanu po stronie serwera, ponieważ usługa kolejkowania utrzymuje 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 aktywny-pasywny.

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óry inni mogą wywoływać

    Na przykład użyj wyzwalacza Żądania, aby uruchomić aplikację logiki, aby inne aplikacje logiki mogły wywoływać 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 odbiornikiem pasywnym, ponieważ aplikacja logiki nie wykonuje żadnej pracy i czeka, aż 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.

  • Aktywny-pasywny: tylko wystąpienie podstawowe jest aktywne i obsługuje całą pracę, podczas gdy wystąpienie pomocnicze czeka do momentu wystąpienia podstawowego zakłóceń lub awarii. Obiekt wywołujący lub router określa, kiedy wywołać wystąpienie pomocnicze.

Zalecana architektura umożliwia używanie usługi Azure API Management jako serwera proxy dla aplikacji logiki korzystających z wyzwalaczy żądania. Usługa 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ć i czekać, aż określone zdarzenie stanie się 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 ról aktywny-pasywny, ponieważ tylko jedno wystąpienie powinno odbierać zdarzenia lub komunikaty z subskrybowanego punktu końcowego.

Ocena kondycji wystąpienia podstawowego

Aby strategia trybu failover w wielu regionach działała, rozwiązanie wymaga sposobów wykonywania tych 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 "kontrola kondycji", która znajduje się w tej samej lokalizacji co wystąpienie podstawowe. Następnie możesz wywołać tę aplikację do sprawdzania kondycji z lokalizacji alternatywnej. Jeśli aplikacja do sprawdzania kondycji pomyślnie odpowie, podstawowa infrastruktura usługi Azure Logic Apps w tym regionie jest dostępna i działa. Jeśli aplikacja do 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żesz 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żna na przykład skonfigurować aplikację logiki watchdog tak, aby w przypadku wywołania logiki sprawdzania kondycji usługa watchdog mogła wysłać alert do zespołu operacyjnego, aby mógł 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 tym zadaniu 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 Cykl.

    Możesz ustawić cykl na wartość poniżej poziomu tolerancji dla 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 się do lokalizacji pomocniczej, gdy awaria podstawowa 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 usługi Azure Resource Manager, aby aktywować odpowiednie aplikacje logiki w lokalizacji pomocniczej. Możesz rozwinąć aplikację watchdog, aby wywołać tę aplikację logiki aktywacji po wystąpieniu określonej liczby błędów.

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