Udostępnij za pomocą

Niezawodne przetwarzanie zdarzeń za pomocą usług Azure Functions i Event Hubs

Dowiedz się, jak tworzyć niezawodne, niezawodne rozwiązania bezserwerowe przy użyciu usługi Azure Functions z wyzwalaczami usługi Azure Event Hubs. W tym artykule opisano najlepsze praktyki dotyczące punktów kontrolnych, obsługi błędów i wdrażania wzorców zabezpieczeń przeciążeniowych, aby zapewnić, że żadne zdarzenia nie zostaną utracone, a aplikacje oparte na zdarzeniach pozostaną stabilne i odporne.

Wyzwania związane ze strumieniami zdarzeń w systemach rozproszonych

Rozważ system, który wysyła zdarzenia z stałą szybkością 100 zdarzeń na sekundę. W tym tempie w ciągu kilku minut wiele równoległych instancji może przetwarzać przychodzące co sekundę 100 zdarzeń.

Należy jednak wziąć pod uwagę te wyzwania związane z przetwarzaniem strumienia zdarzeń.

  • Wydawca zdarzeń wysyła uszkodzone zdarzenie.
  • Kod funkcji napotka nieobsługiwany wyjątek.
  • System podrzędny przechodzi w tryb offline i blokuje przetwarzanie zdarzeń.

W przeciwieństwie do wyzwalacza usługi Azure Queue Storage, który blokuje komunikaty podczas przetwarzania, usługa Azure Event Hubs odczytuje dane na partycję z jednego punktu w strumieniu. To zachowanie odczytu, które jest bardziej podobne do odtwarzacza wideo, zapewnia pożądane korzyści z wysokiej przepływności, wielu grup odbiorców i możliwości odtwarzania. Zdarzenia są odczytywane z punktu kontrolnego, do przodu lub do tyłu, ale należy przenieść wskaźnik, aby przetworzyć nowe zdarzenia. Aby uzyskać więcej informacji, zobacz Punkt kontrolny w dokumentacji usługi Event Hubs.

W przypadku wystąpienia błędów w strumieniu i wybraniu braku postępu wskaźnika dalsze przetwarzanie zdarzeń jest blokowane. Innymi słowy, jeśli zatrzymasz wskaźnik, aby rozwiązać problem w trakcie przetwarzania pojedynczego zdarzenia, nieprzetworzone zdarzenia zaczynają się kumulować.

Funkcja unika zakleszczenia, zawsze przesuwając wskaźnik strumienia, niezależnie od powodzenia lub niepowodzenia. Ze względu na to, że wskaźnik ciągle się przesuwa, funkcje muszą odpowiednio radzić sobie z błędami.

Jak wyzwalacz usługi Event Hubs zużywa zdarzenia

Usługa Azure Functions pobiera zdarzenia z centrum zdarzeń, przechodząc przez następujące kroki:

  1. Wskaźnik jest tworzony i utrwalany w usłudze Azure Storage dla każdej partycji centrum zdarzeń.
  2. Nowe zdarzenia są odbierane w partii (domyślnie), a host próbuje wyzwolić funkcję dostarczającą partię zdarzeń do przetwarzania.
  3. Po zakończeniu wykonywania funkcji z wyjątkami lub bez wyjątków wskaźnik jest zaawansowany i punkt kontrolny jest zapisywany na domyślnym koncie magazynu hosta.
  4. Jeśli warunki uniemożliwiają ukończenie wykonywania funkcji, host nie może przesunąć wskaźnika. Gdy wskaźnik nie może przejść, kolejne wykonania ponownie przetwarzają te same zdarzenia.

To zachowanie ujawnia kilka ważnych kwestii:

  • Nieobsługiwane wyjątki mogą spowodować utratę zdarzeń:

    Wykonania funkcji, które zgłaszają wyjątek, powodują przesunięcie wskaźnika do przodu. Ustawienie polityki ponawiania lub innej logiki ponawiania opóźnia przesunięcie wskaźnika do momentu zakończenia całego ponawiania.

  • Funkcje gwarantują co najmniej jednokrotne dostarczanie:

    W kodzie i systemach zależnych może być konieczne uwzględnienie faktu, że to samo zdarzenie może być przetwarzane dwa razy. Aby uzyskać więcej informacji, zobacz Projektowanie usługi Azure Functions pod kątem identycznych danych wejściowych.

Obsługa wyjątków

Chociaż kod każdej funkcji powinien zawierać blok try/catch na najwyższym poziomie kodu, to posiadanie takiego bloku jest jeszcze ważniejsze w przypadku funkcji korzystających ze zdarzeń usługi Event Hubs. W ten sposób, gdy zostanie zgłoszony wyjątek, blok przechwytujący obsługuje błąd, zanim wskaźnik zostanie przesunięty.

Mechanizmy i zasady ponawiania prób

Ponieważ wiele wyjątków w chmurze jest przejściowych, pierwszym krokiem obsługi błędów jest zawsze ponawianie próby wykonania operacji. Możesz zastosować wbudowane zasady ponawiania prób lub zdefiniować własną logikę ponawiania prób.

Zasady ponawiania prób

Usługa Functions udostępnia wbudowane zasady ponawiania prób dla usługi Event Hubs. W przypadku korzystania z zasad ponawiania po prostu zgłaszasz nowy wyjątek, a host spróbuje ponownie przetworzyć zdarzenie na podstawie zdefiniowanych zasad. To zachowanie ponawiania prób wymaga wersji 5.x lub nowszej rozszerzenia usługi Event Hubs. Aby uzyskać więcej informacji, zobacz Zasady ponawiania prób.

Niestandardowa logika ponawiania prób

Możesz również zdefiniować własną logikę ponawiania prób w samej funkcji. Można na przykład zaimplementować zasady, które są zgodne z przepływem pracy zilustrowanym przez następujące reguły:

  • Spróbuj przetworzyć zdarzenie trzy razy (potencjalnie z opóźnieniem między ponownymi próbami).
  • Jeśli ostatecznym wynikiem wszystkich ponownych prób jest niepowodzenie, dodaj zdarzenie do kolejki, aby przetwarzanie mogło być kontynuowane w strumieniu.
  • Uszkodzone lub nieprzetworzone zdarzenia są następnie obsługiwane później.

Uwaga / Notatka

Polly to przykład odporności i biblioteki obsługi błędów przejściowych dla aplikacji języka C#.

Błędy niebędące wyjątkami

Niektóre problemy mogą wystąpić bez zgłaszania wyjątku. Rozważmy na przykład przypadek, w którym żądanie ulega przekroczeniu limitu czasu lub wystąpienie uruchamiające funkcję ulega awarii. Gdy wykonanie funkcji nie powiedzie się bez wyjątku, wskaźnik przesunięcia nigdy nie jest zaawansowany. Jeśli wskaźnik nie przesuwa się, każde wystąpienie, które działa po nieudanym wykonaniu, nadal będzie odczytywać te same zdarzenia. Ta sytuacja zapewnia gwarancję co najmniej raz.

Zapewnienie, że każde zdarzenie jest przetwarzane co najmniej raz, oznacza, że niektóre zdarzenia mogą być przetwarzane więcej niż raz. Aplikacje funkcji powinny uwzględniać tę możliwość i być tworzone wokół zasad idempotentności.

Obsługa stanów awarii

Aplikacja może być w stanie obsłużyć kilka błędów w przetwarzaniu zdarzeń w sposób akceptowalny. Należy jednak przygotować się również do obsługi trwałego stanu awarii, który może wystąpić w wyniku awarii w przetwarzaniu podrzędnym. W takim stanie awarii, jak na przykład wtedy, gdy podrzędny magazyn danych jest offline, funkcja powinna przestać reagować na zdarzenia, dopóki system nie osiągnie zdrowego stanu.

Wzorzec wyłącznika

Podczas implementowania wzorca wyłącznika aplikacja może skutecznie wstrzymać przetwarzanie zdarzeń, a następnie wznowić je później po rozwiązaniu problemów.

Istnieją dwa składniki wymagane do zaimplementowania wyłącznika w procesie strumienia zdarzeń:

  • Wspólny stan we wszystkich instancjach do śledzenia i monitorowania kondycji obwodu.
  • Podstawowy proces, który może zarządzać stanem obwodu jako open lub closed.

Szczegóły implementacji mogą się różnić, ale aby współużytkować stan między wystąpieniami, potrzebny jest mechanizm przechowywania. Stan można przechowywać w usłudze Azure Storage, pamięci podręcznej Redis lub dowolnej innej trwałej usłudze, do której można uzyskać dostęp za pomocą wystąpień aplikacji funkcji.

Zarówno Durable Functions, jak i Azure Logic Apps zapewniają infrastrukturę do zarządzania przepływami pracy i stanami obwodu. W tym artykule opisano, jak za pomocą usługi Logic Apps wstrzymać i ponownie uruchomić wykonywanie funkcji, zapewniając kontrolę wymaganą do zaimplementowania wzorca wyłącznika.

Definiowanie progu awarii między wystąpieniami

Trwały wspólny stan zewnętrzny jest wymagany do monitorowania stanu zdrowia obwodu, gdy wiele instancji przetwarza zdarzenia jednocześnie. Następnie można monitorować ten stan utrwalony na podstawie reguł określających stan awarii, na przykład:

Jeśli w ciągu 30 sekund we wszystkich instancjach występuje więcej niż 100 niepowodzeń zdarzeń, otwórz obwód, aby zahamować wyzwalanie nowych zdarzeń.

Szczegóły implementacji tej logiki monitorowania różnią się w zależności od potrzeb określonych aplikacji, ale ogólnie należy utworzyć system, który:

  1. Rejestruje awarie do trwałej pamięci.
  2. Sprawdź liczbę kroczącą, gdy są rejestrowane nowe błędy, aby określić, czy próg niepowodzenia zdarzenia jest spełniony.
  3. Po osiągnięciu tego progu emituj zdarzenie informujące system o przerwaniu obwodu.

Zarządzanie stanem obwodu za pomocą usługi Azure Logic Apps

Usługa Azure Logic Apps zawiera wbudowane łączniki do różnych usług, funkcji i orkiestracji stanowych. Jest to naturalny wybór do zarządzania stanem obwodu. Po wykryciu konieczności przerwania obwodu, możesz utworzyć logiczną aplikację w celu wdrożenia tego przepływu pracy.

  1. Wyzwalanie przepływu pracy usługi Event Grid, który zatrzymuje przetwarzanie funkcji.
  2. Wyślij wiadomość e-mail z powiadomieniem, która zawiera opcję ponownego uruchomienia przepływu pracy.

Aby dowiedzieć się, jak wyłączyć i ponownie włączyć określone funkcje przy użyciu ustawień aplikacji, zobacz Jak wyłączyć funkcje w usłudze Azure Functions.

Adresat wiadomości e-mail może zbadać kondycję obwodu i, w razie potrzeby, ponownie uruchomić obwód za pośrednictwem linku w wiadomości e-mail z powiadomieniem. Gdy przepływ pracy ponownie uruchamia funkcję, zdarzenia są przetwarzane z ostatniego punktu kontrolnego Event Hub.

W przypadku korzystania z tego podejścia żadne zdarzenia nie są tracone, zdarzenia są przetwarzane w kolejności i można przerwać obwód na dowolnie długi czas, zgodnie z potrzebą.

Strategie migracji wyzwalaczy Event Grid

Podczas migracji istniejącej aplikacji funkcji między regionami lub między niektórymi planami należy ponownie utworzyć aplikację podczas procesu migracji. W takim przypadku podczas procesu migracji mogą istnieć dwie aplikacje, które mogą korzystać z tego samego strumienia zdarzeń i zapisywać je w tym samym miejscu docelowym danych wyjściowych.

Należy rozważyć użycie grup odbiorców , aby uniknąć utraty lub duplikowania danych zdarzeń podczas procesu migracji:

  1. Utwórz nową grupę odbiorców dla nowej aplikacji docelowej.

  2. Skonfiguruj wyzwalacz w nowej aplikacji, aby używać tej nowej grupy odbiorców.

    Dzięki temu obie aplikacje mogą przetwarzać zdarzenia niezależnie podczas walidacji.

  3. Sprawdź, czy nowa aplikacja prawidłowo przetwarza zdarzenia.

  4. Zatrzymaj oryginalną aplikację lub usuń jej subskrypcję/grupę odbiorców.

  • Last updated on