Integrowanie usługi Event Hubs z funkcjami bezserwerowymi na platformie Azure

Azure Event Hubs

Azure Functions

Azure Monitor

Rozwiązania korzystające z usługi Azure Event Hubs wraz z usługą Azure Functions korzystają z architektury bezserwerowej , która jest skalowalna, ekonomiczna i może przetwarzać duże ilości danych niemal w czasie rzeczywistym. Chociaż te usługi są często używane razem, istnieje wiele funkcji, ustawień i zawiłości, które dodają złożoność ich relacji. Ten artykuł zawiera wskazówki dotyczące efektywnego korzystania z tej integracji przez wyróżnienie kluczowych zagadnień i technik dotyczących wydajności, odporności, zabezpieczeń, możliwości obserwowania i skalowania.

Podstawowe pojęcia dotyczące usługi Event Hubs

Azure Event Hubs to wysoce skalowalna usługa przetwarzania zdarzeń, która może odbierać miliony zdarzeń na sekundę. Przed zapoznaniem się ze wzorcami i najlepszymi rozwiązaniami dotyczącymi integracji usługi Azure Functions najlepiej zrozumieć podstawowe składniki usługi Event Hubs.

Na poniższym diagramie przedstawiono architekturę przetwarzania strumienia usługi Event Hubs:

Zdarzenia

Zdarzenie to zmiana powiadomienia lub stanu, która jest reprezentowana jako fakt, który wystąpił w przeszłości. Zdarzenia są niezmienne i utrwalane w centrum zdarzeń, nazywane również tematemna platformie Kafka. Centrum zdarzeń składa się z co najmniej jednej partycji.

Partycje

Gdy partycja nie jest określona przez nadawcę, odebrane zdarzenia są dystrybuowane między partycjami w centrum zdarzeń. Każde zdarzenie jest zapisywane w dokładnie jednej partycji i nie jest rzutowanie wielowymiarowe między partycjami. Każda partycja działa jako dziennik, w którym rekordy są zapisywane we wzorcu tylko do dołączania. Analogia dziennika zatwierdzeń jest często używana do opisywania charakteru dodawania zdarzeń na końcu sekwencji w partycji.

Gdy jest używana więcej niż jedna partycja, umożliwia używanie dzienników równoległych z tego samego centrum zdarzeń. To zachowanie zapewnia wiele stopni równoległości i zwiększa przepływność dla użytkowników.

Konsumenci i grupy konsumentów

Partycja może być zużywana przez więcej niż jednego konsumenta, każdy odczyt z własnych przesunięć i zarządzanie nimi.

Usługa Event Hubs ma koncepcję grup odbiorców, która umożliwia wielu aplikacjom zużywających wiele aplikacji do każdego z nich ma oddzielny widok strumienia zdarzeń i odczytuje strumień niezależnie we własnym tempie i z własnymi przesunięciami.

Aby dowiedzieć się więcej, zobacz Szczegółowe omówienie pojęć i funkcji usługi Event Hubs.

Korzystanie ze zdarzeń za pomocą usługi Azure Functions

Usługa Azure Functions obsługuje powiązania wyzwalacza i wyjściowe dla usługi Event Hubs. W tej sekcji opisano, jak usługa Azure Functions reaguje na zdarzenia wysyłane do strumienia zdarzeń centrum zdarzeń przy użyciu wyzwalaczy.

Każde wystąpienie wyzwalanej funkcji usługi Event Hubs jest wspierane przez pojedyncze wystąpienie klasy EventProcessorHost . Wyzwalacz (obsługiwany przez usługę Event Hubs) gwarantuje, że tylko jedno wystąpienie klasy EventProcessorHost może uzyskać dzierżawę dla danej partycji.

Rozważmy na przykład centrum zdarzeń o następujących cechach:

• 10 partycji.
• 1000 zdarzeń rozproszonych we wszystkich partycjach z różną liczbą komunikatów w każdej partycji.

Gdy funkcja jest najpierw włączona, istnieje tylko jedno wystąpienie funkcji. Wywołajmy pierwsze wystąpienie Function_1funkcji . Function_1 ma jedno wystąpienie klasy EventProcessorHost , które przechowuje dzierżawę na wszystkich 10 partycjach. To wystąpienie odczytuje zdarzenia z partycji 1–10. Od tego momentu następuje jedna z następujących czynności:

• Nowe wystąpienia funkcji nie są potrzebne: Function_1 może przetworzyć wszystkie 1000 zdarzeń przed zastosowaniem logiki skalowania funkcji. W takim przypadku wszystkie 1000 komunikatów są przetwarzane przez Function_1program .

  

• Dodano dodatkowe wystąpienie funkcji: skalowanie oparte na zdarzeniach lub inna automatyczna lub ręczna logika może określić, że Function_1 ma więcej komunikatów niż może przetworzyć, a następnie utworzy nowe wystąpienie aplikacji funkcji (Function_2). Ta nowa funkcja ma również skojarzone wystąpienie klasy EventProcessorHost. Ponieważ bazowe centrum zdarzeń wykrywa, że nowe wystąpienie hosta próbuje odczytać komunikaty, równoważy obciążenia partycji w wystąpieniach hosta. Na przykład partycje 1–5 mogą być przypisane do Function_1 partycji i partycje 6–10 do Function_2.

  

• Dodano n więcej wystąpień funkcji: skalowanie oparte na zdarzeniach lub inna automatyczna lub ręczna logika określa, że oba Function_1 i Function_2 mają więcej komunikatów niż mogą przetwarzać, tworzone są nowe wystąpienia aplikacji funkcji Function_N. Wystąpienia są tworzone do punktu, w którym N jest równe lub większe niż liczba partycji centrum zdarzeń. W naszym przykładzie usługa Event Hubs ponownie równoważy obciążenie partycji, w tym przypadku między wystąpieniami Function_1...Function_10.

  

W miarę skalowania n wystąpień może być liczbą większą niż liczba partycji centrum zdarzeń. Taka sytuacja może wystąpić, gdy skalowanie sterowane zdarzeniami stabilizuje liczbę wystąpień lub dlatego, że inna automatyczna lub ręczna logika utworzyła więcej wystąpień niż partycje. W takim przypadku wystąpienia klasy EventProcessorHost będą uzyskiwać blokady tylko na partycjach, ponieważ staną się dostępne z innych wystąpień, ponieważ w danym momencie tylko jedno wystąpienie funkcji z tej samej grupy odbiorców może uzyskiwać dostęp/odczytywać z partycji, na których ma blokady.

Po zakończeniu wykonywania wszystkich funkcji (z błędami lub bez błędów) punkty kontrolne są zatwierdzane na skojarzonym koncie magazynu. Po pomyślnym zakończeniu tworzenia punktów kontrolnych funkcja będzie gotowa do przetworzenia nowej partii zdarzeń.

Dynamiczne skalowanie oparte na zdarzeniach jest możliwe w przypadku planów Użycia, Flex Consumption i Premium platformy Azure. Aplikacje funkcji hostowanej na platformie Kubernetes mogą również korzystać z narzędzia skalowania KEDA dla usługi Event Hubs. Skalowanie oparte na zdarzeniach nie jest obecnie możliwe, gdy aplikacja funkcji jest hostowana w planie dedykowanej usługi (App Service), co wymaga określenia odpowiedniej liczby wystąpień na podstawie obciążenia.

Aby dowiedzieć się więcej, zobacz Powiązania usługi Azure Event Hubs dla usługi Azure Functions i wyzwalacza usługi Azure Event Hubs dla usługi Azure Functions.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• David Barkol | Główny specjalista ds. rozwiązań GBB

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Wydajność i skala

Rozwiązania korzystające z usługi Azure Event Hubs wraz z usługą Azure Functions korzystają z architektury bezserwerowej , która jest skalowalna, ekonomiczna i może przetwarzać duże ilości danych niemal w czasie rzeczywistym. Chociaż te usługi są często używane razem, istnieje wiele funkcji, ustawień i zawiłości, które dodają złożoność ich relacji. Ten artykuł zawiera wskazówki dotyczące efektywnego korzystania z tej integracji przez wyróżnienie kluczowych zagadnień i technik dotyczących wydajności, odporności, zabezpieczeń, możliwości obserwowania i skalowania.

Podstawowe pojęcia dotyczące usługi Event Hubs

Azure Event Hubs to wysoce skalowalna usługa przetwarzania zdarzeń, która może odbierać miliony zdarzeń na sekundę. Przed zapoznaniem się ze wzorcami i najlepszymi rozwiązaniami dotyczącymi integracji usługi Azure Functions najlepiej zrozumieć podstawowe składniki usługi Event Hubs.

Na poniższym diagramie przedstawiono architekturę przetwarzania strumienia usługi Event Hubs:

Zdarzenia

Zdarzenie to zmiana powiadomienia lub stanu, która jest reprezentowana jako fakt, który wystąpił w przeszłości. Zdarzenia są niezmienne i utrwalane w centrum zdarzeń, nazywane również tematemna platformie Kafka. Centrum zdarzeń składa się z co najmniej jednej partycji.

Partycje

Gdy partycja nie jest określona przez nadawcę, odebrane zdarzenia są dystrybuowane między partycjami w centrum zdarzeń. Każde zdarzenie jest zapisywane w dokładnie jednej partycji i nie jest rzutowanie wielowymiarowe między partycjami. Każda partycja działa jako dziennik, w którym rekordy są zapisywane we wzorcu tylko do dołączania. Analogia dziennika zatwierdzeń jest często używana do opisywania charakteru dodawania zdarzeń na końcu sekwencji w partycji.

Gdy jest używana więcej niż jedna partycja, umożliwia używanie dzienników równoległych z tego samego centrum zdarzeń. To zachowanie zapewnia wiele stopni równoległości i zwiększa przepływność dla użytkowników.

Konsumenci i grupy konsumentów

Partycja może być zużywana przez więcej niż jednego konsumenta, każdy odczyt z własnych przesunięć i zarządzanie nimi.

Usługa Event Hubs ma koncepcję grup odbiorców, która umożliwia wielu aplikacjom zużywających wiele aplikacji do każdego z nich ma oddzielny widok strumienia zdarzeń i odczytuje strumień niezależnie we własnym tempie i z własnymi przesunięciami.

Aby dowiedzieć się więcej, zobacz Szczegółowe omówienie pojęć i funkcji usługi Event Hubs.

Korzystanie ze zdarzeń za pomocą usługi Azure Functions

Usługa Azure Functions obsługuje powiązania wyzwalacza i wyjściowe dla usługi Event Hubs. W tej sekcji opisano, jak usługa Azure Functions reaguje na zdarzenia wysyłane do strumienia zdarzeń centrum zdarzeń przy użyciu wyzwalaczy.

Każde wystąpienie wyzwalanej funkcji usługi Event Hubs jest wspierane przez pojedyncze wystąpienie klasy EventProcessorHost . Wyzwalacz (obsługiwany przez usługę Event Hubs) gwarantuje, że tylko jedno wystąpienie klasy EventProcessorHost może uzyskać dzierżawę dla danej partycji.

Rozważmy na przykład centrum zdarzeń o następujących cechach:

• 10 partycji.
• 1000 zdarzeń rozproszonych we wszystkich partycjach z różną liczbą komunikatów w każdej partycji.

Gdy funkcja jest najpierw włączona, istnieje tylko jedno wystąpienie funkcji. Wywołajmy pierwsze wystąpienie Function_1funkcji . Function_1 ma jedno wystąpienie klasy EventProcessorHost , które przechowuje dzierżawę na wszystkich 10 partycjach. To wystąpienie odczytuje zdarzenia z partycji 1–10. Od tego momentu następuje jedna z następujących czynności:

• Nowe wystąpienia funkcji nie są potrzebne: Function_1 może przetworzyć wszystkie 1000 zdarzeń przed zastosowaniem logiki skalowania funkcji. W takim przypadku wszystkie 1000 komunikatów są przetwarzane przez Function_1program .

  

• Dodano dodatkowe wystąpienie funkcji: skalowanie oparte na zdarzeniach lub inna automatyczna lub ręczna logika może określić, że Function_1 ma więcej komunikatów niż może przetworzyć, a następnie utworzy nowe wystąpienie aplikacji funkcji (Function_2). Ta nowa funkcja ma również skojarzone wystąpienie klasy EventProcessorHost. Ponieważ bazowe centrum zdarzeń wykrywa, że nowe wystąpienie hosta próbuje odczytać komunikaty, równoważy obciążenia partycji w wystąpieniach hosta. Na przykład partycje 1–5 mogą być przypisane do Function_1 partycji i partycje 6–10 do Function_2.

  

• Dodano n więcej wystąpień funkcji: skalowanie oparte na zdarzeniach lub inna automatyczna lub ręczna logika określa, że oba Function_1 i Function_2 mają więcej komunikatów niż mogą przetwarzać, tworzone są nowe wystąpienia aplikacji funkcji Function_N. Wystąpienia są tworzone do punktu, w którym N jest równe lub większe niż liczba partycji centrum zdarzeń. W naszym przykładzie usługa Event Hubs ponownie równoważy obciążenie partycji, w tym przypadku między wystąpieniami Function_1...Function_10.

  

W miarę skalowania n wystąpień może być liczbą większą niż liczba partycji centrum zdarzeń. Taka sytuacja może wystąpić, gdy skalowanie sterowane zdarzeniami stabilizuje liczbę wystąpień lub dlatego, że inna automatyczna lub ręczna logika utworzyła więcej wystąpień niż partycje. W takim przypadku wystąpienia klasy EventProcessorHost będą uzyskiwać blokady tylko na partycjach, ponieważ staną się dostępne z innych wystąpień, ponieważ w danym momencie tylko jedno wystąpienie funkcji z tej samej grupy odbiorców może uzyskiwać dostęp/odczytywać z partycji, na których ma blokady.

Po zakończeniu wykonywania wszystkich funkcji (z błędami lub bez błędów) punkty kontrolne są zatwierdzane na skojarzonym koncie magazynu. Po pomyślnym zakończeniu tworzenia punktów kontrolnych funkcja będzie gotowa do przetworzenia nowej partii zdarzeń.

Dynamiczne skalowanie oparte na zdarzeniach jest możliwe w przypadku planów Użycia, Flex Consumption i Premium platformy Azure. Aplikacje funkcji hostowanej na platformie Kubernetes mogą również korzystać z narzędzia skalowania KEDA dla usługi Event Hubs. Skalowanie oparte na zdarzeniach nie jest obecnie możliwe, gdy aplikacja funkcji jest hostowana w planie dedykowanej usługi (App Service), co wymaga określenia odpowiedniej liczby wystąpień na podstawie obciążenia.

Aby dowiedzieć się więcej, zobacz Powiązania usługi Azure Event Hubs dla usługi Azure Functions i wyzwalacza usługi Azure Event Hubs dla usługi Azure Functions.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• David Barkol | Główny specjalista ds. rozwiązań GBB

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Wydajność i skala