Tento článek popisuje různé typy zpráv a entity, které se účastní infrastruktury zasílání zpráv. V závislosti na požadavcích jednotlivých typů zpráv článek doporučuje služby zasílání zpráv Azure. Mezi možnosti patří zasílání zpráv služby Azure Service Bus, Azure Event Grid a Azure Event Hubs. Porovnání produktů najdete v tématu Porovnání služeb zasílání zpráv.
Na úrovni architektury je zpráva datagram vytvořený entitou (producentem), která distribuuje informace, aby ostatní entity (spotřebitelé) mohli odpovídajícím způsobem pracovat a vědět. Producent a spotřebitel mohou komunikovat přímo nebo volitelně prostřednictvím zprostředkující entity (zprostředkovatele zpráv). Tento článek se zaměřuje na asynchronní zasílání zpráv pomocí zprostředkovatele zpráv.
Zprávy můžeme klasifikovat do dvou hlavních kategorií. Pokud producent očekává akci od příjemce, je tato zpráva příkazem. Pokud zpráva informuje příjemce, že došlo k akci, je tato zpráva událostí.
Příkazy
Producent odešle příkaz se záměrem, že příjemci budou provádět operaci v rámci obchodní transakce.
Příkaz je zpráva s vysokou hodnotou a musí být doručena alespoň jednou. Pokud dojde ke ztrátě příkazu, může dojít k selhání celé obchodní transakce. Příkaz by také neměl být zpracován více než jednou. To může způsobit chybnou transakci. Zákazník může získat duplicitní objednávky nebo fakturovat dvakrát.
Příkazy se často používají ke správě pracovního postupu vícekrokové obchodní transakce. V závislosti na obchodní logice může producent očekávat, že příjemce zprávu potvrdí a oznámí výsledky operace. Na základě tohoto výsledku může producent zvolit vhodný postup.
Událost
Událost je typ zprávy, kterou producent vyvolá, aby oznámil fakta.
Producent (označovaný jako vydavatel v tomto kontextu) nemá žádné očekávání, že by události způsobily jakoukoli akci.
Zájemci se můžou přihlásit k odběru, naslouchat událostem a provádět akce v závislosti na scénáři spotřeby. Události můžou mít více odběratelů nebo vůbec žádné odběratele. Dva různí odběratelé můžou na událost reagovat s různými akcemi a navzájem si nemusí být vědomi.
Producent a spotřebitel jsou volně svázáni a spravováni nezávisle. Producent neočekává, že příjemce událost potvrdí zpět producentovi. Uživatel, který už nemá zájem o události, se může odhlásit, což odebere příjemce z kanálu, aniž by to ovlivnilo producenta nebo celkovou funkčnost systému.
Existují dvě kategorie událostí:
Producent vyvolá události, aby oznámil diskrétní fakta. Běžným případem použití je oznámení události. Azure Resource Manager například vyvolává události při vytváření, úpravách nebo odstraňování prostředků. Odběratelem těchto událostí může být aplikace logiky, která odesílá e-maily s upozorněními.
Producent během časového období vyvolává související události v posloupnosti nebo v datovém proudu událostí. Datový proud se obvykle využívá ke statistickému vyhodnocení. Vyhodnocení může proběhnout v časovém intervalu nebo při příchodu událostí. Telemetrie je běžný případ použití (například monitorování stavu a zatížení systému). Dalším případem je streamování událostí ze zařízení IoT.
Běžným vzorem pro implementaci zasílání zpráv událostí je model Vydavatel-Odběratel .
Role a výhody zprostředkovatele zpráv
Zprostředkující zprostředkovatel zpráv poskytuje funkci přesouvání zpráv od producenta k spotřebiteli a může nabízet další výhody.
Oddělování
Zprostředkovatel zpráv oddělí producenta od příjemce v logice, která generuje a používá zprávy. V komplexním pracovním postupu může zprostředkovatel podpořit oddělení obchodních operací a koordinaci pracovního postupu.
Například jedna obchodní transakce vyžaduje odlišné operace, které se provádějí v sekvenci obchodní logiky. Producent vydá příkaz, který signalizuje příjemce, aby spustil operaci. Příjemce potvrdí zprávu v samostatné frontě vyhrazenou pro zaplněné odpovědi pro producenta. Až po přijetí odpovědi odešle producent novou zprávu, aby spustil další operaci v sekvenci. Tuto zprávu zpracuje jiný příjemce a odešle zprávu o dokončení do fronty odpovědí. Pomocí zasílání zpráv služby koordinuje pracovní postup transakce mezi sebou.
Zprostředkovatel zpráv poskytuje dočasné oddělení. Producent a spotřebitel nemusí běžet souběžně. Producent může odeslat zprávu zprostředkovateli zpráv bez ohledu na dostupnost příjemce. Naopak spotřebitel není omezen dostupností producenta.
Například uživatelské rozhraní webové aplikace generuje zprávy a používá frontu jako zprostředkovatele zpráv. Až bude příjemce připravený, může načíst zprávy z fronty a provést práci. Dočasné oddělení pomáhá uživatelskému rozhraní zůstat responzivní. Není blokovaná, když se zprávy zpracovávají asynchronně.
Dokončení určitých operací může trvat dlouho. Po vydání příkazu by producent neměl čekat, dokud ho příjemce nedokončí. Zprostředkovatel zpráv pomáhá asynchronnímu zpracování zpráv.
Vyrovnávání zatížení
Producenti mohou publikovat velký počet zpráv, které obsluhuje mnoho spotřebitelů. Použití zprostředkovatele zpráv k distribuci zpracování mezi servery a zlepšení propustnosti. Příjemci mohou běžet na různých serverech, aby se zatížení rozložilo. Příjemci je možné přidat dynamicky, aby v případě potřeby nebo jinak odebrali horizontální navýšení kapacity systému.
Model Konkurující spotřebitelé vysvětluje, jak zpracovávat více zpráv souběžně za účelem optimalizace propustnosti, zlepšení škálovatelnosti a dostupnosti a vyrovnávání zatížení.
Vyrovnávání zatížení
Objem zpráv vygenerovaných producentem nebo skupinou producentů může být proměnlivý. Někdy může docházet k velkému objemu, který způsobuje špičky ve zprávách. Místo přidávání příjemců pro zpracování této práce může zprostředkovatel zpráv fungovat jako vyrovnávací paměť a spotřebitelé postupně vyprázdní zprávy vlastním tempem, aniž by museli systém stresovat.
Model vyrovnávání zatížení založený na frontě poskytuje další informace.
Spolehlivé zasílání zpráv
Zprostředkovatel zpráv pomáhá zajistit, aby se zprávy neztratily, i když komunikace mezi producentem a příjemcem selže. Producent může do zprostředkovatele zpráv publikovat zprávy a příjemce je může načíst při opětovném publikování komunikace. Producent není blokovaný, pokud nepřijde o připojení ke zprostředkovateli zpráv.
Odolné zasílání zpráv
Zprostředkovatel zpráv může uživatelům ve vašem systému přidat odolnost. Pokud příjemce při zpracování zprávy selže, může tuto zprávu zpracovat jiná instance příjemce. Opětovné zpracování je možné, protože zpráva přetrvává ve zprostředkovateli.
Technologické volby pro zprostředkovatele zpráv
Azure poskytuje několik služeb zprostředkovatele zpráv, z nichž každá má řadu funkcí. Před výběrem služby určete záměr a požadavky zprávy.
Zasílání zpráv služby Azure Service Bus
Fronty zasílání zpráv služby Azure Service Bus jsou vhodné pro přenos příkazů od producentů do příjemců. Tady je několik aspektů.
Model vyžádané replikace
Příjemce fronty služby Service Bus se neustále dotazuje služby Service Bus, aby zkontroloval, jestli jsou k dispozici nové zprávy. Klientské sady SDK a trigger Azure Functions pro Service Bus abstrahují tento model. Pokud je k dispozici nová zpráva, vyvolá se zpětné volání příjemce a zpráva se odešle příjemci.
Zaručené doručení
Service Bus umožňuje příjemci zobrazit frontu a uzamknout zprávu od ostatních příjemců.
Uživatel zodpovídá za hlášení stavu zpracování zprávy. Pouze když příjemce označí zprávu jako spotřebovanou, odebere Service Bus zprávu z fronty. Pokud dojde k selhání, vypršení časového limitu nebo chybovému ukončení, služba Service Bus zprávu odemkne, aby ji ostatní uživatelé mohli načíst. Tímto způsobem se zprávy při přenosu neztratí.
Producent může omylem poslat stejnou zprávu dvakrát. Instance producenta například selže po odeslání zprávy. Jiný producent nahradí původní instanci a zprávu odešle znovu. Fronty služby Azure Service Bus poskytují integrovanou funkci odstranění duplicit, která detekuje a odebírá duplicitní zprávy. Stále existuje šance, že se zpráva doručí dvakrát. Pokud například příjemce při zpracování selže, zpráva se vrátí do fronty a načte se stejným nebo jiným příjemcem. Logika zpracování zpráv v příjemci by měla být idempotentní, takže i když se práce opakuje, stav systému se nezmění.
Řazení zpráv
Pokud chcete, aby příjemci dostávali zprávy v pořadí, ve kterém se odesílají, fronty služby Service Bus zaručují doručení seřazené jako první v prvním místě (FIFO) pomocí relací. Relace může mít jednu nebo více zpráv. Zprávy korelují s vlastností SessionId . Zprávy, které jsou součástí relace, nikdy nevyprší platnost. Relace může být uzamčena pro příjemce, aby se zabránilo zpracování zpráv jiným příjemcem.
Další informace naleznete v tématu Relace zpráv.
Trvalost zpráv
Fronty služby Service Bus podporují dočasné oddělení. I když příjemce není k dispozici nebo nemůže zprávu zpracovat, zůstane ve frontě.
Dlouhotrvající transakce kontrolního bodu
Obchodní transakce můžou běžet dlouhou dobu. Každá operace v transakci může mít více zpráv. Pomocí kontrolních bodů můžete koordinovat pracovní postup a zajistit odolnost v případě selhání transakce.
Fronty služby Service Bus umožňují vytváření kontrolních bodů prostřednictvím funkce stavu relace. Informace o stavu se přírůstkově zaznamenávají do fronty (SetState) pro zprávy, které patří do relace. Příjemce může například sledovat průběh kontrolou stavu (GetState) vždy a potom. Pokud příjemce selže, může jiný uživatel použít informace o stavu k určení posledního známého kontrolního bodu k obnovení relace.
Fronta nedoručených zpráv (DLQ)
Fronta služby Service Bus má výchozí podřazenou frontu označovanou jako fronta nedoručených zpráv (DLQ), která uchovává zprávy, které se nedají doručit ani zpracovat. Service Bus nebo logika zpracování zpráv v příjemci může přidat zprávy do DLQ. DlQ uchovává zprávy, dokud se nenačtou z fronty.
Tady jsou příklady, kdy může zpráva skončit v DLQ:
Jedovatá zpráva je zpráva, která se nedá zpracovat, protože je poškozená nebo obsahuje neočekávané informace. Ve frontách služby Service Bus můžete zjistit otrávené zprávy nastavením vlastnosti MaxDeliveryCount fronty. Pokud počet přijatých zpráv překročí tuto hodnotu vlastnosti, služba Service Bus přesune zprávu do knihovny DLQ.
Zpráva už nemusí být relevantní, pokud není zpracována během určitou dobu. Fronty služby Service Bus umožňují producentovi publikovat zprávy s atributem time-to-live. Pokud tato doba vyprší před přijetí zprávy, zpráva se umístí do dlQ.
Prozkoumejte zprávy v DLQ a zjistěte důvod selhání.
Hybridní řešení
Service Bus propojuje místní systémy a cloudová řešení. Místní systémy jsou často obtížně dosažitelné kvůli omezením brány firewall. Producent i příjemce (buď může být místní nebo cloud), může jako vyzvednutí a vyřazení zpráv použít koncový bod fronty služby Service Bus.
Vzor mostu zasílání zpráv je dalším způsobem, jak tyto scénáře zpracovat.
Témata a předplatná
Service Bus podporuje model vydavatele a odběratele prostřednictvím témat a odběrů služby Service Bus.
Tato funkce poskytuje producentovi způsob vysílání zpráv více příjemcům. Když téma obdrží zprávu, přepošla se všem předplaceným příjemcům. Volitelně může mít odběr kritéria filtru, která příjemci umožní získat podmnožinu zpráv. Každý příjemce načte zprávy z odběru podobným způsobem jako fronta.
Další informace najdete v tématech služby Azure Service Bus.
Azure Event Grid
Azure Event Grid doporučujeme pro diskrétní události. Event Grid se řídí vzorem vydavatele a odběratele. Když zdroje událostí aktivují události, publikují se do témat Event Gridu. Příjemci těchto událostí vytvářejí odběry event Gridu zadáním typů událostí a obslužné rutiny události, která události zpracuje. Pokud nejsou žádní odběratelé, události se zahodí. Každá událost může mít více odběrů.
Push Model
Event Grid šíří zprávy odběratelům v modelu nabízených oznámení. Předpokládejme, že máte odběr Event Gridu s webhookem. Když přijde nová událost, Event Grid publikuje událost do koncového bodu webhooku.
Integrovaná s Azure
Pokud chcete dostávat oznámení o prostředcích Azure, zvolte Event Grid. Řada služeb Azure funguje jako zdroje událostí, které obsahují integrovaná témata event Gridu. Event Grid také podporuje různé služby Azure, které je možné nakonfigurovat jako obslužné rutiny událostí. K odběru těchto témat se můžete snadno přihlásit a směrovat události do obslužných rutin událostí podle vašeho výběru. Event Grid můžete například použít k vyvolání funkce Azure Functions při vytvoření nebo odstranění úložiště objektů blob.
Vlastní témata
Pokud chcete odesílat události z vaší aplikace nebo ze služby Azure, která není integrovaná se službou Event Grid, vytvořte vlastní témata Event Gridu.
Pokud chcete například vidět průběh celé obchodní transakce, chcete, aby zúčastněné služby vyvolávaly události při zpracování jednotlivých obchodních operací. Tato událost se zobrazí ve webové aplikaci. Jedním ze způsobů, jak tuto úlohu provést, je vytvořit vlastní téma a přidat předplatné s webovou aplikací zaregistrovanou prostřednictvím webhooku HTTP. Když obchodní služby odesílají události do vlastního tématu, Služba Event Grid je odešle do vaší webové aplikace.
Filtrované události
V odběru můžete zadat filtry, které službě Event Grid dávají pokyn, aby směroval pouze podmnožinu událostí do konkrétní obslužné rutiny události. V schématu předplatného zadáte filtry. Každá událost odeslaná do tématu s hodnotami, které odpovídají filtru, se automaticky přepošle do daného odběru.
Například obsah v různých formátech se nahraje do služby Blob Storage. Při každém přidání souboru se vyvolá a publikuje událost do Event Gridu. Odběr událostí může mít filtr, který odesílá události jenom pro obrázky, aby obslužná rutina události mohla generovat miniatury.
Další informace o filtrování najdete v tématu Filtrování událostí pro Event Grid.
Vysoká propustnost
Event Grid může směrovat 10 000 000 událostí za sekundu na oblast. Prvních 100 000 operací za měsíc je zdarma. Informace o nákladech najdete v tématu Kolik stojí Event Grid?
Odolné doručování
I když úspěšné doručování událostí není tak zásadní jako příkazy, můžete v závislosti na typu události přesto chtít nějakou záruku. Event Grid nabízí funkce, které můžete povolit a přizpůsobit, například zásady opakování, čas vypršení platnosti a nedoručených dopisů. Další informace najdete v tématu Doručování zpráv event Gridu a opakování.
Proces opakování služby Event Grid může pomoct s odolností, ale není bezpečný. V procesu opakování může Event Grid zprávu doručit vícekrát, přeskočit nebo zpozdit některé opakování, pokud koncový bod dlouho nereaguje. Další informace najdete v tématu Plán opakování.
Nedoručené události můžete uchovávat v účtu úložiště objektů blob povolením nedoručených dopisů. Doručení zprávy koncovému bodu úložiště objektů blob se zpozdí a pokud tento koncový bod nereaguje, služba Event Grid událost zahodí. Další informace najdete v tématu Nastavení umístění nedoručených písmen a zásad opakování.
Azure Event Hubs
Když pracujete se streamem událostí, azure Event Hubs je doporučeným zprostředkovatelem zpráv. V podstatě jde o velkou vyrovnávací paměť, která dokáže přijímat velké objemy dat s nízkou latencí. Přijatá data je možné rychle číst prostřednictvím souběžných operací. Přijatá data můžete transformovat pomocí libovolného poskytovatele analýz v reálném čase. Služba Event Hubs také poskytuje možnost ukládat události v účtu úložiště.
Rychlý příjem dat
Event Hubs dokáže ingestovat miliony událostí za sekundu. Události se připojují pouze k datovému proudu a jsou seřazené podle času.
Model vyžádané replikace
Podobně jako Event Grid nabízí Event Hubs také možnosti vydavatele a odběratele. Klíčovým rozdílem mezi Event Gridem a Event Hubs je způsob, jakým jsou data událostí zpřístupněna odběratelům. Event Grid odesílá ingestované data odběratelům, zatímco Služba Event Hubs zpřístupňuje data v modelu vyžádané replikace. Při přijetí událostí je služba Event Hubs připojí ke streamu. Odběratel spravuje svůj kurzor a může se pohybovat vpřed a zpět ve streamu, vybrat časový posun a přehrát sekvenci tempem.
Procesory streamů jsou odběratelé, kteří za účelem transformace a statistické analýzy načítají data ze služby Event Hubs. Azure Stream Analytics a Apache Spark můžete použít ke komplexnímu zpracování, jako je agregace v průběhu času nebo detekce anomálií.
Pokud chcete pracovat s každou událostí na oddíl, můžete načíst data pomocí hostitele procesoru událostí nebo pomocí integrovaného konektoru, jako je Azure Logic Apps , a poskytnout tak logiku transformace. Další možností je použít Azure Functions.
dělení na části
Oddíl je část streamu událostí. Události jsou rozděleny pomocí klíče oddílu. Například několik zařízení IoT odesílá data zařízení do centra událostí. Klíč oddílu je identifikátor zařízení. Když se události ingestují, služba Event Hubs je přesune do samostatných oddílů. V rámci každého oddílu jsou všechny události seřazené podle času.
Příjemce je instance kódu, která zpracovává data události. Event Hubs se řídí modelem dělených příjemců. Každý příjemce čte jenom konkrétní oddíl. Výsledkem více oddílů je rychlejší zpracování, protože datový proud může číst souběžně více příjemců.
Instance stejného příjemce tvoří jednu skupinu příjemců. Několik skupin příjemců může číst stejný datový proud s různými záměry. Předpokládejme, že stream událostí obsahuje data ze senzoru teploty. Jedna skupina příjemců může číst stream a zjišťovat anomálie, jako je špička teploty. Další může číst stejný datový proud, aby vypočítal průměrnou teplotu v časovém intervalu.
Event Hubs podporuje model vydavatele a odběratele tím, že umožňuje více skupin příjemců. Každá skupina příjemců je předplatitelem.
Další informace o dělení služby Event Hubs najdete v tématu Oddíly.
Event Hubs Capture
Funkce Capture umožňuje ukládat stream událostí do služby Azure Blob Storage nebo Data Lake Storage. Tento způsob ukládání událostí je spolehlivý, protože i když účet úložiště není dostupný, funkce Capture uchovává vaše data po určitou dobu a po jejich zpřístupnění se zapisuje do úložiště.
Služby úložiště můžou také nabízet další funkce pro analýzu událostí. Když například využijete přístupové úrovně účtu úložiště objektů blob, můžete události ukládat do horké vrstvy pro data, která potřebují častý přístup. Tato data můžete použít pro vizualizaci. Případně můžete ukládat data do archivní úrovně a občas je načíst pro účely auditování.
Funkce Capture ukládá všechny události ingestované službou Event Hubs a je užitečná pro dávkové zpracování. Sestavy dat můžete generovat pomocí funkce MapReduce. Zachycená data můžou sloužit také jako zdroj pravdy. Pokud se při agregaci dat vynechala určitá fakta, můžete se podívat na zachycená data.
Podrobnosti o této funkci najdete v tématu Zachycení událostí prostřednictvím služby Azure Event Hubs ve službě Azure Blob Storage nebo Azure Data Lake Storage.
Podpora pro klienty Apache Kafka
Event Hubs poskytuje koncový bod pro klienty Apache Kafka . Stávající klienti můžou aktualizovat konfiguraci tak, aby odkazovali na koncový bod, a začít odesílat události do služby Event Hubs. Nemusíte provádět žádné změny kódu.
Další informace najdete v tématu Event Hubs pro Apache Kafka.
Scénáře křížového přechodu
V některých případech je výhodné kombinovat dvě služby zasílání zpráv.
Kombinování služeb může zvýšit efektivitu systému zasílání zpráv. Například ve vaší obchodní transakci používáte fronty služby Azure Service Bus ke zpracování zpráv. Fronty, které jsou většinou nečinné a přijímají zprávy občas, jsou neefektivní, protože příjemce neustále dotazuje frontu na nové zprávy. Odběr služby Event Grid můžete nastavit pomocí funkce Azure Functions jako obslužné rutiny události. Pokaždé, když fronta obdrží zprávu a naslouchají žádní příjemci, Event Grid odešle oznámení, které vyvolá funkci Azure Functions, která vyprázdní frontu.
Podrobnosti o připojení služby Service Bus k Event Gridu najdete v přehledu integrace služby Azure Service Bus k Event Gridu.
Referenční architektura podnikové integrace s využitím front zpráv a událostí ukazuje implementaci integrace služby Service Bus do Event Gridu.
Tady je další příklad: Event Grid obdrží sadu událostí, ve kterých některé události vyžadují pracovní postup, zatímco jiné jsou určené pro oznámení. Metadata zprávy označují typ události. Jedním ze způsobů, jak odlišit, je zkontrolovat metadata pomocí funkce filtrování v odběru událostí. Pokud vyžaduje pracovní postup, Event Grid ho odešle do fronty služby Azure Service Bus. Příjemci této fronty mohou provádět nezbytné akce. Události oznámení se odesílají do Logic Apps, aby odesílaly e-maily s upozorněními.
Související vzory
Při implementaci asynchronního zasílání zpráv zvažte tyto vzory:
- Model konkurenčních spotřebitelů: Čtení zpráv z fronty může potřebovat více příjemců. Tento model vysvětluje, jak zpracovávat více zpráv souběžně za účelem optimalizace propustnosti, zlepšení škálovatelnosti a dostupnosti a vyrovnávání zatížení.
- Model prioritní fronty: V případech, kdy obchodní logika vyžaduje, aby se některé zprávy zpracovávaly před ostatními, tento vzor popisuje, jak se zprávy odesílané producentem s vyšší prioritou přijímají a zpracovávají rychleji než zprávy s nižší prioritou.
- Model vyrovnávání zatížení na základě fronty: Tento model používá zprostředkovatele zpráv k tomu, aby fungoval jako vyrovnávací paměť mezi producentem a příjemcem, aby se minimalizoval dopad na dostupnost a odezvu přerušovaných náročných zatížení obou těchto entit.
- Model opakování. Producent nebo spotřebitel se nemusí připojit k frontě, ale důvody tohoto selhání můžou být dočasné a rychlé. Tento model popisuje, jak tuto situaci zvládnout, aby se do aplikace přidala odolnost.
- Model Scheduler Agent Supervisor Zasílání zpráv se často používá jako součást implementace pracovního postupu. Tento model ukazuje, jak může zasílání zpráv koordinovat sadu akcí napříč distribuovanou sadou služeb a dalších vzdálených prostředků a umožnit systému obnovení a opakování akcí, které selžou.
- Skautografický vzor. Tento model ukazuje, jak můžou služby používat zasílání zpráv k řízení pracovního postupu obchodní transakce.
- Model kontroly deklarací identity Tento model ukazuje, jak rozdělit velkou zprávu na kontrolu deklarací identity a datovou část.
Komunitní zdroje
Blogové příspěvky Jonathon Olivera: Idempotency
Blogový příspěvek Martina Fowlera: Co znamená "Event-Driven"?