W tym artykule opisano różne typy komunikatów i jednostki, które uczestniczą w infrastrukturze obsługi komunikatów. Na podstawie wymagań poszczególnych typów komunikatów artykuł zaleca usługi obsługi komunikatów platformy Azure. Opcje obejmują komunikaty usługi Azure Service Bus, usługę Azure Event Grid i usługę Azure Event Hubs. Aby uzyskać porównanie produktów, zobacz Porównanie usług obsługi komunikatów.
Na poziomie architektury komunikat jest datagramem utworzonym przez jednostkę (producent) w celu dystrybucji informacji, dzięki czemu inne jednostki (konsumenci) mogą być odpowiednio świadomi i działać zgodnie z nimi. Producent i konsument mogą komunikować się bezpośrednio lub opcjonalnie za pośrednictwem jednostki pośredniczącej (broker komunikatów). Ten artykuł koncentruje się na asynchronicznych komunikatach przy użyciu brokera komunikatów.
Możemy sklasyfikować komunikaty w dwóch głównych kategoriach. Jeśli producent oczekuje akcji od konsumenta, komunikat jest poleceniem. Jeśli komunikat informuje użytkownika o tym, że wystąpiła akcja, komunikat jest zdarzeniem.
Polecenia
Producent wysyła polecenie z zamiarem, że odbiorcy będą wykonywać operację w zakresie transakcji biznesowej.
Polecenie jest komunikatem o wysokiej wartości i musi zostać dostarczony co najmniej raz. Jeśli polecenie zostanie utracone, cała transakcja biznesowa może zakończyć się niepowodzeniem. Ponadto polecenie nie powinno być przetwarzane więcej niż raz. Może to spowodować błędną transakcję. Klient może otrzymać zduplikowane zamówienia lub rozliczone dwa razy.
Polecenia są często używane do zarządzania przepływem pracy wieloetapowej transakcji biznesowej. W zależności od logiki biznesowej producent może oczekiwać, że konsument potwierdzi komunikat i zgłosi wyniki operacji. Na podstawie tego wyniku producent może wybrać odpowiedni przebieg działania.
Wydarzenia
Wydarzenie to rodzaj wiadomości, którą producent zgłasza, aby ogłosić fakty.
Producent (znany jako wydawca w tym kontekście) nie ma oczekiwań, że zdarzenia powodują jakąkolwiek akcję.
Zainteresowani odbiorcy mogą subskrybować, nasłuchiwać zdarzeń i podejmować działania w zależności od scenariusza użycia. Zdarzenia mogą mieć wielu subskrybentów lub żadnych subskrybentów. Dwóch różnych subskrybentów może reagować na zdarzenie za pomocą różnych akcji i nie być świadomymi siebie.
Producent i konsument są luźno powiązane i zarządzane niezależnie. Producent nie spodziewa się, że konsument potwierdzi wydarzenie z powrotem do producenta. Użytkownik, który nie jest już zainteresowany zdarzeniami, może anulować subskrypcję, co spowoduje usunięcie konsumenta z potoku bez wpływu na producenta lub ogólną funkcjonalność systemu.
Istnieją dwie kategorie zdarzeń:
Producent podnosi wydarzenia, aby ogłosić dyskretne fakty. Typowym przypadkiem użycia jest powiadomienie o zdarzeniu. Na przykład usługa Azure Resource Manager zgłasza zdarzenia podczas tworzenia, modyfikowania lub usuwania zasobów. Subskrybentem tych zdarzeń może być aplikacja logiki, która wysyła wiadomości e-mail z alertami.
Producent zgłasza powiązane zdarzenia w sekwencji lub strumieniu zdarzeń w danym okresie. Zazwyczaj strumień jest używany do oceny statystycznej. Ocena może wystąpić w oknie czasowym lub w miarę nadejścia zdarzeń. Telemetria to typowy przypadek użycia (na przykład monitorowanie kondycji i obciążenia systemu). Innym przypadkiem jest przesyłanie strumieniowe zdarzeń z urządzeń IoT.
Typowym wzorcem implementowania komunikatów zdarzeń jest wzorzec wydawcy-subskrybenta .
Rola i zalety brokera komunikatów
Pośredni broker komunikatów zapewnia funkcjonalność przenoszenia komunikatów od producenta do konsumenta i może oferować więcej korzyści.
Odłączanie
Broker komunikatów rozdziela producenta od konsumenta w logice, która generuje i używa odpowiednio komunikatów. W złożonym przepływie pracy broker może zachęcić do oddzielenia operacji biznesowych i koordynowania przepływu pracy.
Na przykład jedna transakcja biznesowa wymaga odrębnych operacji wykonywanych w sekwencji logiki biznesowej. Producent wydaje polecenie, które sygnalizuje użytkownikowi uruchomienie operacji. Odbiorca potwierdza komunikat w oddzielnej kolejce zarezerwowanej do tworzenia kolejek w celu utworzenia odpowiedzi dla producenta. Dopiero po otrzymaniu odpowiedzi producent wysyła nowy komunikat, aby rozpocząć następną operację w sekwencji. Inny użytkownik przetwarza ten komunikat i wysyła komunikat ukończenia do kolejki odpowiedzi. Korzystając z komunikatów, usługi koordynują przepływ pracy transakcji między sobą.
Broker komunikatów zapewnia czasowe oddzielenie. Producent i konsument nie muszą działać współbieżnie. Producent może wysłać wiadomość do brokera komunikatów niezależnie od dostępności konsumenta. Z drugiej strony konsument nie jest ograniczony przez dostępność producenta.
Na przykład interfejs użytkownika aplikacji internetowej generuje komunikaty i używa kolejki jako brokera komunikatów. Gdy odbiorca jest gotowy, może pobrać komunikaty z kolejki i wykonać pracę. Rozdzielenie czasowe pomaga interfejsowi użytkownika zachować czas reakcji. Nie jest blokowany, gdy komunikaty są obsługiwane asynchronicznie.
Ukończenie niektórych operacji może potrwać długo. Po uruchomieniu polecenia producent nie powinien czekać, aż konsument go ukończy. Broker komunikatów pomaga asynchroniczne przetwarzanie komunikatów.
Równoważenie obciążenia
Producenci mogą publikować dużą liczbę komunikatów, które są obsługiwane przez wielu użytkowników. Użyj brokera komunikatów, aby dystrybuować przetwarzanie między serwerami i poprawić przepływność. Użytkownicy mogą uruchamiać na różnych serwerach, aby rozłożyć obciążenie. Użytkownicy mogą być dodawani dynamicznie w celu skalowania systemu w poziomie w razie potrzeby lub usunięcia w inny sposób.
Wzorzec konkurujących odbiorców wyjaśnia, jak przetwarzać wiele komunikatów jednocześnie w celu optymalizacji przepływności, zwiększenia skalowalności i dostępności oraz zrównoważenia obciążenia.
Bilansowanie obciążenia
Ilość komunikatów generowanych przez producenta lub grupę producentów może być zmienna. Czasami może wystąpić duży wolumin powodujący wzrost liczby komunikatów. Zamiast dodawać konsumentów do obsługi tej pracy, broker komunikatów może działać jako bufor, a konsumenci stopniowo opróżniają komunikaty we własnym tempie bez podkreślania systemu.
Wzorzec bilansowania obciążenia opartego na kolejce zawiera więcej informacji.
Niezawodna obsługa komunikatów
Broker komunikatów pomaga zagwarantować, że komunikaty nie zostaną utracone, nawet jeśli komunikacja nie powiedzie się między producentem a konsumentem. Producent może publikować komunikaty do brokera komunikatów, a użytkownik może je pobrać po ponownym opublikowaniu komunikacji. Producent nie zostanie zablokowany, chyba że utraci łączność z brokerem komunikatów.
Obsługa komunikatów odpornych
Broker komunikatów może dodać odporność do użytkowników w systemie. Jeśli użytkownik zakończy się niepowodzeniem podczas przetwarzania komunikatu, inne wystąpienie odbiorcy może przetworzyć ten komunikat. Ponowne przetwarzanie jest możliwe, ponieważ komunikat jest utrwalany w brokerze.
Wybór technologii dla brokera komunikatów
Platforma Azure udostępnia kilka usług brokera komunikatów, z których każdy ma szereg funkcji. Przed wybraniem usługi określ intencję i wymagania komunikatu.
Obsługa komunikatów usługi Azure Service Bus
Kolejki komunikatów usługi Azure Service Bus są odpowiednie do przenoszenia poleceń od producentów do użytkowników. Oto kilka zagadnień.
Model ściągania
Użytkownik kolejki usługi Service Bus stale sonduje usługę Service Bus, aby sprawdzić, czy są dostępne nowe komunikaty. Zestawy SDK klienta i wyzwalacz usługi Azure Functions dla usługi Service Bus abstrakcji tego modelu. Gdy jest dostępny nowy komunikat, wywołanie zwrotne odbiorcy jest wywoływane, a komunikat jest wysyłany do konsumenta.
Gwarantowane dostarczanie
Usługa Service Bus umożliwia użytkownikowi przeglądanie kolejki i blokowanie komunikatu od innych użytkowników.
Użytkownik ponosi odpowiedzialność za zgłaszanie stanu przetwarzania komunikatu. Tylko wtedy, gdy użytkownik oznaczy komunikat jako użyty, usługa Service Bus usuwa komunikat z kolejki. Jeśli wystąpi błąd, przekroczenie limitu czasu lub awaria, usługa Service Bus odblokuje komunikat, aby inni użytkownicy mogli go pobrać. W ten sposób komunikaty nie są tracone w transferze.
Producent może przypadkowo wysłać tę samą wiadomość dwa razy. Na przykład wystąpienie producenta kończy się niepowodzeniem po wysłaniu komunikatu. Inny producent zastępuje oryginalne wystąpienie i ponownie wysyła wiadomość. Kolejki usługi Azure Service Bus zapewniają wbudowaną funkcję usuwania zrzutów, która wykrywa i usuwa zduplikowane komunikaty. Nadal istnieje prawdopodobieństwo, że komunikat zostanie dostarczony dwa razy. Jeśli na przykład użytkownik ulegnie awarii podczas przetwarzania, komunikat zostanie zwrócony do kolejki i zostanie pobrany przez tego samego lub innego użytkownika. Logika przetwarzania komunikatów w odbiorcy powinna być idempotentna, tak aby nawet w przypadku powtórzenia pracy stan systemu nie został zmieniony.
Kolejność komunikatów
Jeśli chcesz, aby odbiorcy otrzymywali komunikaty w kolejności, w której są wysyłane, kolejki usługi Service Bus gwarantują pierwsze na pierwszym wyjęcie (FIFO) uporządkowane dostarczanie przy użyciu sesji. Sesja może zawierać co najmniej jeden komunikat. Komunikaty są skorelowane z właściwością SessionId . Komunikaty, które są częścią sesji, nigdy nie wygasają. Sesję można zablokować użytkownikowi, aby uniemożliwić obsługę komunikatów przez innego użytkownika.
Aby uzyskać więcej informacji, zobacz Sesje komunikatów.
Trwałość komunikatów
Kolejki usługi Service Bus obsługują oddzielenie czasowe. Nawet jeśli użytkownik nie jest dostępny lub nie może przetworzyć komunikatu, pozostaje w kolejce.
Długotrwałe transakcje punktu kontrolnego
Transakcje biznesowe mogą działać przez długi czas. Każda operacja w transakcji może zawierać wiele komunikatów. Użyj tworzenia punktów kontrolnych, aby koordynować przepływ pracy i zapewnić odporność w przypadku niepowodzenia transakcji.
Kolejki usługi Service Bus umożliwiają punktowanie kontrolne za pośrednictwem możliwości stanu sesji. Informacje o stanie są rejestrowane przyrostowo w kolejce (SetState) dla komunikatów należących do sesji. Na przykład użytkownik może śledzić postęp, sprawdzając stan (GetState) co jakiś czas. Jeśli konsument ulegnie awarii, inny konsument może użyć informacji o stanie, aby określić ostatni znany punkt kontrolny w celu wznowienia sesji.
Kolejka utraconych komunikatów (DLQ)
Kolejka usługi Service Bus ma domyślną kolejkę podrzędną o nazwie kolejka utraconych komunikatów (DLQ) do przechowywania komunikatów, których nie można dostarczyć ani przetworzyć. Usługa Service Bus lub logika przetwarzania komunikatów w odbiorcy może dodawać komunikaty do biblioteki DLQ. DlQ przechowuje komunikaty do momentu ich pobrania z kolejki.
Oto przykłady tego, kiedy komunikat może znajdować się w dlQ:
Komunikat trucizny jest komunikatem, który nie może być obsługiwany, ponieważ jest źle sformułowany lub zawiera nieoczekiwane informacje. W kolejkach usługi Service Bus można wykryć zatrute komunikaty, ustawiając właściwość MaxDeliveryCount kolejki. Jeśli liczba odebrania tego samego komunikatu przekracza tę wartość właściwości, usługa Service Bus przenosi komunikat do biblioteki DLQ.
Komunikat może już nie być istotny, jeśli nie jest przetwarzany w danym okresie. Kolejki usługi Service Bus umożliwiają producentowi publikowanie komunikatów za pomocą atrybutu time-to-live. Jeśli ten okres wygaśnie przed odebraniem komunikatu, komunikat zostanie umieszczony w dlQ.
Sprawdź komunikaty w dlQ, aby określić przyczynę błędu.
Rozwiązanie hybrydowe
Usługa Service Bus łączy lokalne systemy i rozwiązania w chmurze. Systemy lokalne są często trudne do osiągnięcia z powodu ograniczeń zapory. Zarówno producent, jak i odbiorca (może być lokalny lub w chmurze) może używać punktu końcowego kolejki usługi Service Bus jako punktu końcowego odbioru i listy rozwijanej dla komunikatów.
Wzorzec mostka obsługi komunikatów to inny sposób obsługi tych scenariuszy.
Tematy i subskrypcje
Usługa Service Bus obsługuje wzorzec Publisher-Subscriber za pośrednictwem tematów i subskrypcji usługi Service Bus.
Ta funkcja umożliwia producentowi emisję komunikatów do wielu odbiorców. Gdy temat odbiera komunikat, jest przekazywany do wszystkich subskrybowanych odbiorców. Opcjonalnie subskrypcja może mieć kryteria filtrowania, które umożliwiają użytkownikowi uzyskanie podzbioru komunikatów. Każdy odbiorca pobiera komunikaty z subskrypcji w podobny sposób do kolejki.
Aby uzyskać więcej informacji, zobacz Tematy dotyczące usługi Azure Service Bus.
Azure Event Grid
Zalecamy usługę Azure Event Grid dla zdarzeń dyskretnych. Usługa Event Grid jest zgodna ze wzorcem Publisher-Subscriber. Gdy źródła zdarzeń wyzwalają zdarzenia, są publikowane w tematach usługi Event Grid. Odbiorcy tych zdarzeń tworzą subskrypcje usługi Event Grid, określając typy zdarzeń i procedurę obsługi zdarzeń, która będzie przetwarzać zdarzenia. Jeśli nie ma subskrybentów, zdarzenia zostaną odrzucone. Każde zdarzenie może mieć wiele subskrypcji.
Model wypychania
Usługa Event Grid propaguje komunikaty do subskrybentów w modelu wypychania. Załóżmy, że masz subskrypcję usługi Event Grid z elementem webhook. Po nadejściu nowego zdarzenia usługa Event Grid publikuje zdarzenie w punkcie końcowym elementu webhook.
Integracja z platformą Azure
Wybierz usługę Event Grid, jeśli chcesz otrzymywać powiadomienia o zasobach platformy Azure. Wiele usług platformy Azure działa jako źródła zdarzeń, które mają wbudowane tematy usługi Event Grid. Usługa Event Grid obsługuje również różne usługi platformy Azure, które można skonfigurować jako programy obsługi zdarzeń. Subskrybowanie tych tematów jest łatwe w celu kierowania zdarzeń do wybranego programu obsługi zdarzeń. Możesz na przykład użyć usługi Event Grid, aby wywołać funkcję platformy Azure po utworzeniu lub usunięciu magazynu obiektów blob.
Tematy niestandardowe
Utwórz niestandardowe tematy usługi Event Grid, jeśli chcesz wysyłać zdarzenia z aplikacji lub usługi platformy Azure, która nie jest zintegrowana z usługą Event Grid.
Aby na przykład zobaczyć postęp całej transakcji biznesowej, chcesz, aby uczestniczące usługi zgłaszały zdarzenia podczas przetwarzania poszczególnych operacji biznesowych. Aplikacja internetowa wyświetla te zdarzenia. Jednym ze sposobów wykonania tego zadania jest utworzenie tematu niestandardowego i dodanie subskrypcji z aplikacją internetową zarejestrowaną za pomocą elementu webhook HTTP. Ponieważ usługi biznesowe wysyłają zdarzenia do tematu niestandardowego, usługa Event Grid wypycha je do aplikacji internetowej.
Przefiltrowane zdarzenia
Filtry można określić w subskrypcji, aby poinstruować usługę Event Grid o kierowanie tylko podzbioru zdarzeń do określonej procedury obsługi zdarzeń. Filtry należy określić w schemacie subskrypcji. Każde zdarzenie wysyłane do tematu z wartościami zgodnymi z filtrem jest automatycznie przekazywane do tej subskrypcji.
Na przykład zawartość w różnych formatach jest przesyłana do usługi Blob Storage. Za każdym razem, gdy plik jest dodawany, zdarzenie jest zgłaszane i publikowane w usłudze Event Grid. Subskrypcja zdarzeń może mieć filtr, który wysyła tylko zdarzenia dla obrazów, aby program obsługi zdarzeń mógł wygenerować miniatury.
Aby uzyskać więcej informacji na temat filtrowania, zobacz Filtrowanie zdarzeń dla usługi Event Grid.
Wysoka przepływność
Usługa Event Grid może kierować 10 000 000 zdarzeń na sekundę na region. Pierwsze 100 000 operacji w danym miesiącu jest bezpłatnych. Aby zapoznać się z zagadnieniami dotyczącymi kosztów, zobacz Ile kosztuje usługa Event Grid?
Odporne dostarczanie
Mimo że pomyślne dostarczanie zdarzeń nie jest tak kluczowe, jak polecenia, nadal możesz chcieć mieć pewną gwarancję w zależności od typu zdarzenia. Usługa Event Grid oferuje funkcje, które można włączyć i dostosować, takie jak zasady ponawiania prób, czas wygaśnięcia i utracony zapis. Aby uzyskać więcej informacji, zobacz Dostarczanie komunikatów usługi Event Grid i ponawianie próby.
Proces ponawiania prób usługi Event Grid może pomóc w odporności, ale nie jest bezpieczny w przypadku awarii. W procesie ponawiania próby usługa Event Grid może dostarczyć komunikat więcej niż raz, pominąć lub opóźnić próby, jeśli punkt końcowy nie odpowiada przez długi czas. Aby uzyskać więcej informacji, zobacz Harmonogram ponawiania prób.
Zdarzenia nieużywane można utrwalać na koncie magazynu obiektów blob, włączając zapisywanie utraconych komunikatów. Występuje opóźnienie dostarczania komunikatu do punktu końcowego magazynu obiektów blob, a jeśli ten punkt końcowy nie odpowiada, usługa Event Grid odrzuca zdarzenie. Aby uzyskać więcej informacji, zobacz Ustawianie lokalizacji utraconych komunikatów i zasad ponawiania prób.
Azure Event Hubs
Podczas pracy ze strumieniem zdarzeń usługa Azure Event Hubs jest zalecanym brokerem komunikatów . Zasadniczo jest to duży bufor, który może odbierać duże ilości danych z małym opóźnieniem. Odebrane dane można szybko odczytywać za pomocą operacji współbieżnych. Odebrane dane można przekształcić przy użyciu dowolnego dostawcy analizy w czasie rzeczywistym. Usługa Event Hubs zapewnia również możliwość przechowywania zdarzeń na koncie magazynu.
Szybkie pozyskiwanie
Usługa Event Hubs może pozyskiwać miliony zdarzeń na sekundę. Zdarzenia są dołączane tylko do strumienia i uporządkowane według czasu.
Model ściągania
Podobnie jak usługa Event Grid, usługa Event Hubs oferuje również możliwości wydawcy-subskrybenta. Kluczową różnicą między usługą Event Grid i usługą Event Hubs jest sposób udostępniania danych zdarzeń subskrybentom. Usługa Event Grid wypycha pozyskane dane do subskrybentów, podczas gdy usługa Event Hubs udostępnia dane w modelu ściągania. W miarę odbierania zdarzeń usługa Event Hubs dołącza je do strumienia. Subskrybent zarządza kursorem i może przejść do przodu i z powrotem w strumieniu, wybrać przesunięcie czasu i odtworzyć sekwencję w swoim tempie.
Procesory strumieni to subskrybenci, którzy pobierają dane z usługi Event Hubs na potrzeby transformacji i analizy statystycznej. Usługa Azure Stream Analytics i platforma Apache Spark umożliwiają przetwarzanie złożone, takie jak agregacja w czasie lub wykrywanie anomalii.
Jeśli chcesz wykonywać działania na poszczególnych partycjach, możesz ściągnąć dane przy użyciu hosta procesora zdarzeń lub za pomocą wbudowanego łącznika, takiego jak usługa Azure Logic Apps , aby zapewnić logikę przekształcania. Inną opcją jest użycie usługi Azure Functions.
Partycjonowanie
Partycja jest częścią strumienia zdarzeń. Zdarzenia są podzielone przy użyciu klucza partycji. Na przykład kilka urządzeń IoT wysyła dane urządzenia do centrum zdarzeń. Klucz partycji jest identyfikatorem urządzenia. W miarę pozyskiwania zdarzeń usługa Event Hubs przenosi je do oddzielnych partycji. W każdej partycji wszystkie zdarzenia są uporządkowane według czasu.
Użytkownik to wystąpienie kodu, które przetwarza dane zdarzenia. Usługa Event Hubs jest zgodna ze wzorcem partycjonowanego konsumenta. Każdy użytkownik odczytuje tylko określoną partycję. Posiadanie wielu partycji powoduje szybsze przetwarzanie, ponieważ strumień może być odczytywany współbieżnie przez wielu odbiorców.
Wystąpienia tego samego konsumenta tworzą pojedynczą grupę odbiorców. Wiele grup odbiorców może odczytywać ten sam strumień z różnymi intencjami. Załóżmy, że strumień zdarzeń zawiera dane z czujnika temperatury. Jedna grupa odbiorców może odczytać strumień w celu wykrycia anomalii, takich jak wzrost temperatury. Inny może odczytać ten sam strumień, aby obliczyć średnią temperaturę kroczącą w oknie czasowym.
Usługa Event Hubs obsługuje wzorzec wydawcy-subskrybenta, zezwalając na wiele grup odbiorców. Każda grupa odbiorców jest subskrybentem.
Aby uzyskać więcej informacji na temat partycjonowania usługi Event Hubs, zobacz Partitions (Partycje).
Event Hubs Capture
Funkcja przechwytywania umożliwia przechowywanie strumienia zdarzeń w usłudze Azure Blob Storage lub Data Lake Storage. Ten sposób przechowywania zdarzeń jest niezawodny, ponieważ nawet jeśli konto magazynu nie jest dostępne, funkcja Przechwytywanie przechowuje dane przez pewien okres, a następnie zapisuje dane w magazynie po jej udostępnieniu.
Usługi magazynu mogą również oferować dodatkowe funkcje do analizowania zdarzeń. Na przykład dzięki wykorzystaniu warstw dostępu konta magazynu obiektów blob można przechowywać zdarzenia w warstwie Gorąca dla danych wymagających częstego dostępu. Te dane mogą być używane do wizualizacji. Alternatywnie możesz przechowywać dane w warstwie archiwum i pobierać je od czasu do czasu na potrzeby inspekcji.
Przechwytywanie przechowuje wszystkie zdarzenia pozyskiwane przez usługę Event Hubs i jest przydatne do przetwarzania wsadowego. Raporty dotyczące danych można wygenerować przy użyciu funkcji MapReduce. Przechwycone dane mogą również służyć jako źródło prawdy. Jeśli podczas agregowania danych pominięto pewne fakty, możesz odwołać się do przechwyconych danych.
Aby uzyskać szczegółowe informacje na temat tej funkcji, zobacz Przechwytywanie zdarzeń za pośrednictwem usługi Azure Event Hubs w usłudze Azure Blob Storage lub Azure Data Lake Storage.
Obsługa klientów platformy Apache Kafka
Usługa Event Hubs udostępnia punkt końcowy dla klientów platformy Apache Kafka . Istniejący klienci mogą zaktualizować konfigurację, aby wskazać punkt końcowy i rozpocząć wysyłanie zdarzeń do usługi Event Hubs. Nie musisz wprowadzać żadnych zmian w kodzie.
Aby uzyskać więcej informacji, zobacz Event Hubs for Apache Kafka (Usługa Event Hubs dla platformy Apache Kafka).
Scenariusze crossover
W niektórych przypadkach korzystne jest połączenie dwóch usług obsługi komunikatów.
Łączenie usług może zwiększyć wydajność systemu obsługi komunikatów. Na przykład w transakcji biznesowej kolejki usługi Azure Service Bus służą do obsługi komunikatów. Kolejki, które są w większości bezczynne i odbierane od czasu do czasu, są nieefektywne, ponieważ użytkownik stale sonduje kolejkę pod kątem nowych komunikatów. Subskrypcję usługi Event Grid można skonfigurować za pomocą funkcji platformy Azure jako procedury obsługi zdarzeń. Za każdym razem, gdy kolejka odbiera komunikat i nie ma odbiorców nasłuchujących, usługa Event Grid wysyła powiadomienie, które wywołuje funkcję platformy Azure, która opróżnia kolejkę.
Aby uzyskać szczegółowe informacje na temat łączenia usługi Service Bus z usługą Event Grid, zobacz Omówienie integracji usługi Azure Service Bus z usługą Event Grid.
Integracja przedsiębiorstwa z użyciem kolejek komunikatów i architektury referencyjnej zdarzeń pokazuje implementację integracji usługi Service Bus z usługą Event Grid.
Oto inny przykład: usługa Event Grid odbiera zestaw zdarzeń, w których niektóre zdarzenia wymagają przepływu pracy, podczas gdy inne są przeznaczone do powiadamiania. Metadane komunikatu wskazują typ zdarzenia. Jednym ze sposobów odróżnienia jest sprawdzenie metadanych przy użyciu funkcji filtrowania w subskrypcji zdarzeń. Jeśli wymaga przepływu pracy, usługa Event Grid wysyła ją do kolejki usługi Azure Service Bus. Odbiorniki tej kolejki mogą podejmować niezbędne działania. Zdarzenia powiadomień są wysyłane do usługi Logic Apps w celu wysyłania wiadomości e-mail z alertami.
Powiązane wzorce
Podczas implementowania asynchronicznych komunikatów należy wziąć pod uwagę następujące wzorce:
- Wzorzec konkurujących odbiorców. Wielu użytkowników może wymagać konkurowania w celu odczytywania komunikatów z kolejki. W tym wzorcu wyjaśniono, jak przetwarzać wiele komunikatów jednocześnie w celu optymalizacji przepływności, zwiększenia skalowalności i dostępności oraz równoważenia obciążenia.
- Wzorzec kolejki priorytetowej. W przypadkach, gdy logika biznesowa wymaga przetworzenia niektórych komunikatów przed innymi, ten wzorzec opisuje sposób odbierania i przetwarzania komunikatów o wyższym priorytetu przez producenta niż komunikaty o niższym priorytcie.
- Wzorzec wyrównywania obciążeń przy użyciu kolejki. Ten wzorzec używa brokera komunikatów do działania jako buforu między producentem a konsumentem, aby pomóc zminimalizować wpływ na dostępność i czas reakcji sporadycznie dużych obciążeń dla obu tych jednostek.
- Wzorzec ponawiania. Producent lub konsument nie może nawiązać połączenia z kolejką, ale przyczyny tego błędu mogą być tymczasowe i szybko przekazywane. W tym wzorcu opisano sposób obsługi tej sytuacji w celu dodania odporności do aplikacji.
- Wzorzec nadzorcy agenta harmonogramu. Obsługa komunikatów jest często używana w ramach implementacji przepływu pracy. Ten wzorzec pokazuje, jak obsługa komunikatów może koordynować zestaw akcji w rozproszonym zestawie usług i innych zasobów zdalnych oraz umożliwić systemowi odzyskiwanie i ponawianie akcji, które kończą się niepowodzeniem.
- Wzorzec choreografii. Ten wzorzec pokazuje, jak usługi mogą używać komunikatów do kontrolowania przepływu pracy transakcji biznesowej.
- Wzorzec sprawdzania oświadczeń. Ten wzorzec pokazuje, jak podzielić duży komunikat na sprawdzanie oświadczenia i ładunek.