Udostępnij za pośrednictwem

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.

Obraz przedstawiający przestrzeń nazw usługi Event Hubs

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.

Obraz przedstawiający centrum zdarzeń z kilkoma partycjami.

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

  • Treść zdarzenia
  • Zdefiniowany przez użytkownika pakiet właściwości opisujący zdarzenie
  • Metadane, takie jak przesunięcie w partycji, jego liczba w sekwencji strumienia
  • Znacznik czasowy po stronie serwera, w momencie którego zostało zaakceptowane

Diagram przedstawiający starszą i nowszą sekwencję zdarzeń.

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ń, a tym samym pomnożenie dostępnej przepustowości surowego wejścia-wyjścia (IO).
  • 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, ile jest wymagane zgodnie z przewidywaniami 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ę, gdy mapowanie kluczy partycji na partycje się zmieni, dlatego należy unikać takich zmian, jeśli względna kolejność zdarzeń ma znaczenie w Twojej 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 wydarzeń, pod względem kosztów. 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 standardowej z 32 partycjami lub z jedną partycją wiąże się z tym samym kosztem, gdy przestrzeń nazw jest ustawiona na jedną jednostkę przepustowości TU. Ponadto można skalować jednostki TUs lub PUs w swojej przestrzeni nazw lub jednostki CU dedykowanego klastra niezależnie od liczby partycji.

Partycja jest mechanizmem organizacji danych, który umożliwia równoległe publikowanie i konsumowanie. Chociaż obsługuje przetwarzanie równoległe i skalowanie, łączna pojemność pozostaje ograniczona przez alokację skalowania przestrzeni nazw. 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 ogólną zasadą obliczania liczby partycji byłoby podzielenie maksymalnej oczekiwanej przepływności przez 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 haszującej, która tworzy podział partycji. Jeśli nie określisz klucza partycji podczas publikowania zdarzenia, używane jest przypisanie rotacyjne.

Wydawca zdarzeń ma informacje tylko o kluczu partycji, ale nie o partycji, do której zdarzenia są publikowane. 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 wzajemne powiązanie zdarzeń. Sekwencja zdarzeń zidentyfikowanych przez klucz partycji jest strumieniem. Partycja jest wielowymiarowym magazynem dziennikowym 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ń do poziomu 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ń (używanym synonimicznie 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 Microsoft Entra ID z tokenami JWT wystawionymi przez protokół OAuth2 lub tokenem sygnatury dostępu współdzielonego specyficznego dla Event Hub w celu uzyskania dostępu do publikowania zdarzeń.

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, dwukierunkowego gniazda oraz bezpieczeństwa na poziomie transportu (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 seria. 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.

Diagram przedstawiający sposób mapowania kluczy partycji na partycje w centrum zdarzeń.

Usługa Event Hubs zapewnia, że wszystkie zdarzenia mają te same wartości 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 Standard, 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. Filozofia architektury polega na tym, że dane historyczne wymagają bogatszego indeksowania i bardziej bezpośredniego dostępu niż interfejs wydarzeń w czasie rzeczywistym oferowany przez Event Hubs lub Kafka. Silniki przesyłania strumieniowego zdarzeń nie są odpowiednie do działania jako "data lakes" lub długoterminowe archiwa do sourcingu 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 do stałego przechowywania nieograniczonych 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 indeksowanie nie znajduje się w zakresie funkcji usługi Event Hubs (lub Apache Kafka). Bazy danych oraz wyspecjalizowane magazyny analityczne i silniki, takie jak Azure Data Lake Store, Azure Data Lake Analytics oraz 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 wydarzeń za pomocą polityk wydawcy. Zasady wydawcy to funkcje zaprojektowane w celu ułatwienia obsługi 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 musisz tworzyć nazw wydawców z góry, ale muszą być one zgodne z tokenem SAS użytym podczas publikowania zdarzenia, aby zapewnić niezależne tożsamości wydawców. W przypadku korzystania z polityk wydawcy wartość PartitionKey musi być ustawiona na nazwę wydawcy. Aby zapewnić prawidłowe działanie, te wartości muszą być zgodne.

Przechwyć

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.

Diagram przedstawiający przechwytywanie danych usługi Event Hubs w usłudze Azure Storage lub Azure Data Lake Storage.

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

Diagram przedstawiający strukturę przechwyconych danych 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 SAS jest generowany na podstawie klucza SAS i jest odciskiem 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 SAS dla wydawców zdarzeń są tworzone jedynie z uprawnieniami do wysyłania w określonym centrum zdarzeń. Ten mechanizm adresu URL tokenu SAS stanowi podstawę identyfikacji wydawcy wprowadzonej w polityce wydawcy. Aby uzyskać więcej informacji na temat pracy z SAS, zobacz 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 używają protokołu AMQP lub systemu Apache Kafka do odbierania zdarzeń z huba 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 procedur obsługi zdarzeń do obsługi zdarzeń z huba zdarzeń, procesor zdarzeń wewnętrznie używa modelu pobierania do odbierania zdarzeń z huba 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 korzystającym odczyt tych samych danych przesyłanych strumieniowo w centrum wydarzeń niezależnie, we własnym tempie, z własnymi przesunięciami. 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 w grupie odbiorców na partycji 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 zaprezentowano konwencję URI grupy konsumenckiej.

//<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:

Diagram przedstawiający architekturę przetwarzania strumienia usługi Event Hubs.

Przesunięcia strumienia

Offset to pozycja zdarzenia w partycji. Przesunięcie można traktować jako kursor po stronie klienta. Przesunięcie to numerowanie bajtów 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. Konsumenci 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.

Diagram przedstawiający partycję z przesunięciem.

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 konsumencie i odbywa się indywidualnie dla każdej partycji w grupie konsumentó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ąże połączenie, przekazuje przesunięcie do centrum zdarzeń, aby określić punkt, od którego ma rozpocząć odczytywanie. W ten sposób można użyć punktów kontrolnych zarówno do oznaczenia zdarzeń jako „ukończone” przez aplikacje działające dalej w procesie, jak i zapewnienia odporności w przypadku przełączenia awaryjnego między czytnikami działającymi na różnych maszynach. Można wrócić do starszych danych, określając niższe przesunięcie w procesie 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. Odpowiedzialność za monitorowanie punktów kontrolnych podczas przetwarzania zdarzeń spoczywa na konsumencie.

Postępuj zgodnie z tymi zaleceniami, gdy używasz 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 konta magazynowego do niczego innego.
  • Nie używaj kontenera do niczego innego.
  • Utwórz konto magazynu w tym samym regionie co wdrożona aplikacja. Jeśli aplikacja jest na miejscu, spróbuj wybrać najbliższy możliwy region.

Na stronie konta magazynowego w portalu Azure, w sekcji usługi Blob, upewnij się, że następujące ustawienia zostały wyłączone.

  • Hierarchiczna przestrzeń nazw
  • Miękkie usuwanie obiektów blob
  • Wersjonowanie

Kompaktowanie logów

Usługa Azure Event Hubs obsługuje kompaktowanie dziennika zdarzeń w celu zachowania najnowszych zdarzeń danego klucza zdarzenia. W przypadku skompaktowanych centrów zdarzeń/tematów Kafka można użyć przechowywania bazującego na kluczach, zamiast korzystać z bardziej ogólnego 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, jest to świadomy stanu kanał komunikacji dwukierunkowej. 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, wynajem i zarządzanie odbiornikami jest uproszczone dzięki użyciu klientów w ramach zestawów SDK usługi Event Hubs, które działają jako inteligentne agenty odbiorców. Są to:

Odczytaj zdarzenia

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 wyznaczania punktów kontrolnych na 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, oraz zarządzanie przesyłaniem strumieniowym zdarzeń (publikowanie lub odbieranie) pomiędzy aplikacjami klienckimi a 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 Kafka można ponownie skonfigurować tak, aby wskazywała na przestrzeń nazw "s" zamiast na serwer bootstrap klastra 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 Apache Kafka, zyskujesz także dostęp do funkcji usługi Azure Event Hubs, takich jak automatyczne grupowanie i archiwizowanie za pośrednictwem funkcji Event Hubs Capture, automatyczne skalowanie i równoważenie obciążenia, odzyskiwanie po awarii, obsługa strefy dostępności neutralnej pod względem kosztów, elastyczna i bezpieczna integracja sieci oraz obsługa wielu protokołów, w tym przyjaznego dla zapory protokołu AMQP-przez-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 konsumenci 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 procedur obsługi zdarzeń do obsługi zdarzeń z huba zdarzeń, procesor zdarzeń wewnętrznie używa modelu pobierania do odbierania zdarzeń z huba zdarzeń.

AMQP (Protokół przesyłania danych asynchronicznych)

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: