Funkcje i terminologia w usłudze Azure Event Hubs

Azure Event Hubs to skalowalna usługa przetwarzania zdarzeń, która pozyskiwa i przetwarza duże ilości zdarzeń i danych z małym opóźnieniem i wysoką niezawodnością. Aby zapoznać się z ogólnym omówieniem usługi, zobacz Co to jest usługa Event Hubs?.

Ten artykuł opiera się na informacjach w artykule omówienia oraz zawiera szczegóły techniczne i implementacji dotyczące składników i funkcji usługi Event Hubs.

Przestrzeń nazw

Przestrzeń nazw usługi Event Hubs to kontener zarządzania dla centrów zdarzeń (lub tematów w parlance platformy Kafka). Zapewnia on zintegrowane z systemem DNS punkty końcowe sieci oraz szereg funkcji kontroli dostępu i zarządzania integracją sieci, takich jak filtrowanie adresów IP, punkt końcowy usługi sieci wirtualnej i usługa Private Link.

Partycje

Usługa Event Hubs organizuje sekwencje zdarzeń wysyłanych do centrum zdarzeń w co najmniej jednej partycji. Po nadejściu nowszych zdarzeń są one dodawane na końcu tej sekwencji.

Partycję można traktować jako dziennik zatwierdzeń. Partycje przechowują dane zdarzeń zawierające następujące informacje:

• Treść zdarzenia
• Torba właściwości zdefiniowana przez użytkownika opisująca zdarzenie
• Metadane, takie jak przesunięcie w partycji, jego liczba w sekwencji strumienia
• Sygnatura czasowa po stronie usługi, w której została zaakceptowana

Zalety korzystania z partycji

Usługa Event Hubs została zaprojektowana w celu ułatwienia przetwarzania dużych ilości zdarzeń, a partycjonowanie pomaga w tym na dwa sposoby:

• Mimo że usługa Event Hubs jest usługą PaaS, poniżej znajduje się rzeczywistość fizyczna. Utrzymywanie dziennika, który zachowuje kolejność zdarzeń, wymaga, aby te zdarzenia były przechowywane razem w magazynie bazowym i jego replikach, co powoduje pułap przepływności dla takiego dziennika. Partycjonowanie umożliwia użycie wielu dzienników równoległych dla tego samego centrum zdarzeń i w związku z tym pomnożenie dostępnej pojemności przepływności danych wejściowych (we/wy).
• Twoje aplikacje muszą być w stanie nadążyć za przetwarzaniem liczby zdarzeń wysyłanych do centrum zdarzeń. Może to być złożone i wymaga znacznej, skalowanej w poziomie pojemności przetwarzania równoległego. Pojemność pojedynczego procesu do obsługi zdarzeń jest ograniczona, więc potrzebujesz kilku procesów. Partycje są sposobem, w jaki rozwiązanie jest źródłem tych procesów, a jednocześnie zapewnia, że każde zdarzenie ma jasnego właściciela przetwarzania.

Liczba partycji

Liczba partycji jest określana w momencie tworzenia centrum zdarzeń. Musi zawierać się między jedną a maksymalną dozwoloną liczbą partycji dla każdej warstwy cenowej. Aby uzyskać limit liczby partycji dla każdej warstwy, zobacz ten artykuł.

Zalecamy wybranie co najmniej tylu partycji, zgodnie z oczekiwaniami, które są wymagane podczas szczytowego obciążenia aplikacji dla tego konkretnego centrum zdarzeń. W przypadku warstw innych niż warstwy premium i dedykowane nie można zmienić liczby partycji dla centrum zdarzeń po jego utworzeniu. W przypadku centrum zdarzeń w warstwie Premium lub dedykowanej można zwiększyć liczbę partycji po jego utworzeniu, ale nie można ich zmniejszyć. Rozkład strumieni między partycjami zmieni się po zakończeniu mapowania kluczy partycji na zmiany partycji, dlatego należy spróbować uniknąć takich zmian, jeśli względna kolejność zdarzeń ma znaczenie w aplikacji.

Ustawienie liczby partycji na maksymalną dozwoloną wartość jest kuszące, ale należy pamiętać, że strumienie zdarzeń muszą być ustrukturyzowane tak, aby rzeczywiście można było korzystać z wielu partycji. Jeśli potrzebujesz bezwzględnego zachowania porządku we wszystkich zdarzeniach lub tylko kilku podstreamach, możesz nie być w stanie skorzystać z wielu partycji. Ponadto wiele partycji sprawia, że strona przetwarzania jest bardziej złożona.

Nie ma znaczenia, ile partycji znajduje się w centrum zdarzeń, jeśli chodzi o ceny. Zależy to od liczby jednostek cenowych (jednostek przepływności (TU) dla warstwy Standardowa, jednostek przetwarzania (PU) dla warstwy Premium oraz jednostek pojemności (CU) dla dedykowanej warstwy) dla przestrzeni nazw lub dedykowanego klastra. Na przykład centrum zdarzeń warstwy Standardowa z 32 partycjami lub z jedną partycją wiąże się z tym samym kosztem, gdy przestrzeń nazw jest ustawiona na jedną pojemność tu. Ponadto można skalować jednostki RU lub jednostki PU w przestrzeni nazw lub jednostkach CU dedykowanego klastra niezależnie od liczby partycji.

Jako partycja to mechanizm organizacji danych, który umożliwia równoległe publikowanie i używanie danych. Zalecamy równoważenie jednostek skalowania (jednostek przepływności dla warstwy Standardowa, jednostek przetwarzania dla warstwy Premium lub jednostek pojemności dla warstwy dedykowanej) i partycji w celu uzyskania optymalnej skali. Ogólnie rzecz biorąc, zalecamy maksymalną przepływność wynoszącą 1 MB/s na partycję. W związku z tym regułą kciuka do obliczenia liczby partycji byłoby podzielenie maksymalnej oczekiwanej przepływności o 1 MB/s. Jeśli na przykład przypadek użycia wymaga 20 MB/s, zalecamy wybranie co najmniej 20 partycji w celu uzyskania optymalnej przepływności.

Jeśli jednak masz model, w którym aplikacja ma koligację z określoną partycją, zwiększenie liczby partycji nie jest korzystne. Aby uzyskać więcej informacji, zobacz dostępność i spójność.

Mapowanie zdarzeń na partycje

Klucz partycji służy do mapowania danych zdarzeń przychodzących na określone partycje na potrzeby organizowania danych. Klucz partycji to wartość podawana przez nadawcę przekazywana do centrum zdarzeń. Jest ona przetwarzana za pomocą statycznej funkcji tworzenia skrótów, która tworzy przypisanie partycji. Jeśli nie określisz klucza partycji podczas publikowania zdarzenia, używane jest przypisanie działania okrężnego.

Wydawca zdarzeń ma informacje tylko o kluczu partycji, a nie partycji, na której publikowane są zdarzenia. To oddzielenie klucza od partycji powoduje, że nadawca nie musi wiedzieć zbyt dużo o przetwarzaniu podrzędnym. Unikatowa tożsamość urządzenia lub użytkownika stanowi dobry klucz partycji, ale inne atrybuty, takie jak lokalizacja geograficzna, mogą również zostać użyte do grupowania powiązanych zdarzeń w jedną partycję.

Określenie klucza partycji umożliwia zachowanie powiązanych zdarzeń w tej samej partycji i w dokładnej kolejności, w jakiej dotarły. Klucz partycji jest ciągiem pochodzącym z kontekstu aplikacji i identyfikuje interrelationship zdarzeń. Sekwencja zdarzeń zidentyfikowanych przez klucz partycji jest strumieniem. Partycja jest multipleksowym magazynem dzienników dla wielu takich strumieni.

Uwaga

Chociaż zdarzenia można wysyłać bezpośrednio do partycji, nie zalecamy tego, zwłaszcza gdy wysoka dostępność jest dla Ciebie ważna. Obniża dostępność centrum zdarzeń na poziomie partycji. Aby uzyskać więcej informacji, zobacz Dostępność i spójność.

Wydawcy zdarzeń

Każda jednostka, która wysyła dane do centrum zdarzeń, jest wydawcą zdarzeń (synonimem używanym z producentem zdarzeń). Wydawcy zdarzeń mogą publikować zdarzenia przy użyciu protokołu HTTPS lub AMQP 1.0 lub protokołu Kafka. Wydawcy zdarzeń używają autoryzacji opartej na identyfikatorze Entra firmy Microsoft z tokenami JWT wystawionymi przez protokół OAuth2 lub tokenem sygnatury dostępu współdzielonego specyficznego dla centrum zdarzeń w celu uzyskania dostępu do publikowania.

Zdarzenie można opublikować za pośrednictwem protokołu AMQP 1.0, protokołu Kafka lub HTTPS. Usługa Event Hubs udostępnia interfejs API REST i biblioteki klienta .NET, Java, Python, JavaScript i Go do publikowania zdarzeń w centrum zdarzeń. W przypadku innych środowisk uruchomieniowych i platform można używać dowolnego klienta protokołu AMQP 1.0, na przykład Apache Qpid.

Decyzja o korzystaniu z protokołu AMQP lub HTTPS jest specyficzna dla scenariusza użycia. Protokół AMQP wymaga ustanowienia trwałego gniazda dwukierunkowego oprócz protokołu TLS lub SSL/ TLS. Protokół AMQP ma wyższe koszty sieci podczas inicjowania sesji, jednak protokół HTTPS wymaga dodatkowych obciążeń związanych z protokołem TLS dla każdego żądania. Protokół AMQP ma wyższą wydajność dla częstych wydawców i może osiągnąć znacznie mniejsze opóźnienia w przypadku użycia z kodem publikowania asynchronicznego.

Zdarzenia można publikować pojedynczo lub wsadowo. Pojedyncza publikacja ma limit wynoszący 1 MB, niezależnie od tego, czy jest to pojedyncze zdarzenie, czy partia. Publikowanie zdarzeń większych niż ten próg jest odrzucane.

Przepływność usługi Event Hubs jest skalowana przy użyciu partycji i alokacji jednostek przepływności. Najlepszym rozwiązaniem jest, aby wydawcy nie byli świadomi określonego modelu partycjonowania wybranego dla centrum zdarzeń i określić tylko klucz partycji, który jest używany do spójnego przypisywania powiązanych zdarzeń do tej samej partycji.

Usługa Event Hubs zapewnia, że wszystkie zdarzenia współużytkujące wartość klucza partycji są przechowywane razem i dostarczane w kolejności przyjazdu. Jeśli klucze partycji są używane wraz z zasadami wydawcy, to tożsamość wydawcy i wartość klucza partycji muszą być zgodne. W przeciwnym razie wystąpi błąd.

Przechowywanie zdarzeń

Opublikowane zdarzenia są usuwane z centrum zdarzeń na podstawie konfigurowalnych, opartych na czasie zasad przechowywania. Oto kilka ważnych kwestii:

• Wartość domyślna i najkrótszy możliwy okres przechowywania to 1 godzina.
• W przypadku usługi Event Hubs w warstwie Standardowa maksymalny okres przechowywania wynosi 7 dni.
• W przypadku usługi Event Hubs Premium i Dedykowane maksymalny okres przechowywania wynosi 90 dni.
• Jeśli zmienisz okres przechowywania, dotyczy to wszystkich zdarzeń, w tym zdarzeń, które znajdują się już w centrum zdarzeń.

Usługa Event Hubs zachowuje zdarzenia dla skonfigurowanego czasu przechowywania, który ma zastosowanie we wszystkich partycjach. Zdarzenia są usuwane automatycznie po osiągnięciu okresu przechowywania. Jeśli określono okres przechowywania jednego dnia (24 godziny), zdarzenie stanie się niedostępne dokładnie 24 godziny po zaakceptowaniu. Nie można jawnie usuwać zdarzeń.

Jeśli musisz archiwizować zdarzenia poza dozwolonym okresem przechowywania, możesz je automatycznie przechowywać w usłudze Azure Storage lub Azure Data Lake, włączając funkcję przechwytywania usługi Event Hubs. Jeśli musisz przeszukiwać lub analizować takie głębokie archiwa, możesz je łatwo zaimportować do usługi Azure Synapse lub innych podobnych magazynów i platform analitycznych.

Przyczyną ograniczenia przechowywania danych w usłudze Event Hubs na podstawie czasu jest zapobieganie uwięzieniu dużych ilości historycznych danych klienta w głębokim magazynie, który jest indeksowany tylko przez znacznik czasu i umożliwia dostęp sekwencyjny. Oto filozofia architektury, że dane historyczne wymagają bogatszego indeksowania i bardziej bezpośredniego dostępu niż interfejs zdarzeń w czasie rzeczywistym zapewniany przez usługę Event Hubs lub Kafka. Aparaty przesyłania strumieniowego zdarzeń nie są odpowiednie do odegrania roli magazynów typu data lake lub długoterminowych archiwów na potrzeby określania źródła zdarzeń.

Uwaga

Usługa Event Hubs jest aparatem strumienia zdarzeń w czasie rzeczywistym i nie jest przeznaczona do użycia zamiast bazy danych i/lub jako trwały magazyn dla nieskończenie przechowywanych strumieni zdarzeń.

Im głębsza historia strumienia zdarzeń, tym bardziej potrzebne będą indeksy pomocnicze, aby znaleźć konkretny historyczny fragment danego strumienia. Inspekcja ładunków zdarzeń i indeksowania nie mieści się w zakresie funkcji usługi Event Hubs (lub Apache Kafka). Bazy danych i wyspecjalizowane magazyny analityczne i aparaty, takie jak Azure Data Lake Store, Azure Data Lake Analytics i Azure Synapse , są zatem znacznie lepiej dostosowane do przechowywania zdarzeń historycznych.

Usługa Event Hubs Capture integruje się bezpośrednio z usługami Azure Blob Storage i Azure Data Lake Storage, a także umożliwia przepływ zdarzeń bezpośrednio do usługi Azure Synapse.

Zasady wydawcy

Usługa Event Hubs umożliwia szczegółową kontrolę nad wydawcami zdarzeń za pomocą zasad wydawcy. Zasady wydawcy to funkcje środowiska uruchomieniowego zaprojektowane w celu ułatwienia działania dużej liczby niezależnych wydawców zdarzeń. Dzięki zasadom wydawcy każdy wydawca używa swojego unikatowego identyfikatora podczas publikowania zdarzeń w centrum zdarzeń przy użyciu następującego mechanizmu:

//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>

Nie jest konieczne wcześniejsze tworzenie nazw wydawców, ale muszą one być zgodne z tokenem sygnatury dostępu współdzielonego użytym podczas publikowania zdarzenia w celu zapewnienia niezależnych tożsamości wydawcy. W przypadku korzystania z zasad wydawcy wartość PartitionKey musi być ustawiona na nazwę wydawcy. Aby zapewnić prawidłowe działanie, te wartości muszą być zgodne.

Capture

Funkcja przechwytywania usługi Event Hubs umożliwia automatyczne przechwytywanie danych przesyłanych strumieniowo w usłudze Event Hubs i zapisywanie ich na wybranym koncie usługi Blob Storage lub na koncie usługi Azure Data Lake Storage. Możesz włączyć przechwytywanie w witrynie Azure Portal i określić minimalny rozmiar i przedział czasu do wykonania przechwytywania. Korzystając z funkcji przechwytywania usługi Event Hubs, należy określić własne konto i kontener usługi Azure Blob Storage lub konto usługi Azure Data Lake Storage, które jest używane do przechowywania przechwyconych danych. Przechwycone dane są zapisywane w formacie Apache Avro.

Pliki utworzone przez usługę Event Hubs Capture mają następujący schemat Avro:

Uwaga

Jeśli nie używasz edytora kodu w witrynie Azure Portal, możesz przechwycić dane przesyłane strumieniowo w usłudze Event Hubs na koncie usługi Azure Data Lake Storage Gen2 w formacie Parquet . Aby uzyskać więcej informacji, zobacz Jak przechwytywać dane z usługi Event Hubs w formacie Parquet i Samouczek: przechwytywanie danych usługi Event Hubs w formacie Parquet i analizowanie za pomocą usługi Azure Synapse Analytics.

Tokeny sygnatur dostępu współdzielonego

Usługa Event Hubs używa sygnatur dostępu współdzielonego, które są dostępne na poziomie przestrzeni nazw i centrum zdarzeń. Token sygnatury dostępu współdzielonego jest generowany na podstawie klucza sygnatury dostępu współdzielonego i jest skrótem SHA adresu URL zakodowanym w określonym formacie. Usługa Event Hubs może ponownie wygenerować skrót przy użyciu nazwy klucza (zasad) i tokenu, a tym samym uwierzytelnić nadawcę. Zwykle tokeny sygnatury dostępu współdzielonego dla wydawców zdarzeń są tworzone jedynie z uprawnieniami do wysyłania w określonym centrum zdarzeń. Ten mechanizm adresu URL tokenu sygnatury dostępu współdzielonego stanowi podstawę do identyfikacji wydawcy wprowadzoną w ramach zasad wydawcy. Aby uzyskać więcej informacji na temat pracy z sygnaturą dostępu współdzielonego, zobacz Shared Access Signature Authentication with Service Bus (Uwierzytelnianie za pomocą sygnatury dostępu współdzielonego przy użyciu usługi Service Bus).

Odbiorcy zdarzeń

Każda jednostka, która odczytuje dane zdarzenia z centrum zdarzeń, jest odbiorcą zdarzenia. Odbiorcy lub odbiorcy używają protokołu AMQP lub Apache Kafka do odbierania zdarzeń z centrum zdarzeń. Usługa Event Hubs obsługuje tylko model ściągania, który umożliwia konsumentom odbieranie z niego zdarzeń. Nawet w przypadku używania programów obsługi zdarzeń do obsługi zdarzeń z centrum zdarzeń procesor zdarzeń wewnętrznie używa modelu ściągania do odbierania zdarzeń z centrum zdarzeń.

Grupy odbiorców

Mechanizm publikowania/subskrypcji usługi Event Hubs jest włączany za pomocą grup odbiorców. Grupa odbiorców to logiczna grupa odbiorców odczytujących dane z centrum zdarzeń lub tematu platformy Kafka. Umożliwia wielu aplikacjom zużywających odczyt tych samych danych przesyłanych strumieniowo w centrum zdarzeń niezależnie we własnym tempie z przesunięciem. Umożliwia równoległe wykorzystanie komunikatów i rozłożenie obciążenia między wielu odbiorców przy zachowaniu kolejności komunikatów w ramach każdej partycji.

Zalecamy, aby na partycji w grupie odbiorców był tylko jeden aktywny odbiornik. Jednak w niektórych scenariuszach można użyć maksymalnie pięciu odbiorców lub odbiorników na partycję, gdzie wszystkie odbiorniki pobierają wszystkie zdarzenia partycji. Jeśli masz wielu czytelników na tej samej partycji, przetwarzasz zduplikowane zdarzenia. Musisz obsłużyć go w kodzie, co nie jest proste. Jednak jest to prawidłowe podejście w niektórych scenariuszach.

W architekturze przetwarzania strumieni każda aplikacja podrzędna odpowiada grupie odbiorców. Jeśli chcesz zapisać dane zdarzenia do magazynu długoterminowego, to ta aplikacja edytora magazynu odpowiada grupie odbiorców. Przetwarzanie złożonych zdarzeń może być wtedy wykonywane przez inną, oddzielną grupę odbiorców. Dostęp do partycji można uzyskać tylko za pośrednictwem grupy odbiorców. Zawsze istnieje domyślna grupa odbiorców w centrum zdarzeń i można utworzyć maksymalną liczbę grup odbiorców dla odpowiedniej warstwy cenowej.

Niektórzy klienci oferowani przez zestawy SDK platformy Azure to inteligentni agenci odbiorcy, którzy automatycznie zarządzają szczegółami zapewniającymi, że każda partycja ma jeden czytnik i że wszystkie partycje centrum zdarzeń są odczytywane. Dzięki temu kod może skupić się na przetwarzaniu odczytanych zdarzeń z centrum zdarzeń, dzięki czemu może ignorować wiele szczegółów partycji. Aby uzyskać więcej informacji, zobacz Nawiązywanie połączenia z partycją.

W poniższych przykładach przedstawiono konwencję identyfikatora URI grupy odbiorców:

//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

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

Przesunięcia strumienia

Przesunięcie to pozycja zdarzenia w partycji. Przesunięcie można traktować jako kursor po stronie klienta. Przesunięcie to numer bajtu zdarzenia. To przesunięcie umożliwi odbiorcy zdarzeń (czytnikowi) określenie punktu w strumieniu zdarzeń, od którego ma zostać rozpoczęte odczytywanie zdarzeń. Przesunięcie można określić jako sygnaturę czasową lub wartość przesunięcia. Odbiorcy są zobowiązani do przechowywania własnych wartości przesunięcia poza usługą Event Hubs. W ramach partycji każde zdarzenie zawiera przesunięcie.

Tworzenie punktów kontrolnych

Tworzenie punktów kontrolnych jest procesem, za pomocą którego czytniki oznaczają lub zatwierdzają swoją pozycję w sekwencji zdarzeń partycji. Odpowiedzialność za tworzenie punktów kontrolnych spoczywa na odbiorcy i odbywa się dla każdej partycji w ramach grupy odbiorców. Ta odpowiedzialność oznacza, że dla każdej grupy odbiorców każdy czytnik partycji musi śledzić swoją bieżącą pozycję w strumieniu zdarzeń i może poinformować usługi, gdy uzna, że strumień danych jest pełny.

Jeśli czytnik rozłączy się od partycji, po swoim ponownym połączeniu rozpoczyna odczyt punktu kontrolnego, który został wcześniej przesłany przez ostatni czytnik tej partycji w danej grupie odbiorców. Gdy czytnik nawiąż połączenie, przekazuje przesunięcie do centrum zdarzeń, aby określić lokalizację, w której ma rozpocząć odczytywanie. W ten sposób można użyć procesu tworzenia punktów kontrolnych zarówno do oznaczenia zdarzeń jako „ukończone” przez aplikacje podrzędne, jak i zapewnienia odporności zdarzenia na pracę w trybie failover między czytnikami działającymi na różnych komputerach. Można wrócić do starszych danych, określając niższe przesunięcie z tego procesu tworzenia punktów kontrolnych. Dzięki temu mechanizmowi tworzenie punktów kontrolnych zapewnia zarówno odporność na pracę w trybie failover, jak i powtarzanie strumienia zdarzeń.

Ważne

Przesunięcia są udostępniane przez usługę Event Hubs. To odpowiedzialność konsumenta za punkt kontrolny w miarę przetwarzania zdarzeń.

Postępuj zgodnie z poniższymi zaleceniami w przypadku korzystania z usługi Azure Blob Storage jako magazynu punktów kontrolnych:

• Użyj oddzielnego kontenera dla każdej grupy odbiorców. Możesz użyć tego samego konta magazynu, ale użyj jednego kontenera dla każdej grupy.
• Nie używaj kontenera dla żadnych innych elementów i nie używaj konta magazynu dla innych elementów.
• Konto magazynu powinno znajdować się w tym samym regionie co wdrożona aplikacja. Jeśli aplikacja jest lokalna, spróbuj wybrać możliwy region najbliżej.

Na stronie Konto magazynu w witrynie Azure Portal w sekcji Blob Service upewnij się, że następujące ustawienia są wyłączone.

• Hierarchiczna przestrzeń nazw
• Usuwanie nietrwałe obiektów blob
• Wersje

Kompaktowanie dzienników

Usługa Azure Event Hubs obsługuje kompaktowanie dziennika zdarzeń w celu zachowania najnowszych zdarzeń danego klucza zdarzenia. W przypadku zwartych centrów zdarzeń/tematu platformy Kafka można użyć przechowywania opartego na kluczach, zamiast korzystać z grubszego przechowywania opartego na czasie.

Aby uzyskać więcej informacji na temat kompaktowania dzienników, zobacz Log compaction (Kompaktowanie dzienników).

Typowe zadania odbiorców

Wszyscy odbiorcy usługi Event Hubs łączą się za pośrednictwem sesji protokołu AMQP 1.0, kanału komunikacji dwukierunkowej obsługującej stan. Każda partycja zawiera sesję protokołu AMQP 1.0, która ułatwia transport zdarzeń posegregowanych według partycji.

Nawiązywanie połączenia z partycją

Podczas nawiązywania połączenia z partycjami często stosuje się mechanizm dzierżawy do koordynowania połączeń czytnika z określonymi partycjami. Dzięki temu każda partycja w grupie odbiorców może mieć tylko jeden aktywny czytelnik. Tworzenie punktów kontrolnych, dzierżawienie i zarządzanie czytelnikami jest uproszczone przy użyciu klientów w zestawach SDK usługi Event Hubs, które działają jako inteligentni agenci odbiorcy. Są to:

• EventProcessorClient dla platformy .NET
• EventProcessorClient dla języka Java
• EventHubConsumerClient dla języka Python
• EventHubConsumerClient dla języka JavaScript/TypeScript

Zdarzenia odczytywania

Po otwarciu sesji i linku protokołu AMQP 1.0 dla określonej partycji zdarzenia są dostarczane do klienta protokołu AMQP 1.0 przez usługę Event Hubs. Ten mechanizm dostarczania zapewnia wyższą przepływność i mniejsze opóźnienia niż mechanizmy oparte na ściąganiu, na przykład HTTP GET. Podczas wysyłania zdarzeń do klienta każde wystąpienie danych zdarzenia zawiera ważne metadane, takie jak przesunięcie i numer sekwencji, które są używane do ułatwienia tworzenia punktów kontrolnych sekwencji zdarzeń.

Dane zdarzenia:

• Przesunięcie
• Numer sekwencyjny
• Treść
• Właściwości użytkownika
• Właściwości systemu

Twoim zadaniem jest zarządzanie przesunięciem.

Grupy aplikacji

Grupa aplikacji to kolekcja aplikacji klienckich łączących się z przestrzenią nazw usługi Event Hubs udostępniającą unikatowy warunek identyfikacji, taki jak kontekst zabezpieczeń — zasady dostępu współdzielonego lub identyfikator aplikacji Microsoft Entra.

Usługa Azure Event Hubs umożliwia definiowanie zasad dostępu do zasobów, takich jak zasady ograniczania dla danej grupy aplikacji i sterowanie przesyłaniem strumieniowym zdarzeń (publikowanie lub korzystanie) między aplikacjami klienckimi i usługą Event Hubs.

Aby uzyskać więcej informacji, zobacz Zarządzanie zasobami dla aplikacji klienckich z grupami aplikacji.

Obsługa platformy Apache Kafka

Obsługa protokołu dla klientów platformy Apache Kafka (wersja >=1.0) zapewnia punkty końcowe, które umożliwiają istniejącym aplikacjom platformy Kafka korzystanie z usługi Event Hubs. Większość istniejących aplikacji platformy Kafka można ponownie skonfigurować tak, aby wskazywała przestrzeń nazw zamiast serwera bootstrap klastra platformy Kafka.

Z perspektywy kosztów, nakładu pracy operacyjnej i niezawodności usługa Azure Event Hubs to świetna alternatywa dla wdrażania i obsługi własnych klastrów kafka i zookeeper oraz ofert platformy Kafka jako usługa, które nie są natywne dla platformy Azure.

Oprócz uzyskania takich samych podstawowych funkcji jak broker platformy Apache Kafka, możesz również uzyskać dostęp do funkcji usługi Azure Event Hubs, takich jak automatyczne dzielenie na partie i archiwizowanie za pośrednictwem funkcji przechwytywania usługi Event Hubs, automatycznego skalowania i równoważenia, odzyskiwania po awarii, obsługi strefy dostępności neutralnej pod względem kosztów, elastycznej i bezpiecznej integracji sieci oraz obsługi wielu protokołów, w tym przyjaznego dla zapory protokołu AMQP-over-WebSockets.

Protokoły

Producenci lub nadawcy mogą wysyłać zdarzenia do centrum zdarzeń przy użyciu protokołu Advanced Messaging Queuing Protocol (AMQP), Kafka lub HTTPS.

Odbiorcy lub odbiorcy używają protokołu AMQP lub platformy Kafka do odbierania zdarzeń z centrum zdarzeń. Usługa Event Hubs obsługuje tylko model ściągania, który umożliwia konsumentom odbieranie z niego zdarzeń. Nawet w przypadku używania programów obsługi zdarzeń do obsługi zdarzeń z centrum zdarzeń procesor zdarzeń wewnętrznie używa modelu ściągania do odbierania zdarzeń z centrum zdarzeń.

AMQP

Protokół AMQP 1.0 umożliwia wysyłanie zdarzeń do usługi Azure Event Hubs i odbieranie zdarzeń. Protokół AMQP zapewnia niezawodną, wydajną i bezpieczną komunikację zarówno do wysyłania, jak i odbierania zdarzeń. Można go używać do przesyłania strumieniowego o wysokiej wydajności i czasie rzeczywistym i jest obsługiwany przez większość zestawów SDK usługi Azure Event Hubs.

HTTPS/REST API

Zdarzenia można wysyłać tylko do usługi Event Hubs przy użyciu żądań HTTP POST. Usługa Event Hubs nie obsługuje odbierania zdarzeń za pośrednictwem protokołu HTTPS. Jest odpowiedni dla lekkich klientów, gdzie bezpośrednie połączenie TCP nie jest możliwe.

Apache Kafka

Usługa Azure Event Hubs ma wbudowany punkt końcowy platformy Kafka, który obsługuje producentów i konsumentów platformy Kafka. Aplikacje utworzone przy użyciu platformy Kafka mogą używać protokołu Kafka (w wersji 1.0 lub nowszej) do wysyłania i odbierania zdarzeń z usługi Event Hubs bez żadnych zmian w kodzie.

Zestawy SDK platformy Azure tworzą abstrakcję podstawowych protokołów komunikacyjnych i zapewniają uproszczony sposób wysyłania i odbierania zdarzeń z usługi Event Hubs przy użyciu języków takich jak C#, Java, Python, JavaScript itp.

Następne kroki

Aby uzyskać więcej informacji na temat usługi Event Hubs, skorzystaj z następujących linków:

• Wprowadzenie do usługi Event Hubs
  • .NET
  • Java
  • Python
  • JavaScript

• Availability and consistency in Event Hubs (Dostępność i spójność w usłudze Event Hubs)
• Event Hubs — często zadawane pytania
• Przykłady usługi Event Hubs