Komunikacja między usługami
Napiwek
Ta zawartość jest fragmentem książki eBook, Architekting Cloud Native .NET Applications for Azure, dostępnej na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.
Przechodząc z klienta frontonu, teraz adresujemy mikrousługi zaplecza komunikują się ze sobą.
Podczas tworzenia aplikacji natywnej dla chmury warto być wrażliwa na sposób komunikowania się usług zaplecza ze sobą. W idealnym przypadku tym mniej komunikacji między usługami tym lepiej. Jednak unikanie nie zawsze jest możliwe, ponieważ usługi zaplecza często polegają na sobie, aby ukończyć operację.
Istnieje kilka powszechnie akceptowanych podejść do implementowania komunikacji między usługami. Typ interakcji komunikacji często określa najlepsze podejście.
Rozważ następujące typy interakcji:
Zapytanie — jeśli wywołanie mikrousługi wymaga odpowiedzi z wywoływanej mikrousługi, takiej jak "Hej, podaj mi informacje o nabywcy dla danego identyfikatora klienta".
Polecenie — gdy wywołanie mikrousługi wymaga innej mikrousługi do wykonania akcji, ale nie wymaga odpowiedzi, takiej jak "Hej, po prostu wyślij tę kolejność".
Zdarzenie — gdy mikrousługa, nazywana wydawcą, zgłasza zdarzenie, które uległo zmianie lub wystąpiła akcja. Inne mikrousługi, nazywane subskrybentami, którzy są zainteresowani, mogą odpowiednio reagować na zdarzenie. Wydawca i subskrybenci nie znają się nawzajem.
Systemy mikrousług zwykle używają kombinacji tych typów interakcji podczas wykonywania operacji wymagających interakcji między usługami. Przyjrzyjmy się bliżej każdemu z nich i sposobom ich implementacji.
Zapytania
Wiele razy jedna mikrousługa może wymagać wykonania zapytania względem innej, co wymaga natychmiastowej odpowiedzi na ukończenie operacji. Mikrousługa koszyka zakupów może potrzebować informacji o produkcie i cenie, aby dodać przedmiot do koszyka. Istnieje wiele metod implementowania operacji zapytań.
Obsługa komunikatów żądań/odpowiedzi
Jedną z opcji implementacji tego scenariusza jest wywołanie mikrousługi zaplecza w celu wysyłania bezpośrednich żądań HTTP do mikrousług, które muszą wykonywać zapytania, pokazane na rysunku 4-8.
Rysunek 4–8. Bezpośrednia komunikacja HTTP
Chociaż bezpośrednie wywołania HTTP między mikrousługami są stosunkowo proste do zaimplementowania, należy zadbać o zminimalizowanie tej praktyki. Aby rozpocząć, te wywołania są zawsze synchroniczne i blokują operację do momentu zwrócenia wyniku lub limitu czasu żądania. To, co było kiedyś samodzielne, niezależne usługi, w stanie rozwijać się niezależnie i wdrażać często, teraz stają się powiązane ze sobą. Wraz ze wzrostem sprzężenia między mikrousługami ich korzyści architektoniczne maleją.
Wykonanie rzadkiego żądania, które sprawia, że pojedyncze bezpośrednie wywołanie HTTP do innej mikrousługi może być akceptowalne dla niektórych systemów. Jednak wywołania o dużej ilości, które wywołują bezpośrednie wywołania HTTP do wielu mikrousług, nie są zalecane. Mogą one zwiększyć opóźnienia i negatywnie wpłynąć na wydajność, skalowalność i dostępność systemu. Co gorsza, długa seria bezpośredniej komunikacji HTTP może prowadzić do głębokich i złożonych łańcuchów synchronicznych wywołań mikrousług, pokazanych na rysunku 4-9:
Rysunek 4–9. Łączenie łańcuchów zapytań HTTP
Z pewnością można sobie wyobrazić ryzyko w projekcie pokazanym na poprzedniej ilustracji. Co się stanie, jeśli krok 3 zakończy się niepowodzeniem? Lub krok 8 kończy się niepowodzeniem? Jak można odzyskać? Co zrobić, jeśli krok 6 jest powolny, ponieważ podstawowa usługa jest zajęta? Jak kontynuować? Nawet jeśli wszystkie działają prawidłowo, pomyśl o opóźnieniu, które spowoduje naliczenie tego wywołania, co jest sumą opóźnienia każdego kroku.
Duży stopień sprzężenia na poprzedniej ilustracji sugeruje, że usługi nie zostały optymalnie modelowane. Zespół musiałby ponownie wrócić do swojego projektu.
Wzorzec zmaterializowanego widoku
Popularną opcją usuwania sprzężenia mikrousług jest wzorzec zmaterializowanego widoku. Za pomocą tego wzorca mikrousługi przechowuje własną lokalną, zdenormalizowaną kopię danych należących do innych usług. Zamiast mikrousługi Koszyk zakupów wykonuje zapytania dotyczące mikrousług Katalogu produktów i Cen, utrzymuje własną lokalną kopię tych danych. Ten wzorzec eliminuje niepotrzebne sprzęganie i poprawia niezawodność i czas odpowiedzi. Cała operacja jest wykonywana wewnątrz jednego procesu. Badamy ten wzorzec i inne kwestie związane z danymi w rozdziale 5.
Wzorzec agregatora usług
Inną opcją wyeliminowania sprzężenia mikrousług do mikrousług jest mikrousługa agregatora, pokazana na fioletowo na rysunku 4-10.
Rysunek 4–10. Mikrousługi agregatora
Wzorzec izoluje operację, która wykonuje wywołania wielu mikrousług zaplecza, scentralizowanie jej logiki w wyspecjalizowaną mikrousługę. Purpurowa mikrousługa agregatora wyewidencjonowania na poprzedniej ilustracji organizuje przepływ pracy dla operacji wyewidencjonowania. Obejmuje ona wywołania kilku mikrousług zaplecza w kolejności sekwencyjnej. Dane z przepływu pracy są agregowane i zwracane do obiektu wywołującego. Mimo że nadal implementuje bezpośrednie wywołania HTTP, mikrousługa agregatora zmniejsza bezpośrednie zależności między mikrousługami zaplecza.
Wzorzec żądania/odpowiedzi
Innym podejściem do oddzielenia synchronicznych komunikatów HTTP jest wzorzec żądania i odpowiedzi, który używa komunikacji kolejkowania. Komunikacja przy użyciu kolejki jest zawsze kanałem jednokierunkowym, a producent wysyła komunikat i odbiorca odbierający go. W tym wzorcu zaimplementowano zarówno kolejkę żądań, jak i kolejkę odpowiedzi, pokazaną na rysunku 4–11.
Rysunek 4–11. Wzorzec odpowiedzi na żądanie
W tym miejscu producent komunikatu tworzy komunikat oparty na zapytaniach zawierający unikatowy identyfikator korelacji i umieszcza go w kolejce żądań. Usługa korzystająca dequeuuje komunikaty, przetwarza je i umieszcza odpowiedź w kolejce odpowiedzi o tym samym identyfikatorze korelacji. Usługa producenta dequeuuje komunikat, dopasuje go do identyfikatora korelacji i kontynuuje przetwarzanie. W następnej sekcji szczegółowo omówiono kolejki.
Polecenia
Innym typem interakcji komunikacji jest polecenie. Mikrousługa może wymagać innej mikrousługi do wykonania akcji. Mikrousługa zamawiania może wymagać mikrousługi Wysyłka, aby utworzyć przesyłkę dla zatwierdzonego zamówienia. Na rysunku 4–12 jedna mikrousługa, nazywana producentem, wysyła komunikat do innej mikrousługi, konsumenta, wysyłając polecenie, aby coś zrobić.
Rysunek 4–12. Interakcja poleceń z kolejką
Najczęściej producent nie wymaga odpowiedzi i może wyzwolić komunikat. Jeśli potrzebna jest odpowiedź, odbiorca wysyła oddzielną wiadomość z powrotem do producenta w innym kanale. Komunikat polecenia najlepiej wysyłać asynchronicznie z kolejką komunikatów. obsługiwane przez lekkiego brokera komunikatów. Na poprzednim diagramie zwróć uwagę, jak kolejka oddziela obie usługi i oddziela je od siebie.
Ponieważ wiele kolejek komunikatów może wysyłać ten sam komunikat więcej niż raz, znany jako co najmniej jednokrotne dostarczanie, konsument musi mieć możliwość prawidłowego identyfikowania i obsługi tych scenariuszy przy użyciu odpowiednich wzorców przetwarzania komunikatów idempotentnych.
Kolejka komunikatów to pośrednia konstrukcja, za pomocą której producent i odbiorca przekazują komunikat. Kolejki implementują asynchroniczny wzorzec obsługi komunikatów typu punkt-punkt. Producent wie, gdzie należy wysłać polecenie i odpowiednio kierowania. Kolejka gwarantuje, że komunikat jest przetwarzany przez dokładnie jedno z wystąpień odbiorców odczytywanych z kanału. W tym scenariuszu producent lub usługa konsumenta może skalować w poziomie bez wpływu na drugą. Ponadto technologie mogą być różne po każdej stronie, co oznacza, że możemy mieć mikrousługę Java wywołującą mikrousługę języka Golang .
W rozdziale 1 omówiliśmy usługi zapasowe. Usługi pomocnicze są zasobami pomocniczymi, od których zależą systemy natywne dla chmury. Kolejki komunikatów są usługami zapasowymi. Chmura platformy Azure obsługuje dwa typy kolejek komunikatów, które systemy natywne dla chmury mogą wykorzystywać do implementowania komunikatów poleceń: kolejki usługi Azure Storage i kolejki usługi Azure Service Bus.
Kolejki usługi Azure Storage
Kolejki usługi Azure Storage oferują prostą infrastrukturę kolejkowania, która jest szybka, przystępna cenowo i wspierana przez konta usługi Azure Storage.
Kolejki usługi Azure Storage oferują mechanizm kolejkowania oparty na protokole REST z niezawodną i trwałą obsługą komunikatów. Zapewniają one minimalny zestaw funkcji, ale są niedrogie i przechowują miliony wiadomości. Ich zakresy pojemności do 500 TB. Pojedynczy komunikat może mieć rozmiar do 64 KB.
Dostęp do komunikatów z dowolnego miejsca na świecie można uzyskać za pośrednictwem uwierzytelnionych wywołań przy użyciu protokołu HTTP lub HTTPS. Kolejki magazynu mogą być skalowane w poziomie do dużej liczby równoczesnych klientów w celu obsługi skoków ruchu.
Oznacza to, że istnieją ograniczenia dotyczące usługi:
Kolejność komunikatów nie jest gwarantowana.
Komunikat może być utrwalany tylko przez siedem dni, zanim zostanie automatycznie usunięty.
Obsługa zarządzania stanem, wykrywania duplikatów lub transakcji nie jest dostępna.
Rysunek 4–13 przedstawia hierarchię kolejki usługi Azure Storage.
Rysunek 4–13. Hierarchia kolejek magazynu
Na poprzedniej ilustracji zwróć uwagę, jak kolejki magazynu przechowują komunikaty na bazowym koncie usługi Azure Storage.
Dla deweloperów firma Microsoft udostępnia kilka bibliotek po stronie klienta i serwera na potrzeby przetwarzania kolejek usługi Storage. Większość głównych platform jest obsługiwana, w tym .NET, Java, JavaScript, Ruby, Python i Go. Deweloperzy nigdy nie powinni komunikować się bezpośrednio z tymi bibliotekami. W ten sposób ściśle połączy kod mikrousługi z usługą Azure Storage Queue Service. Lepszym rozwiązaniem jest odizolowanie szczegółów implementacji interfejsu API. Wprowadzenie do warstwy pośredniczącej lub pośredniego interfejsu API, która uwidacznia ogólne operacje i hermetyzuje konkretną bibliotekę. To luźne sprzężenie umożliwia zamianę jednej usługi kolejkowania dla innej bez konieczności wprowadzania zmian w kodzie usługi mainline.
Kolejki usługi Azure Storage to ekonomiczna opcja implementowania komunikatów poleceń w aplikacjach natywnych dla chmury. Szczególnie gdy rozmiar kolejki przekroczy 80 GB lub prosty zestaw funkcji jest akceptowalny. Płacisz tylko za przechowywanie wiadomości; nie są naliczane opłaty godzinowe.
Kolejki usługi Azure Service Bus
Aby uzyskać bardziej złożone wymagania dotyczące obsługi komunikatów, rozważ kolejki usługi Azure Service Bus.
Na szczycie niezawodnej infrastruktury komunikatów usługa Azure Service Bus obsługuje model obsługi komunikatów obsługiwanych przez brokera. Komunikaty są niezawodnie przechowywane w brokerze (kolejce) do momentu odebrania przez konsumenta. Kolejka gwarantuje dostarczanie komunikatów first-in/First-Out (FIFO), szanując kolejność dodawania komunikatów do kolejki.
Rozmiar komunikatu może być znacznie większy, do 256 KB. Komunikaty są utrwalane w kolejce przez nieograniczony czas. Usługa Service Bus obsługuje nie tylko wywołania oparte na protokole HTTP, ale także zapewnia pełną obsługę protokołu AMQP. AmQP to otwarty standard dla dostawców, który obsługuje protokół binarny i wyższy stopień niezawodności.
Usługa Service Bus udostępnia bogaty zestaw funkcji, w tym obsługę transakcji i funkcję wykrywania duplikatów. Kolejka gwarantuje "co najwyżej jednokrotne dostarczanie" na komunikat. Automatycznie odrzuca komunikat, który został już wysłany. Jeśli producent ma wątpliwości, może ponownie wysłać ten sam komunikat, a usługa Service Bus gwarantuje, że zostanie przetworzona tylko jedna kopia. Wykrywanie duplikatów zwalnia z konieczności tworzenia dodatkowej instalacji wodociągowej infrastruktury.
Dwie kolejne funkcje przedsiębiorstwa to partycjonowanie i sesje. Tradycyjna kolejka usługi Service Bus jest obsługiwana przez jednego brokera komunikatów i przechowywana w jednym magazynie komunikatów. Jednak partycjonowanie usługi Service Bus rozkłada kolejkę na wiele brokerów komunikatów i magazynów komunikatów. Ogólna przepływność nie jest już ograniczona przez wydajność pojedynczego brokera komunikatów lub magazynu komunikatów. Tymczasowa awaria magazynu komunikatów nie powoduje niedostępności partycjonowanej kolejki.
Sesje usługi Service Bus umożliwiają grupowanie komunikatów. Wyobraź sobie scenariusz przepływu pracy, w którym komunikaty muszą być przetwarzane razem i operacja zakończona na końcu. Aby można było korzystać, sesje muszą być jawnie włączone dla kolejki, a każdy powiązany komunikat musi zawierać ten sam identyfikator sesji.
Istnieją jednak pewne ważne zastrzeżenia: rozmiar kolejek usługi Service Bus jest ograniczony do 80 GB, co jest znacznie mniejsze niż to, co jest dostępne w kolejkach sklepu. Ponadto kolejki usługi Service Bus generują podstawowy koszt i opłaty za operację.
Rysunek 4–14 przedstawia architekturę wysokiego poziomu kolejki usługi Service Bus.
Rysunek 4–14. Kolejka usługi Service Bus
Na poprzedniej ilustracji zwróć uwagę na relację punkt-punkt. Dwa wystąpienia tego samego dostawcy umieszczają komunikaty w kolejce do jednej kolejki usługi Service Bus. Każdy komunikat jest używany tylko przez jedno z trzech wystąpień konsumentów po prawej stronie. Następnie omówimy sposób implementowania komunikatów, w których wszyscy użytkownicy mogą być zainteresowani tym samym komunikatem.
Zdarzenia
Kolejkowanie komunikatów to skuteczny sposób implementacji komunikacji, w której producent może asynchronicznie wysyłać użytkownikowi komunikat. Co się jednak stanie, gdy wielu różnych odbiorców jest zainteresowanych tym samym komunikatem? Dedykowana kolejka komunikatów dla każdego konsumenta nie będzie dobrze skalowana i stanie się trudna do zarządzania.
Aby rozwiązać ten scenariusz, przechodzimy do trzeciego typu interakcji komunikatów, zdarzenia. Jedna mikrousługa ogłasza, że wystąpiła akcja. Inne mikrousługi, jeśli są zainteresowane, reagują na akcję lub zdarzenie. Jest to również nazywane stylem architektury opartej na zdarzeniach.
Zdarzenie jest procesem dwuetapowym. W przypadku danej zmiany stanu mikrousługa publikuje zdarzenie w brokerze komunikatów, udostępniając je innym zainteresowanym mikrousługom. Zainteresowana mikrousługa jest powiadamiana przez subskrybowanie zdarzenia w brokerze komunikatów. Wzorzec publikowania/subskrybowania służy do implementowania komunikacji opartej na zdarzeniach.
Rysunek 4–15 przedstawia mikrousługę koszyka zakupów publikując zdarzenie z dwoma innymi mikrousługami subskrybowanymi.
Rysunek 4–15. Obsługa komunikatów sterowanych zdarzeniami
Zwróć uwagę na składnik magistrali zdarzeń, który znajduje się w środku kanału komunikacyjnego. Jest to klasa niestandardowa, która hermetyzuje brokera komunikatów i rozdziela go z podstawowej aplikacji. Mikrousługi zamawiania i inwentaryzacji niezależnie obsługują zdarzenie bez znajomości siebie ani mikrousługi koszyka zakupów. Po opublikowaniu zarejestrowanego zdarzenia w magistrali zdarzeń działają na nim.
Dzięki zdarzeniu przechodzimy z technologii kolejkowania do tematów. Temat jest podobny do kolejki, ale obsługuje wzorzec obsługi komunikatów jeden do wielu. Jedna mikrousługa publikuje komunikat. Wiele subskrybujących mikrousług może wybrać odbieranie i wykonywanie działań na podstawie tego komunikatu. Rysunek 4–16 przedstawia architekturę tematu.
Rysunek 4–16. Architektura tematu
Na poprzedniej ilustracji wydawcy wysyłają komunikaty do tematu. Na koniec subskrybenci otrzymują komunikaty z subskrypcji. W środku temat przekazuje komunikaty do subskrypcji na podstawie zestawu reguł wyświetlanych w ciemnoniebieskim polu. Reguły działają jako filtr, który przekazuje określone komunikaty do subskrypcji. W tym miejscu zdarzenie "GetPrice" zostanie wysłane do subskrypcji cen i rejestrowania, ponieważ subskrypcja rejestrowania wybrała odbieranie wszystkich komunikatów. Zdarzenie "GetInformation" zostanie wysłane do informacji i subskrypcji rejestrowania.
Chmura platformy Azure obsługuje dwie różne usługi tematów: Tematy usługi Azure Service Bus i Azure EventGrid.
Tematy usługi Azure Service Bus
Na podstawie tego samego niezawodnego modelu komunikatów obsługiwanych przez brokera kolejek usługi Azure Service Bus znajdują się tematy usługi Azure Service Bus. Temat może odbierać komunikaty od wielu niezależnych wydawców i wysyłać komunikaty do maksymalnie 2000 subskrybentów. Subskrypcje można dynamicznie dodawać lub usuwać w czasie wykonywania bez zatrzymywania systemu lub ponownego tworzenia tematu.
Wiele zaawansowanych funkcji z kolejek usługi Azure Service Bus jest również dostępnych dla tematów, takich jak obsługa wykrywania duplikatów i transakcji. Domyślnie tematy usługi Service Bus są obsługiwane przez jednego brokera komunikatów i przechowywane w jednym magazynie komunikatów. Jednak partycjonowanie usługi Service Bus skaluje temat, rozpowszechniając go w wielu brokerach komunikatów i magazynach komunikatów.
Zaplanowane dostarczanie komunikatów taguje komunikat o określonym czasie przetwarzania. Komunikat nie pojawi się w temacie przed tym czasem. Odroczenie komunikatu umożliwia odroczenie pobierania komunikatu do późniejszego czasu. Oba są często używane w scenariuszach przetwarzania przepływu pracy, w których operacje są przetwarzane w określonej kolejności. Przetwarzanie odebranych komunikatów można odroczyć do czasu ukończenia poprzedniej pracy.
Tematy usługi Service Bus to niezawodna i sprawdzona technologia umożliwiająca publikowanie/subskrybowanie komunikacji w systemach natywnych dla chmury.
Azure Event Grid
Chociaż usługa Azure Service Bus jest brokerem obsługi komunikatów testowanych pod kątem walki z pełnym zestawem funkcji przedsiębiorstwa, usługa Azure Event Grid jest nowym dzieckiem w bloku.
Na pierwszy rzut oka usługa Event Grid może wyglądać podobnie do innego systemu obsługi komunikatów opartych na temacie. Jednak różni się na wiele sposobów. Koncentruje się na obciążeniach opartych na zdarzeniach, umożliwia przetwarzanie zdarzeń w czasie rzeczywistym, głęboką integrację platformy Azure i otwartą platformę — wszystko w infrastrukturze bezserwerowej. Jest ona przeznaczona dla nowoczesnych aplikacji natywnych dla chmury i bezserwerowych
Jako scentralizowane zaplecze lub potok zdarzeń usługa Event Grid reaguje na zdarzenia wewnątrz zasobów platformy Azure i z własnych usług.
Powiadomienia o zdarzeniach są publikowane w temacie usługi Event Grid, który z kolei kieruje każde zdarzenie do subskrypcji. Subskrybenci mapować na subskrypcje i korzystać ze zdarzeń. Podobnie jak usługa Service Bus, usługa Event Grid obsługuje filtrowany model subskrybenta, w którym subskrypcja ustawia regułę dla zdarzeń, które chce otrzymywać. Usługa Event Grid zapewnia szybką przepływność z gwarancją 10 milionów zdarzeń na sekundę, umożliwiając dostarczanie niemal w czasie rzeczywistym — znacznie więcej niż to, co usługa Azure Service Bus może wygenerować.
Słodkim miejscem dla usługi Event Grid jest głęboka integracja z siecią szkieletową infrastruktury platformy Azure. Zasób platformy Azure, taki jak Cosmos DB, może publikować wbudowane zdarzenia bezpośrednio w innych zainteresowanych zasobach platformy Azure — bez konieczności używania kodu niestandardowego. Usługa Event Grid może publikować zdarzenia z subskrypcji platformy Azure, grupy zasobów lub usługi, zapewniając deweloperom szczegółową kontrolę nad cyklem życia zasobów w chmurze. Jednak usługa Event Grid nie jest ograniczona do platformy Azure. Jest to otwarta platforma, która może korzystać z niestandardowych zdarzeń HTTP publikowanych z aplikacji lub usług innych firm i kierować zdarzenia do zewnętrznych subskrybentów.
Podczas publikowania i subskrybowania zdarzeń natywnych z zasobów platformy Azure nie jest wymagane kodowanie. Dzięki prostej konfiguracji można zintegrować zdarzenia z jednego zasobu platformy Azure do innego przy użyciu wbudowanej instalacji hydraulicznej tematów i subskrypcji. Rysunek 4–17 przedstawia anatomię usługi Event Grid.
Rysunek 4–17. Anatomia usługi Event Grid
Główną różnicą między usługą EventGrid i usługą Service Bus jest podstawowy wzorzec wymiany komunikatów.
Usługa Service Bus implementuje starszy model ściągania stylu, w którym subskrybent podrzędny aktywnie sonduje subskrypcję tematu pod kątem nowych komunikatów. To podejście daje subskrybentowi pełną kontrolę nad tempem przetwarzania komunikatów. Określa, kiedy i ile komunikatów ma być przetwarzanych w danym momencie. Nieprzeczytane komunikaty pozostają w subskrypcji do momentu przetworzenia. Znaczącym brakiem jest opóźnienie między czasem wygenerowania zdarzenia a operacją sondowania, która ściąga ten komunikat do subskrybenta w celu przetworzenia. Ponadto obciążenie związane z ciągłym sondowaniem na następne zdarzenie zużywa zasoby i pieniądze.
Usługa EventGrid jest jednak inna. Implementuje model wypychania, w którym zdarzenia są wysyłane do programu EventHandlers zgodnie z odebraniem, zapewniając dostarczanie zdarzeń niemal w czasie rzeczywistym. Zmniejsza to również koszty, ponieważ usługa jest wyzwalana tylko wtedy, gdy jest potrzebna do korzystania ze zdarzenia — nie jest stale tak samo jak w przypadku sondowania. Oznacza to, że procedura obsługi zdarzeń musi obsługiwać obciążenie przychodzące i zapewniać mechanizmy ograniczania, aby chronić się przed przeciążeniami. Wiele usług platformy Azure korzystających z tych zdarzeń, takich jak Azure Functions i Logic Apps, zapewnia automatyczne skalowanie automatyczne w celu obsługi zwiększonych obciążeń.
Event Grid to w pełni zarządzana bezserwerowa usługa w chmurze. Jest ona dynamicznie skalowana na podstawie ruchu i opłat tylko za rzeczywiste użycie, a nie nabytą wstępnie pojemność. Pierwsze 100 000 operacji miesięcznie jest bezpłatnych — operacje zdefiniowane jako przychodzące zdarzenia (powiadomienia o zdarzeniach przychodzących), próby dostarczenia subskrypcji, wywołania zarządzania i filtrowanie według tematu. Dzięki dostępności 99,99% usługa EventGrid gwarantuje dostarczenie zdarzenia w ciągu 24-godzinnego okresu z wbudowaną funkcją ponawiania prób dla nieudanego dostarczania. Nieużywane komunikaty można przenosić do kolejki "utraconych komunikatów" w celu rozwiązania problemu. W przeciwieństwie do usługi Azure Service Bus usługa Event Grid jest dostosowana do szybkiej wydajności i nie obsługuje takich funkcji jak uporządkowana obsługa komunikatów, transakcje i sesje.
Przesyłanie strumieniowe komunikatów w chmurze platformy Azure
Usługi Azure Service Bus i Event Grid zapewniają doskonałą obsługę aplikacji, które uwidaczniają pojedyncze, dyskretne zdarzenia, takie jak nowy dokument, zostały wstawione do usługi Cosmos DB. Ale co zrobić, jeśli system natywny dla chmury musi przetwarzać strumień powiązanych zdarzeń? Strumienie zdarzeń są bardziej złożone. Są one zwykle uporządkowane w czasie, powiązane i muszą być przetwarzane jako grupa.
Azure Event Hub to platforma przesyłania strumieniowego danych i usługa pozyskiwania zdarzeń, która zbiera, przekształca i przechowuje zdarzenia. Jest ona dostosowana do przechwytywania danych przesyłanych strumieniowo, takich jak ciągłe powiadomienia o zdarzeniach emitowane z kontekstu telemetrii. Usługa jest wysoce skalowalna i może przechowywać i przetwarzać miliony zdarzeń na sekundę. Pokazano na rysunku 4–18, że często jest to drzwi wejściowe dla potoku zdarzeń, co umożliwia oddzielenie strumienia pozyskiwania ze zużycia zdarzeń.
Rysunek 4–18. Centrum zdarzeń Azure
Usługa Event Hub obsługuje małe opóźnienia i konfigurowalne przechowywanie czasu. W przeciwieństwie do kolejek i tematów usługa Event Hubs przechowuje dane zdarzeń po ich odczytaniu przez użytkownika. Ta funkcja umożliwia innym usługom analitycznym danych, zarówno wewnętrznym, jak i zewnętrznym, ponowne odtwarzanie danych w celu dalszej analizy. Zdarzenia przechowywane w centrum zdarzeń są usuwane tylko po wygaśnięciu okresu przechowywania, który jest domyślnie jeden dzień, ale konfigurowalny.
Centrum zdarzeń obsługuje typowe protokoły publikowania zdarzeń, w tym HTTPS i AMQP. Obsługuje również platformę Kafka 1.0. Istniejące aplikacje platformy Kafka mogą komunikować się z centrum zdarzeń przy użyciu protokołu Kafka, co stanowi alternatywę do zarządzania dużymi klastrami platformy Kafka. Wiele systemów natywnych dla chmury typu open source obejmuje platformę Kafka.
Usługa Event Hubs implementuje przesyłanie strumieniowe komunikatów za pośrednictwem partycjonowanego modelu konsumenta, w którym każdy odbiorca odczytuje tylko określony podzestaw lub partycję strumienia komunikatów. Ten wzorzec umożliwia ogromną skalę w poziomie na potrzeby przetwarzania zdarzeń i udostępnia inne funkcje ukierunkowane na strumień, które są niedostępne w kolejkach i tematach. Partycja to uporządkowana sekwencja zdarzeń przechowywana w centrum zdarzeń. Po nadejściu nowszych zdarzeń są one dodawane na końcu tej sekwencji. Rysunek 4–19 przedstawia partycjonowanie w centrum zdarzeń.
Rysunek 4–19. Partycjonowanie centrum zdarzeń
Zamiast odczytywać z tego samego zasobu, każda grupa odbiorców odczytuje w podzestawie lub partycji strumienia komunikatów.
W przypadku aplikacji natywnych dla chmury, które muszą przesyłać strumieniowo dużą liczbę zdarzeń, usługa Azure Event Hub może być niezawodnym i przystępnym cenowo rozwiązaniem.
