Volba, jestli se mají používat zprávy nebo události
Předpokládejme, že plánujete architekturu distribuované aplikace pro sdílení hudby. Chcete zajistit, aby byla aplikace co nejspolehlivější a škálovatelná, a vy máte v úmyslu používat technologie Azure k vytvoření robustní komunikační infrastruktury.
Než budete moct zvolit správnou technologii Azure, musíte porozumět každé individuální komunikaci, kterou komponenty aplikace vyměňují. Pro každou komunikaci můžete zvolit jinou technologii Azure.
První věc, kterou je potřeba pochopit o komunikaci, je to, zda odesílá zprávy nebo události. Tyto znalosti vám pomůžou zvolit příslušnou službu Azure, která se má použít.
Strategie komunikace v Azure (rozhraní API)
Co je zpráva?
V terminologii distribuovaných aplikací mají zprávy následující charakteristiky:
- Zpráva obsahuje nezpracovaná data vytvořená jednou komponentou a spotřebovaná jinou komponentou.
- Zpráva obsahuje samotná data, nejen odkaz 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.
Předpokládejme například, že uživatel nahraje novou skladbu pomocí mobilní aplikace pro sdílení hudby. Mobilní aplikace musí danou skladbu odeslat do webového rozhraní API, které běží v Azure. Samotný mediální soubor skladby se musí odeslat, ne jenom upozornění, které indikuje, že byla přidána nová skladba. Mobilní aplikace očekává, že webové rozhraní API uloží novou skladbu do databáze a zpřístupní ji ostatním uživatelům. Toto je příklad zprávy.
Co je událost?
Události jsou odlehčenější než zprávy a nejčastěji se používají pro vysílací komunikaci. Komponenty odesílající událost se označují jako vydavateléa příjemci se označují jako odběratelé.
V případě událostí přijímající komponenty rozhodnou, o jakou komunikaci mají zájem, a přihlásí se k těmto událostem. 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í charakteristiky:
- Událost je zjednodušené oznámení, které indikuje, že se něco stalo.
- Událost může být odeslána více příjemcům, nebo nikomu.
- Události jsou často navrženy tak, aby se „rozšiřovaly“, tedy aby měl každý publikující velký počet odběratelů.
- Vydavatel události nemá žádné očekávání o akci, kterou provede přijímající komponenta.
- Některé události jsou diskrétní jednotky a nesouvisejí s jinými událostmi.
- Některé události jsou součástí související a seřazené řady.
Předpokládejme například, že se nahrávání hudebního souboru dokončilo a nová skladba se přidá do databáze. Aby bylo možné informovat uživatele o novém souboru, musí webové rozhraní API informovat webové front-end a uživatele mobilní aplikace o novém souboru. 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 diskrétní události.
Jak zvolit zprávy nebo události
Jedna aplikace bude pravděpodobně používat události pro některé účely a zprávy pro jiné. 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 pravděpodobněji slouží k vysílání a často jsou pomíjivé, což znamená, že komunikace není zpracována žádným příjemcem, pokud se k odběru aktuálně nepřihlašuje žádný. Je pravděpodobnější, že se zprávy budou používat tam, kde distribuovaná aplikace vyžaduje záruku, že komunikace bude zpracována.
Pro každou komunikaci zvažte následující otázku: Očekává odesílající komponenta konkrétní zpracování komunikace cílovou komponentou?
Pokud je odpověď ano, zvolte použít zprávu. Pokud je odpověď bez, 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 zprávami.