Wybieranie platformy do obsługi komunikatów
Dostępnych jest wiele platform komunikacyjnych, które pomagają zwiększyć niezawodność aplikacji rozproszonej, w tym kilka na platformie Microsoft Azure. Każda platforma to narzędzie, które służy innego celu. Ważne jest, aby wybrać odpowiednie narzędzie dla każdego wymagania w aplikacji. Zapoznaj się z opcjami w usłudze Azure Service Bus.
Proponowana architektura rozproszonej aplikacji do zamawiania i śledzenia rowerów firmy Contoso wymaga kilku składników, w tym witryny internetowej, magazynu danych i usługi zaplecza. Składniki aplikacji można powiązać na wiele różnych sposobów, a jedna aplikacja może korzystać z wielu technik.
Musisz zdecydować, które techniki mają być używane w nowej aplikacji Contoso Bicycles. Pierwszym krokiem jest ocena każdego miejsca, w którym istnieje komunikacja między wieloma częściami. Niektóre składniki muszą być uruchamiane w odpowiednim czasie, aby aplikacja w ogóle wykonywała swoje zadanie. Niektóre mogą być ważne, ale nie krytyczne dla czasu. Na koniec inne składniki, takie jak powiadomienia aplikacji mobilnej, są nieco bardziej opcjonalne.
Wybór między komunikatami i zdarzeniami
Zarówno komunikaty, jak i zdarzenia to datagramy: pakiety danych wysyłanych z jednego składnika do innego. Różnią się one w sposób, który na początku wydaje się subtelny, ale różnice mogą mieć znaczący wpływ na sposób tworzenia architektury aplikacji.
Wiadomości
W terminologii aplikacji rozproszonych definiowana cecha komunikatu polega na tym, że ogólna integralność aplikacji może polegać na odbieranych komunikatach. O wysyłaniu komunikatów można myśleć jak o składniku przekazującym pałeczkę innemu składnikowi. Cały przepływ pracy może być istotnym procesem biznesowym, a komunikatem jest zaprawa, która przechowuje składniki razem.
Komunikat zazwyczaj zawiera rzeczywiste dane, a nie tylko odwołanie (na przykład identyfikator lub adres URL) do danych. Wysyłanie danych w ramach datagramu jest mniej kruche niż wysyłanie odwołania. Architektura obsługi komunikatów gwarantuje dostarczanie komunikatów, a ponieważ nie są wymagane żadne dodatkowe wyszukiwania, komunikat jest niezawodnie obsługiwany. Jednak aplikacja wysyłająca musi wiedzieć dokładnie, jakie dane należy uwzględnić, aby uniknąć wysyłania zbyt dużej ilości danych, co wymagałoby, aby składnik odbierający działał niepotrzebnie. W tym sensie nadawca i odbiorca komunikatu są często powiązane ze ścisłym kontraktem danych.
W nowej architekturze dla rowerów firmy Contoso po złożeniu zamówienia firma prawdopodobnie będzie używać komunikatów. Fronton internetowy lub aplikacja mobilna wyśle komunikat do składników przetwarzania zaplecza. Na zapleczu zostaną wykonane kroki, takie jak routing do sklepu najbliższego klienta i ładowanie karty kredytowej.
Wydarzenia
Zdarzenie wyzwala powiadomienie o tym, że coś nastąpiło. Zdarzenia są „lżejsze” niż komunikaty i są najczęściej używane w przypadku emisji.
Zdarzenia mają następujące cechy:
- Zdarzenie może być wysyłane do wielu odbiorników lub do żadnego w ogóle.
- Zdarzenia są często przeznaczone do szerokiego rozpowszechniania, czyli każdy wydawca ma dużą liczbę subskrybentów.
- Wydawca zdarzeń nie ma oczekiwań co do akcji, która podejmuje składnik odbierający.
Łańcuch części rowerowych prawdopodobnie będzie używać zdarzeń dla powiadomień użytkowników o zmianach stanu. Zdarzenia zmiany stanu można wysyłać do usługi Azure Event Grid, a następnie do usługi Azure Functions i do usługi Azure Notification Hubs w celu uzyskania całkowicie bezserwerowego rozwiązania.
Ta różnica między zdarzeniami i komunikatami jest zasadnicza, ponieważ platformy komunikacji są zazwyczaj zaprojektowane z myślą o obsłudze jednych lub drugich. Usługa Service Bus jest przeznaczona do obsługi komunikatów. Jeśli chcesz wysyłać zdarzenia, prawdopodobnie wybierz pozycję Event Grid.
Platforma Azure ma również usługę Azure Event Hubs, ale najczęściej jest używana dla określonego typu strumienia komunikacji o wysokim przepływie używanego do analizy. Jeśli na przykład masz czujniki sieciowe w magazynach produkcyjnych, możesz użyć usługi Event Hubs w połączeniu z usługą Azure Stream Analytics, aby obserwować wzorce w zmianach temperatury, które mogą wskazywać na niepożądane zużycie pożaru lub składnika.
Tematy i kolejki usługi Service Bus
Usługa Azure Service Bus może wymieniać komunikaty na dwa różne sposoby: kolejki i tematy.
Co to jest kolejka?
Kolejka usługi Service Bus to prosta tymczasowa lokalizacja magazynu komunikatów. Składnik wysyłający dodaje komunikat do kolejki. Składnik docelowy pobiera komunikat z początku kolejki. W zwykłych okolicznościach każdy komunikat jest odbierany tylko przez jeden odbiornik.
Kolejki oddzielają od siebie składniki źródłowe i docelowe, aby odizolować składniki docelowe w przypadku dużego zapotrzebowania.
W godzinach szczytu komunikaty mogą występować szybciej niż składniki docelowe mogą je obsługiwać. Ponieważ składniki źródłowe nie mają bezpośredniego połączenia z miejscem docelowym, nie ma to wpływu na źródło, a kolejka będzie rosła. Składniki docelowe spowodują usunięcie komunikatów z kolejki w miarę ich obsługi. Gdy zapotrzebowanie spadnie, składniki docelowe mogą nadrobić zaległości, a kolejka się skróci.
Kolejka reaguje na duże zapotrzebowanie bez konieczności dodawania zasobów do systemu. Jednak w przypadku komunikatów, które muszą być obsługiwane szybko, tworzenie większej liczby wystąpień składnika docelowego może umożliwić im udostępnianie obciążenia. Każdy komunikat jest obsługiwany tylko przez jedno wystąpienie. Jest to skuteczny sposób skalowania całej aplikacji przez dodanie zasobów tylko do składników, które ich rzeczywiście potrzebują.
Co to jest temat?
Temat usługi Service Bus jest podobny do kolejki, ale temat może mieć wiele subskrypcji. Oznacza to, że wiele składników docelowych może subskrybować określony temat, więc każdy komunikat jest dostarczany do wielu odbiorników. Subskrypcje mogą także filtrować komunikaty w temacie, aby odbierać tylko istotne komunikaty. Subskrypcje zapewniają tę samą komunikację z rozdzieleniem źródła i celu co kolejki i reagują na wysokie zapotrzebowanie w ten sam sposób. Użyj tematu, jeśli chcesz dostarczyć każdy komunikat do wielu składników docelowych.
Uwaga
Tematy nie są obsługiwane w warstwie cenowej Podstawowa.
Kolejki usługi Service Bus i kolejki magazynu
Dwie usługi platformy Azure obejmują kolejki komunikatów: Service Bus i Azure Storage. Ogólnie rzecz biorąc, kolejki magazynu są prostsze w użyciu, ale są mniej zaawansowane i mniej elastyczne niż kolejki usługi Service Bus.
Najważniejsze zalety kolejek usługi Service Bus obejmują:
- Obsługuje większe rozmiary komunikatów o rozmiarze 256 KB (warstwa Standardowa) lub 100 MB (warstwa Premium) na komunikat w porównaniu z 64 KB dla komunikatów w kolejce usługi Azure Storage.
- Obsługuje zarówno co najwyżej jednokrotne, jak i co najmniej jednokrotne dostarczanie. Wybierz między bardzo małą szansą, że komunikat zostanie utracony lub bardzo mała szansa, że zostanie obsłużona dwa razy.
- Gwarantuje kolejność pierwszy na wyjęcie (FIFO). Komunikaty są obsługiwane w tej samej kolejności, w której są dodawane. Mimo że fiFO jest normalną operacją kolejki, domyślny wzorzec FIFO jest zmieniany, jeśli organizacja konfiguruje sekwencjonowane lub zaplanowane komunikaty lub podczas przerw, takich jak awaria systemu. Aby uzyskać więcej informacji, zobacz Porównanie kolejek usługi Azure Storage i kolejek usługi Azure Service Bus.
- Może grupować wiele komunikatów w jednej transakcji. Jeśli dostarczenie jednego komunikatu w transakcji nie powiedzie się, wszystkie komunikaty w transakcji nie zostaną dostarczone.
- Obsługuje zabezpieczenia oparte na rolach.
- Nie wymaga składników docelowych do ciągłego sondowania kolejki.
Zalety kolejek magazynu:
- Obsługują nieograniczony rozmiar kolejki (w przeciwieństwie do limitu 80 GB dla kolejek usługi Service Bus)
- Przechowują dziennik wszystkich komunikatów
Jak wybrać technologię komunikacji
Przedstawiono różne pojęcia i implementacje platformy Azure. Następnie zastanów się, jak powinien wyglądać proces decyzyjny dla każdej komunikacji.
Kwestie wymagające rozważenia
Podczas wybierania metody wysyłania i odbierania komunikatów należy wziąć pod uwagę następujące pytania:
Czy komunikacja jest zdarzeniem? Jeśli tak, należy wziąć pod uwagę użycie usługi Event Grid lub Event Hubs.
Czy pojedynczy komunikat ma zostać dostarczony do więcej niż jednego miejsca docelowego? Jeśli tak, użyj tematu usługi Service Bus. W przeciwnym razie użyj kolejki usługi Service Bus.
Kolejki: Usługa Service Bus a magazyn
Jeśli zdecydujesz, że potrzebujesz kolejki, zawęź wybór dalej.
Wybierz kolejkę usługi Service Bus , jeśli:
- Potrzebujesz co najwyżej jednokrotnej gwarancji dostarczania.
- Potrzebujesz gwarancji FIFO (jeśli żadne inne ustawienia nie wywłaszczą domyślnej kolejności FIFO).
- Chcesz grupować komunikaty w transakcje.
- Chcesz odbierać komunikaty bez sondowania kolejki.
- Musisz zapewnić dostęp oparty na rolach do kolejek.
- Musisz obsługiwać komunikaty większe niż 64 KB, ale mniejsze niż 256 KB dla warstwy Standardowa lub 100 MB dla warstwy Premium.
- Rozmiar kolejki nie będzie większy niż 80 GB.
- Chcesz mieć możliwość publikowania i korzystania z partii komunikatów.
Wybierz kolejkę magazynu , jeśli:
- Potrzebujesz prostej kolejki bez konkretnych dodatkowych wymagań.
- Potrzebujesz dziennika inspekcji wszystkich komunikatów przechodzących przez kolejkę.
- Oczekujesz, że rozmiar kolejki przekroczy 80 GB.
- Chcesz śledzić postęp przetwarzania komunikatu wewnątrz kolejki.
Chociaż składniki aplikacji rozproszonej mogą komunikować się bezpośrednio, często można zwiększyć niezawodność tej komunikacji przy użyciu pośredniej platformy komunikacji, takiej jak Azure Event Hubs lub Azure Event Grid.
Usługi Event Hubs i Event Grid są przeznaczone dla zdarzeń, które powiadamiają adresatów tylko o zdarzeniu i nie zawierają nieprzetworzonych danych skojarzonych z tym zdarzeniem. Usługa Azure Event Hubs jest przeznaczona dla dużych przepływów, typów analiz zdarzeń.
Usługa Azure Service Bus i kolejki magazynu są przeznaczone dla komunikatów, których można użyć do powiązania podstawowych elementów dowolnego przepływu pracy aplikacji.
Jeśli wymagania są proste, jeśli chcesz wysłać każdy komunikat tylko do jednego miejsca docelowego lub jeśli chcesz napisać kod tak szybko, jak to możliwe, kolejka magazynu może być najlepszą opcją. W przeciwnym razie kolejki usługi Service Bus zapewniają o wiele więcej opcji i elastyczność.
Jeśli chcesz wysyłać komunikaty do wielu subskrybentów, użyj tematu usługi Service Bus.