Volba mezi použitím zpráv a událostí
Předpokládejme, že plánujete architekturu distribuované aplikace pro sdílení hudby. Chcete zajistit, aby byla aplikace co nejvíce spolehlivá a škálovatelná, a hodláte pomocí technologií Azure sestavit robustní komunikační infrastrukturu.
Než si vyberete správnou technologii Azure, je potřeba pochopit, jaké druhy komunikace si budou jednotlivé komponenty aplikace vyměňovat. Pro každý typ komunikace můžete zvolit jinou technologii Azure.
Jako první potřebujete zjistit, jestli se při komunikaci odesílají zprávy nebo události. Tyto znalosti vám pomůžou zvolit příslušnou službu Azure, která se má použít.
Komunikační strategie v Azure (rozhraní API)
Co je zpráva?
V terminologii distribuovaných aplikací mají zprávy následující vlastnosti:
- Zpráva obsahuje nezpracovaná data vytvořená jednou komponentou a spotřebovaná jinou komponentou.
- Zpráva obsahuje samotná data, ne odkazy na tato data.
- Odesílající komponenta očekává, že cílová komponenta zpracuje obsah zprávy určitým způsobem. Celková integrita systému může záviset na odesílateli i příjemci, který provádí určitou úlohu.
Můžeme si třeba představit, že uživatel pomocí mobilní aplikace pro sdílení hudby nahraje novou skladbu. Mobilní aplikace musí danou skladbu odeslat do webového rozhraní API, které běží v Azure. Je potřeba odeslat samotný mediální soubor skladby, nejenom upozornění na přidání nové skladby. Mobilní aplikace očekává, že webové rozhraní API uloží novou skladbu do databáze a zpřístupní ji ostatním uživatelům. To je tedy příklad zprávy.
Co je událost?
Události jsou jednodušší než zprávy a nejčastěji se používají pro komunikaci vysílání. Komponenty odesílající událost se označují jako vydavatelé a příjemci jako odběratelé.
V případě událostí se příjem komponent rozhodne, ve které komunikaci se zajímají, a "přihlásit se k odběru" těchto událostí. Zprostředkovatel spravuje předplatné, jako je Azure Event Grid nebo Azure Event Hubs. Když vydavatelé posílají událost, zprostředkující tuto událost směruje odběratelům, které mají zájem. Tento model se označuje jako architektura publikování a odběru. Není to jediný způsob, jak řešit události, ale je to nejběžnější.
Události mají následující vlastnosti:
- Událost je zjednodušené oznámení, které udává, že se něco stalo.
- Událost se může odeslat více příjemcům nebo žádnému příjemci.
- Události jsou často určené k větvení nebo mají pro každého vydavatele velký počet odběratelů.
- Vydavatel události nemá žádná očekávání ohledně toho, co má provést přijímající komponenta.
- Některé události jsou samostatné jednotky a nesouvisejí s ostatními událostmi.
- Jiné události jsou součástí propojené a uspořádané řady.
Předpokládejme například, že nahrávání hudebního souboru bylo dokončeno a nová skladba byla přidána do databáze. Za účelem informování uživatelů o novém souboru musí webové rozhraní API informovat o novém souboru webový front-end a uživatele mobilní aplikace. Uživatelé můžou zvolit, jestli se má nová skladba poslechnout, takže počáteční oznámení neobsahuje hudební soubor, ale jenom upozorní uživatele, že skladba existuje. Odesílatel nemá konkrétní očekávání, že příjemci událostí dělají cokoli, zejména v reakci na tuto událost.
Tento scénář je příkladem samostatné události.
Volba mezi zprávami a událostmi
Aplikace bude pravděpodobně k některým účelům používat události a k jiným zase zprávy. Než se rozhodnete, musíte analyzovat architekturu aplikace a všechny její případy použití, abyste identifikovali všechny různé účely, kdy spolu její komponenty musí vzájemně komunikovat.
Události se budou pravděpodobně používat pro vysílání a často jsou dočasné. To znamená, že komunikace nemusí být zpracována žádným příjemcem, pokud se k odběru aktuálně nepřihlašuje žádný příjemce. Zprávy se budou pravděpodobně používat v případech, kdy distribuovaná aplikace vyžaduje záruku zpracování komunikace.
U každé komunikace si položte následující otázku: Očekává odesílající komponenta, že cílová komponenta zpracuje komunikaci určitým způsobem?
Pokud si odpovíte kladně, zvolte použití zprávy. Pokud odpověď není , možná budete moct používat události.
Pochopení toho, jak vaše komponenty potřebují komunikovat, vám pomůže zvolit, jak vaše komponenty komunikují. Začněme se zprávami.