Model vydavatele a odběratele

Umožňuje aplikaci oznamovat události několika příjemcům asynchronně, bez párování odesílatelů s příjemci.

Volal se také: Pub/sub messaging

Kontext a problém

V cloudových a distribuovaných aplikacích musí komponenty systému často poskytovat informace ostatním komponentám, když se události objeví.

Asynchronní zasílání zpráv je efektivní způsob, jak oddělit odesílatele od příjemců a vyhnout se blokování, aby odesílatel čekal na odpověď. Použití vyhrazené fronty zpráv pro každého příjemce se ale efektivně nes škáluje na mnoho příjemců. Někteří spotřebitelé můžou mít také zájem jenom o podmnožinu informací. Jak může odesílatel oznámit události všem příjemcům, kteří mají zájem, aniž by znal své identity?

Řešení

Představte si subsystém asynchronního zasílání zpráv, který obsahuje následující:

• Vstupní kanál pro zasílání zpráv používaný odesílatelem. Odesílatel zabalí události do zpráv pomocí známého formátu zprávy a odešle tyto zprávy prostřednictvím vstupního kanálu. Odesílatel v tomto vzoru se také nazývá vydavatel.

  Poznámka:

  Zpráva je paket dat. Událost je zpráva, která upozorní ostatní komponenty na změnu nebo akci, která se proběhla.

• Jeden výstupní kanál zasílání zpráv na příjemce Příjemci se označují jako odběratelé.

• Mechanismus kopírování každé zprávy ze vstupního kanálu do výstupních kanálů pro všechny předplatitele, kteří mají tuto zprávu zájem. Tuto operaci obvykle zpracovává zprostředkovatel, jako je zprostředkovatel zpráv nebo sběrnice událostí.

Následující diagram znázorňuje logické součásti tohoto modelu:

Pub/sub messaging má následující výhody:

• Odděluje subsystémy, které stále potřebují komunikovat. Subsystémy je možné spravovat nezávisle a zprávy je možné správně spravovat, i když je jeden nebo více příjemců offline.

• Zvyšuje škálovatelnost a zlepšuje odezvu odesílatele. Odesílatel může rychle odeslat jednu zprávu do vstupního kanálu a pak se vrátit do základních zodpovědností za zpracování. Infrastruktura zasílání zpráv zodpovídá za zajištění doručení zpráv odběratelům, kteří mají zájem.

• Zvyšuje spolehlivost. Asynchronní zasílání zpráv pomáhá aplikacím plynule běžet pod zvýšenými zatíženími a efektivněji zpracovávat přerušovaná selhání.

• Umožňuje odložené nebo plánované zpracování. Odběratelé můžou čekat na vyzvednutí zpráv až do doby mimo špičku nebo je možné zprávy směrovat nebo zpracovávat podle konkrétního plánu.

• Umožňuje jednodušší integraci mezi systémy pomocí různých platforem, programovacích jazyků nebo komunikačních protokolů a mezi místními systémy a aplikacemi běžícími v cloudu.

• Usnadňuje asynchronní pracovní postupy v rámci podniku.

• Zlepšuje testovatelnost. Kanály je možné monitorovat a zprávy je možné kontrolovat nebo protokolovat jako součást celkové strategie integračního testu.

• Poskytuje oddělení obav pro vaše aplikace. Každá aplikace se může soustředit na své základní funkce, zatímco infrastruktura zasílání zpráv zpracovává vše potřebné ke spolehlivému směrování zpráv více příjemcům.

Problémy a důležité informace

Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:

• Stávající technologie. Důrazně doporučujeme používat dostupné produkty a služby pro zasílání zpráv, které podporují model publikování a odběru, a ne vytvářet vlastní. V Azure zvažte použití služby Service Bus, Event Hubs nebo Event Gridu. Mezi další technologie, které je možné použít pro zasílání pub/sub messaging, patří Redis, RabbitMQ a Apache Kafka.

• Zpracování předplatného Infrastruktura zasílání zpráv musí poskytovat mechanismy, které uživatelé můžou použít k přihlášení k odběru nebo odhlášení odběru dostupných kanálů.

• Zabezpečení. Připojení na jakýkoli kanál zpráv musí být omezen zásadami zabezpečení, aby se zabránilo odposlouchávání neoprávněnými uživateli nebo aplikacemi.

• Podmnožina zpráv Odběratelé se obvykle zajímají jenom o podmnožinu zpráv distribuovaných vydavatelem. Služby zasílání zpráv často umožňují odběratelům zúžit sadu zpráv přijatých:

  • Témata. Každé téma má vyhrazený výstupní kanál a každý příjemce se může přihlásit k odběru všech relevantních témat.
  • Filtrování obsahu Zprávy se kontrolují a distribuují na základě obsahu každé zprávy. Každý odběratel může zadat obsah, který vás zajímá.

• Předplatitelé se zástupnými cardy. Zvažte možnost povolit předplatitelům přihlášení k odběru více témat prostřednictvím zástupných znaků.

• Obousměrná komunikace. Kanály v systému publikování a odběru se považují za jednosměrné. Pokud určitý odběratel potřebuje odeslat potvrzení nebo oznámit stav zpět vydavateli, zvažte použití vzoru žádosti a odpovědi. Tento model používá jeden kanál k odeslání zprávy odběrateli a samostatný kanál odpovědi pro komunikaci s vydavatelem.

• Pořadí zpráv: Pořadí, ve kterém instance příjemců přijímají zprávy, není zaručeno a nemusí nutně odrážet pořadí, ve kterém byly zprávy vytvořeny. Navrhni systém, aby se zajistilo, že zpracování zpráv je idempotentní, aby se zabránilo jakékoli závislosti na pořadí zpracování zpráv.

• Priorita zprávy Některá řešení mohou vyžadovat zpracování zpráv v určitém pořadí. Model Prioritní fronta poskytuje mechanismus pro zajištění doručení konkrétních zpráv před ostatními.

• Jedovaté zprávy. Poškozená zpráva nebo úloha vyžadující přístup k prostředkům, které nejsou k dispozici, může způsobit selhání instance služby. Systém by měl zabránit vrácení takových zpráv do fronty. Místo toho zachyťte a uložte podrobnosti těchto zpráv jinde, aby je bylo možné v případě potřeby analyzovat. Někteří zprostředkovatelé zpráv, jako je Azure Service Bus, to podporují prostřednictvím funkcí fronty nedoručených zpráv.

• Opakované zprávy: Stejná zpráva může být odeslána vícekrát. Odesílatel může například po odeslání zprávy selhat. Pak se může spustit nová instance odesílatele a zprávu zopakovat. Infrastruktura zasílání zpráv by měla implementovat duplicitní detekci a odebrání zpráv (označované také jako zrušení duplicity) na základě ID zpráv, aby bylo možné poskytovat doručení zpráv najednou. Případně pokud používáte infrastrukturu zasílání zpráv, která neduplikuje zprávy, ujistěte se, že je logika zpracování zpráv idempotentní.

• Vypršení platnosti zprávy Zpráva může mít omezenou životnost. Pokud se během tohoto období nezpracovávají, nemusí už být relevantní a mělo by být zahozeno. Odesílatel může zadat čas vypršení platnosti jako součást dat ve zprávě. Příjemce může tyto informace prozkoumat předtím, než se rozhodne, jestli se má provést obchodní logika přidružená ke zprávě.

• Plánování zpráv Zpráva může být dočasně synchronizovaná a neměla by být zpracována do určitého data a času. Zpráva by neměla být k dispozici příjemci do této doby.

• Horizontální navýšení kapacity odběratelů Pokud daný odběratel nemůže držet krok s rychlostí zpráv, které přijímá, použijte model Konkurenční spotřebitelé k horizontálnímu navýšení kapacity.

Kdy se má tento model použít

Tento model použijte v těchto případech:

• Aplikace potřebuje vysílat informace významnému počtu příjemců.

• Aplikace musí komunikovat s jednou nebo více nezávisle vyvinutými aplikacemi nebo službami, které mohou používat různé platformy, programovací jazyky a komunikační protokoly.

• Aplikace může uživatelům odesílat informace, aniž by od uživatelů vyžadovala odpovědi v reálném čase.

• Integrované systémy jsou navržené tak, aby podporovaly model konečné konzistence pro jejich data.

• Aplikace potřebuje sdělit informace více příjemcům, kteří můžou mít jiné požadavky na dostupnost nebo plány dostupnosti než odesílatel.

Tento model nebude pravděpodobně vhodný v následujících případech:

• Aplikace má pouze několik spotřebitelů, kteří potřebují výrazně odlišné informace od produkční aplikace.

• Aplikace vyžaduje téměř interakci v reálném čase se spotřebiteli.

Návrh úloh

Architekt by měl vyhodnotit způsob použití vzoru vydavatele a odběratele v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:

Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.

Příklad

Následující diagram znázorňuje architekturu podnikové integrace, která používá Service Bus ke koordinaci pracovních postupů, a Event Grid k upozornění subsystémů na události, ke kterým dochází. Další informace najdete v tématu Podniková integrace v Azure pomocí front zpráv a událostí.

Další kroky

Při implementaci tohoto modelu můžou být relevantní následující pokyny:

• Vyberte si mezi službami Azure, které doručí zprávy.

• Úvod k asynchronnímu zasílání zpráv: Fronty zpráv jsou asynchronní komunikační mechanismus. Pokud služba příjemce vyžaduje odeslání odpovědi do aplikace, může být nutná implementace nějakého způsobu zasílání odpovědí. Úvod k asynchronnímu zasílání zpráv poskytuje informace o tom, jak se dá zasílání požadavků a odpovědí implementovat pomocí front zpráv.

Při implementaci tohoto modelu můžou být relevantní následující vzory:

• Vzor pozorovatele. Model publikování a odběru vychází ze vzoru pozorovatele oddělením subjektů od pozorovatelů prostřednictvím asynchronního zasílání zpráv.

• Model zprostředkovatele zpráv. Mnoho subsystémů zasílání zpráv, které podporují model publikování a odběru, se implementuje prostřednictvím zprostředkovatele zpráv.

Tento blogový příspěvek popisuje různé způsoby zpracování zpráv, které přicházejí z objednávky.

Související prostředky

• Styl architektury řízené událostmi je styl architektury, který používá zasílání zpráv pub/sub.
• Zpracování idempotentních zpráv
• Podniková integrace v Azure s využitím front zpráv a událostí