Wzorzec publikowania–subskrypcji — Publish–subscribe pattern

Informacje na temat funkcji Macintosh wprowadzonej w systemie System 7 można znaleźć w sekcji Publikowanie i subskrybowanie (Mac OS) . Aby zapoznać się z praktyką płacenia przed ukończeniem pracy, zobacz Model biznesowy subskrypcji .
„PubSub” przekierowuje tutaj. Aby zapoznać się z nieistniejącą witryną wyszukiwania, zobacz PubSub (witryna) .
„Pub sub” przekierowuje tutaj. Dla kanapki sprzedawanej w Publix, zobacz Publix § Market .

W architekturze oprogramowania , publikować subskrybowania jest wzór wiadomości gdzie nadawców komunikatów , zwanych wydawców, nie zaprogramować wiadomości mają być wysyłane bezpośrednio do odbiorników konkretnych, zwanych abonentów, ale zamiast kategoryzować opublikowanych wiadomości do klas bez znajomości których abonenci, jeśli w ogóle , może być. Podobnie subskrybenci wyrażają zainteresowanie co najmniej jedną klasą i otrzymują tylko interesujące wiadomości, bez wiedzy o tym, którzy wydawcy, jeśli w ogóle, istnieją.

Publikowanie-subskrypcja to odpowiednik paradygmatu kolejki komunikatów i zazwyczaj stanowi część większego systemu oprogramowania pośredniczącego zorientowanego na komunikaty. Większość systemów przesyłania wiadomości obsługuje w swoich interfejsach API zarówno modele pub/sub, jak i kolejki komunikatów ; np. Java Message Service (JMS).

Ten wzorzec zapewnia większą skalowalność sieci i bardziej dynamiczną topologię sieci , co skutkuje mniejszą elastycznością modyfikowania wydawcy i struktury publikowanych danych.

Filtrowanie wiadomości

W modelu publikuj-subskrybuj subskrybenci zazwyczaj otrzymują tylko część wszystkich opublikowanych wiadomości. Proces wybierania wiadomości do odbioru i przetwarzania nazywa się filtrowaniem . Istnieją dwie popularne formy filtrowania: na podstawie tematu i na podstawie treści.

W systemie tematycznym komunikaty są publikowane w „tematach” lub nazwanych kanałach logicznych. Subskrybenci w systemie tematycznym otrzymają wszystkie wiadomości opublikowane w tematach, które subskrybują. Wydawca odpowiada za zdefiniowanie tematów, które mogą subskrybować subskrybenci.

W systemie opartym na treści komunikaty są dostarczane do subskrybenta tylko wtedy, gdy atrybuty lub treść tych komunikatów są zgodne z ograniczeniami zdefiniowanymi przez subskrybenta. Subskrybent odpowiada za klasyfikację wiadomości.

Niektóre systemy obsługują hybrydę tych dwóch; wydawcy publikują wiadomości w temacie, podczas gdy subskrybenci rejestrują subskrypcje oparte na treści w jednym lub większej liczbie tematów.

Topologie

W wielu systemach pub/sub wydawcy publikują komunikaty w pośredniczącym brokerze komunikatów lub magistrali zdarzeń , a subskrybenci rejestrują subskrypcje u tego brokera, umożliwiając brokerowi przeprowadzenie filtrowania. Broker zwykle wykonuje funkcję przechowywania i przesyłania dalej, aby kierować komunikaty od wydawców do subskrybentów. Ponadto broker może nadawać priorytet wiadomościom w kolejce przed routingiem.

Subskrybenci mogą rejestrować się w celu uzyskania określonych komunikatów w czasie kompilacji, inicjalizacji lub w czasie wykonywania. W systemach GUI abonenci mogą być zakodowani do obsługi poleceń użytkownika (np. kliknięcia przycisku), co odpowiada rejestracji czasu budowy. Niektóre platformy i oprogramowanie używają plików konfiguracyjnych XML do rejestrowania subskrybentów. Te pliki konfiguracyjne są odczytywane w czasie inicjalizacji. Najbardziej wyrafinowaną alternatywą jest możliwość dodawania lub usuwania subskrybentów w czasie wykonywania. To drugie podejście jest stosowane na przykład w wyzwalaczach baz danych , listach mailingowych i RSS .

Oprogramowanie pośredniczące usługi dystrybucji danych (DDS) nie używa pośrednika w środku. Zamiast tego każdy wydawca i subskrybent w systemie pub/sub udostępnia metadane o sobie za pośrednictwem multiemisji IP . Wydawca i subskrybenci buforują te informacje lokalnie i przekierowują wiadomości na podstawie wzajemnego odkrycia we wspólnym poznaniu. W efekcie architektury bez brokera wymagają systemu publikowania/subskrybowania w celu zbudowania sieci nakładkowej, która umożliwia wydajne zdecentralizowane trasowanie od wydawców do subskrybentów. Jon Kleinberg wykazał, że wydajny zdecentralizowany routing wymaga topologii Navigable Small-World . Takie topologie Small-World są zwykle implementowane przez zdecentralizowane lub sfederowane systemy publikowania/subskrybowania. Systemy publikowania/subskrybowania uwzględniające lokalizację tworzą topologie Small-World, które kierują subskrypcje przez krótkie i tanie łącza, skracając w ten sposób czas dostarczania subskrypcji.

Historia

Jednym z najwcześniejszych publicznie opisanych systemów pub/sub był podsystem „wiadomości” Isis Toolkit, opisany na sympozjum Association for Computing Machinery (ACM) w 1987 roku na konferencji dotyczącej zasad systemów operacyjnych (SOSP '87), w artykule „Exploiting Virtual Synchronia w systemach rozproszonych 123–138".

Zalety

Luźne powiązanie

Wydawcy są luźno związani z subskrybentami i nie muszą nawet wiedzieć o ich istnieniu. Skupiając się na temacie, wydawcy i subskrybenci mogą pozostać nieświadomi topologii systemu. Każdy może nadal działać normalnie, niezależnie od drugiego. W tradycyjnym, ściśle powiązanym paradygmacie klient-serwer klient nie może wysyłać wiadomości do serwera, gdy proces serwera nie jest uruchomiony, ani serwer nie może odbierać wiadomości, jeśli klient nie jest uruchomiony. Wiele systemów pub/sub oddziela nie tylko lokalizacje wydawców i subskrybentów, ale także rozdziela je czasowo. Powszechną strategią stosowaną przez analityków oprogramowania pośredniczącego w takich systemach pub/sub jest wyłączenie wydawcy, aby umożliwić subskrybentowi pracę przez zaległości (forma ograniczania przepustowości ).

Skalowalność

Pub/sub zapewnia możliwość lepszej skalowalności niż tradycyjny klient-serwer, dzięki pracy równoległej, buforowaniu wiadomości, routingowi opartemu na drzewie lub sieci itp. Jednak w niektórych typach ściśle powiązanych środowisk korporacyjnych o dużej objętości, takich jak systemy skalować, aby stać się centrami danych z tysiącami serwerów współdzielących infrastrukturę pub/sub, obecne systemy dostawców często tracą tę korzyść; skalowalność dla produktów pub/sub pod dużym obciążeniem w tych kontekstach jest wyzwaniem badawczym.

Z drugiej strony, poza środowiskiem korporacyjnym, paradygmat pub/sub dowiódł swojej skalowalności do wolumenów znacznie wykraczających poza pojedyncze centrum danych, zapewniając rozproszone przesyłanie wiadomości w całym Internecie za pośrednictwem protokołów syndykacji sieci Web, takich jak RSS i Atom . Te protokoły syndykowania akceptują większe opóźnienia i brak gwarancji dostarczenia w zamian za możliwość syndykowania komunikatów do (potencjalnie) milionów oddzielnych węzłów abonenckich nawet przez serwer sieciowy o niskim standardzie.

Niedogodności

Najpoważniejsze problemy z systemami pub/sub są efektem ubocznym ich głównej zalety: oddzielenia wydawcy od subskrybenta.

Problemy z dostarczaniem wiadomości

System pub/sub musi być starannie zaprojektowany, aby mógł zapewnić silniejsze właściwości systemu, których może wymagać dana aplikacja, takie jak gwarantowana dostawa.

  • Broker w systemie pub/sub może być zaprojektowany tak, aby dostarczać komunikaty przez określony czas, ale potem przestać próbować dostarczyć, niezależnie od tego, czy otrzymał potwierdzenie pomyślnego odebrania komunikatu przez wszystkich subskrybentów. Zaprojektowany w ten sposób system pub/sub nie może zagwarantować dostarczania wiadomości do jakichkolwiek aplikacji, które mogą wymagać takiej gwarantowanej dostawy. Ściślejsze sprzężenie projektów takiej pary wydawcy i subskrybenta musi być egzekwowane poza architekturą pub/sub, aby osiągnąć takie gwarantowane dostarczenie (np. przez wymaganie od subskrybenta publikowania komunikatów odbioru).
  • Wydawca w systemie pub/sub może zakładać, że subskrybent słucha, podczas gdy w rzeczywistości tak nie jest. Fabryka może wykorzystywać system pub/sub, w którym sprzęt może publikować problemy lub awarie subskrybentowi, który wyświetla i rejestruje te problemy. Jeśli rejestrator ulegnie awarii (awaria), wydawcy problemów ze sprzętem niekoniecznie otrzymają powiadomienie o awarii rejestratora, a komunikaty o błędach nie będą wyświetlane ani rejestrowane przez żadne urządzenie w systemie pub/sub. Jest to również wyzwanie projektowe dla alternatywnych architektur przesyłania wiadomości, takich jak system klient/serwer. W systemie klient/serwer, gdy rejestrator błędów ulegnie awarii, system otrzyma informację o awarii rejestratora błędów (serwera). Jednak system klient/serwer będzie musiał poradzić sobie z tą awarią, udostępniając nadmiarowe serwery rejestrowania w trybie online lub dynamicznie tworząc zapasowe serwery rejestrowania. Zwiększa to złożoność projektów klienta i serwera, a także całej architektury klient/serwer. Jednak w systemie pub/sub, nadmiarowi subskrybenci rejestrujący, którzy są dokładnymi duplikatami istniejącego rejestratora, mogą zostać dodani do systemu w celu zwiększenia niezawodności rejestrowania bez wpływu na inne urządzenia w systemie. W systemie pub/sub, funkcja gwarantowanego rejestrowania komunikatów o błędach może być dodawana stopniowo, po zaimplementowaniu podstawowej funkcjonalności rejestrowania komunikatów o problemach ze sprzętem.

Wzorzec pub/sub skaluje się dobrze w małych sieciach z niewielką liczbą węzłów wydawców i subskrybentów oraz małą liczbą wiadomości. Jednak wraz ze wzrostem liczby węzłów i wiadomości wzrasta prawdopodobieństwo wystąpienia niestabilności, ograniczając maksymalną skalowalność sieci pub/sub. Przykładowe niestabilności przepustowości w dużej skali obejmują:

  • Skoki obciążenia — okresy, w których subskrybent żąda nasycenia przepustowości sieci, po których następują okresy niskiej głośności wiadomości (niewykorzystana przepustowość sieci)
  • Spowolnienia — ponieważ coraz więcej aplikacji korzysta z systemu (nawet jeśli komunikują się w oddzielnych kanałach pub/sub), przepływ wiadomości do pojedynczego abonenta będzie spowolniony

W przypadku systemów pub/sub, które korzystają z brokerów (serwerów), argumentem przemawiającym za wysyłaniem komunikatów do subskrybenta przez brokera jest in-band i może powodować problemy z bezpieczeństwem. Brokerzy mogą zostać oszukani do wysyłania powiadomień do niewłaściwego klienta, wzmacniając żądania odmowy usługi skierowane przeciwko klientowi. Sami brokerzy mogą być przeciążeni, ponieważ przydzielają zasoby do śledzenia utworzonych subskrypcji.

Nawet w przypadku systemów, które nie opierają się na brokerach, subskrybent może otrzymać dane, do których otrzymywania nie jest upoważniony. Nieautoryzowany wydawca może wprowadzić nieprawidłowe lub szkodliwe wiadomości do systemu pub/sub. Dotyczy to zwłaszcza systemów, które rozgłaszają lub multiemisji swoje wiadomości. Szyfrowanie (np. Transport Layer Security (SSL/TLS)) może zapobiec nieautoryzowanemu dostępowi, ale nie może zapobiec wprowadzaniu szkodliwych wiadomości przez autoryzowanych wydawców. Architektury inne niż pub/sub, takie jak systemy klient/serwer, są również podatne na złośliwe zachowanie autoryzowanych nadawców wiadomości.

Zobacz też

Bibliografia

Zewnętrzne linki