Wzorzec wydawcy-subskrybenta

Umożliwianie aplikacji asynchronicznego informowania o zdarzeniach zainteresowanych odbiorców bez sprzęgania nadawców z odbiorcami.

Wywoływana również: obsługa komunikatów pub/podrzędnych

Kontekst i problem

W aplikacjach opartych na chmurze i rozproszonych składniki systemu często muszą dostarczać informacje innym składnikom w miarę wystąpienia zdarzeń.

Asynchroniczne przesyłanie komunikatów to skuteczny sposób oddzielenia nadawców od użytkowników i unikanie blokowania nadawcy oczekiwania na odpowiedź. Jednak użycie dedykowanej kolejki komunikatów dla każdego odbiorcy nie powoduje efektywnego skalowania do wielu odbiorców. Ponadto niektórzy konsumenci mogą być zainteresowani tylko podzestawem informacji. Jak nadawca może ogłaszać zdarzenia wszystkim zainteresowanym konsumentom bez znajomości ich tożsamości?

Rozwiązanie

Wprowadzenie do podsystemu asynchronicznego obsługi komunikatów, który obejmuje następujące elementy:

• Kanał obsługi komunikatów wejściowych używany przez nadawcę. Nadawca pakuje zdarzenia do komunikatów, używając znanego formatu wiadomości i wysyła te komunikaty za pośrednictwem kanału wejściowego. Nadawca w tym wzorcu jest również nazywany wydawcą.

  Uwaga

  Komunikat to pakiet danych. Zdarzenie to komunikat, który powiadamia inne składniki o zmianie lub akcji, która została wykonana.

• Jeden kanał obsługi komunikatów wyjściowych na odbiorcę. Odbiorcy są znani jako subskrybenci.

• Mechanizm kopiowania każdego komunikatu z kanału wejściowego do kanałów wyjściowych dla wszystkich subskrybentów zainteresowanych tym komunikatem. Ta operacja jest zwykle obsługiwana przez pośrednika, takiego jak broker komunikatów lub magistrala zdarzeń.

Na poniższym diagramie przedstawiono logiczne składniki tego wzorca:

Obsługa komunikatów pub/sub ma następujące korzyści:

• Rozdziela podsystemy, które nadal muszą się komunikować. Podsystemy mogą być zarządzane niezależnie, a komunikaty mogą być prawidłowo zarządzane, nawet jeśli co najmniej jeden odbiornik jest w trybie offline.

• Zwiększa skalowalność i poprawia czas reakcji nadawcy. Nadawca może szybko wysłać pojedynczy komunikat do kanału wejściowego, a następnie powrócić do podstawowych obowiązków związanych z przetwarzaniem. Infrastruktura obsługi komunikatów jest odpowiedzialna za zapewnienie, że komunikaty są dostarczane do zainteresowanych subskrybentów.

• Zwiększa niezawodność. Asynchroniczne obsługa komunikatów pomaga aplikacjom w dalszym ciągu bezproblemowo uruchamiać się pod zwiększonymi obciążeniami i efektywniej obsługiwać sporadyczne awarie.

• Umożliwia odroczone lub zaplanowane przetwarzanie. Subskrybenci mogą czekać na odbieranie komunikatów do godzin poza godzinami szczytu lub komunikaty mogą być kierowane lub przetwarzane zgodnie z określonym harmonogramem.

• Umożliwia prostszą integrację między systemami przy użyciu różnych platform, języków programowania lub protokołów komunikacyjnych, a także między systemami lokalnymi i aplikacjami działającymi w chmurze.

• Ułatwia asynchroniczne przepływy pracy w przedsiębiorstwie.

• Zwiększa to możliwość testowania. Kanały mogą być monitorowane, a komunikaty mogą być sprawdzane lub rejestrowane w ramach ogólnej strategii testowania integracji.

• Zapewnia ona rozdzielenie problemów dotyczących aplikacji. Każda aplikacja może skupić się na jej podstawowych możliwościach, podczas gdy infrastruktura obsługi komunikatów obsługuje wszystko, co jest wymagane do niezawodnego kierowania komunikatów do wielu użytkowników.

Problemy i kwestie do rozważenia

Podczas podejmowania decyzji o sposobie wdrożenia tego wzorca należy rozważyć następujące punkty:

• Istniejące technologie. Zdecydowanie zaleca się korzystanie z dostępnych produktów i usług obsługi komunikatów, które obsługują model publikowania-subskrybowania, zamiast tworzyć własne. Na platformie Azure rozważ użycie usługi Service Bus, usługi Event Hubs lub usługi Event Grid. Inne technologie, które mogą być używane do obsługi komunikatów pub/sub, to Redis, RabbitMQ i Apache Kafka.

• Obsługa subskrypcji. Infrastruktura obsługi komunikatów musi zapewniać mechanizmy, których użytkownicy mogą używać do subskrybowania lub anulowania subskrypcji dostępnych kanałów.

• Zabezpieczenia. Połączenie do dowolnego kanału wiadomości muszą być ograniczone przez zasady zabezpieczeń, aby zapobiec podsłuchiwania przez nieautoryzowanych użytkowników lub aplikacji.

• Podzestawy komunikatów. Subskrybenci są zwykle zainteresowani tylko podzbiorem komunikatów dystrybuowanych przez wydawcę. Usługi obsługi komunikatów często umożliwiają subskrybentom zawężenie zestawu komunikatów odbieranych przez:

  • Tematy. Każdy temat ma dedykowany kanał wyjściowy, a każdy odbiorca może subskrybować wszystkie odpowiednie tematy.
  • Filtrowanie zawartości. Komunikaty są sprawdzane i dystrybuowane na podstawie zawartości każdego komunikatu. Każdy subskrybent może określić zawartość, która jest zainteresowana.

• Subskrybenci symboli wieloznacznych. Rozważ umożliwienie subskrybentom subskrybowania wielu tematów za pośrednictwem symboli wieloznacznych.

• Komunikacja dwukierunkowa. Kanały w systemie publikowania-subskrybowania są traktowane jako jednokierunkowe. Jeśli określony subskrybent musi wysłać potwierdzenie lub przekazać stan z powrotem do wydawcy, rozważ użycie wzorca żądania/odpowiedzi. Ten wzorzec używa jednego kanału do wysyłania komunikatu do subskrybenta i oddzielnego kanału odpowiedzi do komunikacji z powrotem do wydawcy.

• Kolejność komunikatów. Kolejność odbierania komunikatów przez wystąpienia konsumentów nie jest gwarantowana i nie musi odzwierciedlać kolejności tworzenia komunikatów. Zaprojektuj system, aby upewnić się, że przetwarzanie komunikatów jest idempotentne, aby wyeliminować wszelkie zależności od kolejności obsługi komunikatów.

• Priorytet wiadomości. Niektóre rozwiązania mogą wymagać przetwarzania komunikatów w określonej kolejności. Wzorzec kolejki priorytetu zapewnia mechanizm zapewniający dostarczanie określonych komunikatów przed innymi.

• Zatrute wiadomości. Zniekształcony komunikat lub zadanie wymagające dostępu do zasobów, które nie są dostępne, może spowodować niepowodzenie wystąpienia usługi. System powinien zapobiegać zwracaniu takich komunikatów do kolejki. Zamiast tego przechwyć i zapisać szczegóły tych komunikatów w innym miejscu, aby można je było analizować w razie potrzeby. Niektórzy brokerzy komunikatów, tacy jak Usługa Azure Service Bus, obsługują tę funkcję za pośrednictwem funkcji kolejki utraconych komunikatów.

• Powtórzone komunikaty. Ta sama wiadomość może zostać wysłana więcej niż raz. Na przykład nadawca może zakończyć się niepowodzeniem po opublikowaniu wiadomości. Następnie nowe wystąpienie nadawcy może uruchomić i powtórzyć komunikat. Infrastruktura obsługi komunikatów powinna implementować wykrywanie i usuwanie zduplikowanych komunikatów (nazywane również usuwaniem zrzutów) na podstawie identyfikatorów komunikatów, aby zapewnić co najwyżej jednokrotne dostarczanie komunikatów. Alternatywnie, jeśli korzystasz z infrastruktury obsługi komunikatów, która nie deduplikuje komunikatów, upewnij się, że logika przetwarzania komunikatów jest idempotentna.

• Wygaśnięcie wiadomości. Komunikat może mieć ograniczony okres istnienia. Jeśli nie jest on przetwarzany w tym okresie, może już nie być odpowiedni i powinien zostać odrzucony. Nadawca może określić czas wygaśnięcia w ramach danych w komunikacie. Odbiorca może zbadać te informacje przed podjęciem decyzji, czy wykonać logikę biznesową skojarzona z komunikatem.

• Planowanie komunikatów. Komunikat może być tymczasowo embargodowany i nie powinien być przetwarzany do określonej daty i godziny. Komunikat nie powinien być dostępny dla odbiorcy do tej pory.

• Skalowanie subskrybentów wyrażeń. Jeśli dany subskrybent nie może nadążyć za szybkością odbierania komunikatów, użyj wzorca konkurujących odbiorców, aby go skalować w poziomie.

Kiedy używać tego wzorca

Użyj tego wzorca, gdy:

• Aplikacja musi emitować informacje do znacznej liczby użytkowników.

• Aplikacja musi komunikować się z co najmniej jedną niezależną aplikacją lub usługą, która może używać różnych platform, języków programowania i protokołów komunikacyjnych.

• Aplikacja może wysyłać informacje do użytkowników bez konieczności odpowiadania w czasie rzeczywistym od użytkowników.

• Zintegrowane systemy są przeznaczone do obsługi modelu spójności ostatecznej dla swoich danych.

• Aplikacja musi komunikować informacje wielu użytkownikom, którzy mogą mieć różne wymagania dotyczące dostępności lub harmonogramy czasu pracy niż nadawca.

Ten wzorzec może nie być przydatny w następujących sytuacjach:

• Aplikacja ma tylko kilku użytkowników, którzy potrzebują znacznie różnych informacji od aplikacji produkującej.

• Aplikacja wymaga interakcji niemal w czasie rzeczywistym z użytkownikami.

Projekt obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec wydawcy/subskrybenta może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Na przykład:

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Przykład

Na poniższym diagramie przedstawiono architekturę integracji przedsiębiorstwa, która używa usługi Service Bus do koordynowania przepływów pracy, oraz usługi Event Grid w celu powiadamiania podsystemów o zdarzeniach, które występują. Aby uzyskać więcej informacji, zobacz Integracja przedsiębiorstwa na platformie Azure przy użyciu kolejek komunikatów i zdarzeń.

Następne kroki

Następujące wskazówki mogą być istotne podczas implementowania tego wzorca:

• Wybierz między usługami platformy Azure, które dostarczają komunikaty.

• Asynchronous Messaging Primer (Podstawy asynchronicznej obsługi komunikatów). Kolejki komunikatów to mechanizm komunikacji asynchronicznej. Jeśli usługa konsumenta musi wysyłać odpowiedź do aplikacji, może być konieczne zaimplementowanie pewnego rodzaju obsługi odpowiedzi na komunikaty. W artykule Asynchronous Messaging Primer (Podstawy asynchronicznej obsługi komunikatów) podano informacje, jak zaimplementować obsługę komunikatów typu żądanie/odpowiedź, korzystając z kolejek komunikatów.

Podczas implementowania tego wzorca mogą być istotne następujące wzorce:

• Wzorzec obserwatora. Wzorzec Publish-Subscribe opiera się na wzorcu obserwatora przez oddzielenie tematów od obserwatorów za pośrednictwem asynchronicznej obsługi komunikatów.

• Wzorzec brokera komunikatów. Wiele podsystemów obsługi komunikatów obsługujących model publikowania-subskrybowania jest implementowanych za pośrednictwem brokera komunikatów.

W tym wpisie w blogu opisano różne sposoby obsługi komunikatów wychodzących z zamówienia.

Powiązane zasoby

• Styl architektury opartej na zdarzeniach jest stylem architektury, który używa komunikatów pub/sub.
• Idempotentne przetwarzanie komunikatów
• Integracja przedsiębiorstwa na platformie Azure przy użyciu kolejek komunikatów i zdarzeń