Možnosti asynchronního zasílání zpráv

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 na typ zprávy poskytuje Azure služby zasílání zpráv, mezi které patří zasílání zpráv služby Azure Service Bus, Azure Event Grid a Azure Event Hubs. Další informace najdete v tématu Porovnání služeb zasílání zpráv.

Na úrovni architektury vytvoří entita producenta datagram zpráv pro distribuci informací. Spotřebitelé si uvědomí informace a podle toho jednají. Producent a příjemci mohou komunikovat přímo nebo prostřednictvím zprostředkující entity zprostředkovatele zpráv . Tento článek se zaměřuje na asynchronní zasílání zpráv, které používá zprostředkovatele zpráv.

Diagram znázorňuje tok, který začíná producentem, přejde do zprostředkovatele zpráv a končí příjemcem.

Zprávy mají dvě hlavní kategorie:

• Příkaz je zpráva, která požaduje konkrétní akci od příjemce.
• Událost je zpráva, která informuje příjemce, že došlo k akci.

Příkazy

Producent odešle příkaz, který požádá příjemce o provedení operace v rámci obchodní transakce.

Příkaz je zpráva s vysokou hodnotou, která má přísné požadavky na doručení. Příkaz musí být doručen alespoň jednou. Pokud příkaz nedosáhne svého cíle, může selhat celá obchodní transakce. Ve většině případů by uživatelé neměli zpracovávat příkaz více než jednou. Duplicitní zpracování může způsobit chybné transakce, jako jsou duplicitní objednávky nebo dvojité účtování.

Příkazy často spravují pracovní postup 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, jak pokračovat.

Events

Událost je zpráva, kterou producent vyšle, aby oznámil, že se něco stalo. Producent (známý jako vydavatel v tomto kontextu) nemá žádné očekávání, že událost způsobí jakoukoli konkrétní 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 jejich spotřeby. Události mohou mít více odběratelů nebo vůbec žádné odběratele. Různí odběratelé můžou reagovat na stejnou událost s různými akcemi nezávisle na sobě.

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.

Události mají dvě kategorie:

• Diskrétní události: Producent vyvolá události, které oznamují jednotlivá 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ů. Aplikace logiky se může přihlásit k odběru těchto událostí a odesílat e-maily s upozorněními.

• Streamy událostí: Producent v průběhu času vyvolá posloupnost souvisejících událostí. Spotřebitelé obvykle vyhodnocují datové proudy pro statistické účely, a to buď v časovém intervalu, nebo při příchodu událostí. Telemetrie je běžný případ použití, jako je monitorování stavu a zatížení systému. Další případ použití zahrnuje streamování událostí ze zařízení IoT (Internet of Things).

Zasílání událostí můžete implementovat pomocí vzoruPublisher-Subscriber.

Vydavatel odešle zprávy do centrální komponenty zprávy, která pak tyto zprávy doručí dvěma odběratelům, označeným odběrateli A a odběrateli B.

Role a výhody zprostředkovatele zpráv

Zprostředkující zprostředkovatel zpráv ukládá a přesouvá zprávy od producenta do příjemce. Může také poskytovat další výhody.

Rozpojení

Zprostředkovatel zpráv odděluje logiku generování zpráv producenta od logiky zpracování zpráv příjemce. V komplexním pracovním postupu vám toto oddělení pomůže oddělit obchodní operace a koordinovat pracovní postup.

Představte si obchodní transakci, která vyžaduje různé operace v posloupnosti:

1. Producent vydá pokyn konzumentovi ke spuštění operace.

2. Příjemce přijímá zprávu v samostatné frontě odpovědí, která je vyhrazena pro řazení odpovědí pro producenta.

3. Jakmile producent obdrží odpověď, odešle novou zprávu, která spustí další operaci.

4. 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 transakční pracovní postup mezi sebou.

Diagram znázorňující producenta na levé straně Producent odešle dva samostatné datové proudy zpráv do dvou front zpráv. Každá fronta odesílá zprávy odpovídajícímu příjemci označenému příjemcem A a příjemci B. Oba příjemci odesílají odpovědi zpět do sdílené fronty odpovědí a pak producentovi.

Zprostředkovatel zpráv poskytuje časové rozpojení. Producent a spotřebitel nemusí fungovat současně. Producent může zprostředkovateli zpráv odeslat zprávu bez ohledu na dostupnost příjemce. Dostupnost producenta neomezí spotřebitele.

Například uživatelské rozhraní webové aplikace generuje zprávy a jako zprostředkovatel zpráv používá frontu. Až bude spotřebitel připravený, může načíst zprávy z fronty a provést úkoly. Časové oddělení pomáhá uživatelskému rozhraní zůstat responzivní a neblokované, když se zprávy zpracovávají asynchronně.

Některé operace můžou trvat delší dobu. Jakmile producent vydá příkaz, neměl by čekat, dokud příjemce operaci nedokončí. Zprostředkovatel zpráv pomáhá zpracovávat zprávy asynchronně.

Vyrovnávání zatížení

Producenti můžou publikovat velký počet zpráv, které může zpracovat více příjemců. Použití zprostředkovatele zpráv k distribuci zpracování mezi servery a zlepšení propustnosti. Konzumenti mohou pracovat na různých serverech, aby se úloha rozložila. Podle potřeby můžete dynamicky přidávat nebo odebírat uživatele pro škálování systému.

Diagram znázorňující instanci aplikace na levé straně Odesílá zprávy do jedné fronty zpráv uprostřed. Z této fronty ukazují tři šipky na tři samostatné instance příjemců napravo, které představují fond příjemců, kteří zpracovávají zprávy paralelně.

Model Konkurenční spotřebitelé zpracovává 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í

Producenti generují různé objemy zpráv, které můžou náhle narůst. Místo přidávání spotřebitelů ke zpracování dodatečného zatížení ukládá zprostředkovatel zpráv zprávy do vyrovnávací paměti. Uživatelé pak zpracovávají zprávy v zvládnutelném tempu, aniž by došlo k přetížení systému.

Tři producenti na levé straně ukazují na centrální frontu zpráv. Jedna šipka ukončí frontu na jednoho příjemce na pravé straně. Pod diagramem se nachází pruhový graf označující požadavky přijaté proměnlivou frekvencí s nerovnoměrnými pruhy. Další pruhový graf označený jako zprávy zpracovávané ve více konstantní frekvenci má více jednotných pruhů.

Další informace najdete v tématu vzor vyrovnávání zátěže založený na frontě.

Spolehlivé zasílání zpráv

Zprostředkovatel zpráv zajišťuje, že zprávy potrvají prostřednictvím selhání komunikace mezi producentem a příjemcem. ** Producent odesílá zprávy zprostředkovateli a příjemce je načítá, jakmile je obnovena komunikace. Producent zůstane neomezený, pokud neztratí spojení se zprostředkovatelem zpráv.

Odolné zasílání zpráv

Zprostředkovatel zpráv zvyšuje odolnost uživatelů ve vašem systému. Pokud příjemce selže při zpracování zprávy, může tuto zprávu zpracovat jiná instance příjemce. Zprostředkovatel uchovává zprávu, která podporuje toto opětovné zpracování.

Velké zprávy

Pokud datová část překročí limit velikosti zprostředkovatele zpráv nebo když uživatelé potřebují přístup k velkým datovým částem jen občas, použijte vzorClaim-Check. Uložte velkou datovou část do externího úložiště, jako je Azure Blob Storage. Odešle zprostředkovatele zprávu, která obsahuje ukazatel na uloženou datovou část. Spotřebitel v případě potřeby získá datovou část pomocí ukazatele. Tento přístup brání tomu, aby velké datagramy zahltily zprostředkovatele a spotřebitele.

Technologické volby pro zprostředkovatele zpráv

Azure poskytuje několik služeb zprostředkovatele zpráv, které mají různé funkce. Než zvolíte službu, určete záměr a požadavky zprávy.

Zasílání zpráv služby Service Bus

Fronty zasílání zpráv Service Bus slouží k přenosu příkazů od producentů k příjemcům.

Model na vyžádání

Spotřebitel fronty služby Service Bus neustále kontroluje službu Service Bus, aby zjistil nové zprávy. Klientské sady SDK a trigger Azure Functions pro Service Bus zpracovávají toto dotazování automaticky. Jakmile bude zpráva dostupná, sada SDK vyvolá zpětné volání příjemce a doručí zprávu příjemci.

Zaručené doručení

Service Bus používá mechanismus peek-lock. Když příjemce načte zprávu, Service Bus ji dočasně uzamkne. Tento zámek brání ostatním příjemcům ve zpracování stejné zprávy.

Příjemce musí nahlásit stav zpracování zprávy. Když příjemce označí zprávu jako spotřebovanou, Service Bus zprávu odebere 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. Tento přístup zabraňuje ztrátě zpráv během přenosu.

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 Service Bus poskytují vestavěnou schopnost zabraňování duplicitám, která zjišťuje a odebírá duplicitní zprávy. Service Bus může zprávu pořád doručovat dvakrát. Pokud například příjemce při zpracování selže, service Bus vrátí zprávu do fronty a stejný příjemce nebo jiný příjemce ji znovu načte. Logika zpracování zpráv příjemce by měla být idempotentní, aby opakované zpracování nezměnilo stav systému.

Řazení zpráv

Aby se zajistilo, že se zprávy doručují v pořadí, v jakém byly odeslány, fronty služby Service Bus používají relace pro zajištění seřazeného doručení. Relace může mít jednu nebo více zpráv. Service Bus koreluje zprávy pomocí SessionId vlastnosti. Zprávy, které patří do relace, nejsou časově omezené. Relaci můžete uzamknout pro spotřebitele, abyste zabránili jinému spotřebiteli ve zpracování zpráv.

Další informace naleznete v tématu Sezení zpráv.

Trvalost zpráv

Fronty služby Service Bus podporují trvalé časové oddělení. I když je příjemce nedostupný nebo nemůže zprávu zpracovat, zůstane ve frontě.

Kontrolní bod dlouhotrvajících transakcí

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 podporují vytváření kontrolních bodů prostřednictvím schopnosti spravovat stav relace. Příjemci používají SetSessionStateAsync k přírůstkovém záznamu informací o stavu ve frontě pro zprávy, které patří do relace. Příjemce může například sledovat průběh pravidelným voláním GetSessionStateAsync ke kontrole stavu. Pokud příjemce selže, může jiný příjemce použít informace o stavu k určení posledního známého kontrolního bodu a obnovení relace.

Fronta nedoručených zpráv

Fronta služby Service Bus má výchozí podřadku označovanou jako fronta nedoručených zpráv (DLQ), která uchovává zprávy, které Service Bus nemůže doručit nebo které příjemci nemůžou 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 je příjemce nenačte z fronty.

Service Bus přemístí zprávy do DLQ v následujících případech:

• Jedovatá zpráva je taková, kterou příjemce nemůže zpracovat, protože je chybně formátovaná nebo obsahuje neočekávané informace. Chcete-li detekovat otrávené zprávy ve frontách služby Service Bus, nastavte MaxDeliveryCount vlastnost fronty. Pokud příjemce obdrží stejnou zprávu vícekrát, než jaká je povolena podle této hodnoty vlastnosti, Service Bus ji přesune do DLQ.

• Zpráva už nemusí být relevantní, pokud ji příjemce během určitého období nezpracuje. Fronty služby Service Bus umožňují producentovi publikovat zprávy s atributem TTL (Time to Live). Pokud platnost tohoto období vyprší, než příjemce obdrží zprávu, služba Service Bus zprávu umístí do dlQ.

Zkontrolujte zprávy v DLQ a určete důvod selhání. Možná nebudete moct tyto zprávy znovu zpracovat a možná budete potřebovat vlastní kompenzační akci.

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 a spotřebitel, ať už místně, nebo v cloudu, mohou použít koncový bod fronty služby Service Bus v cloudu jako místo pro výměnu zpráv.

Azure Relay Hybrid Connections poskytuje kompletní řešení pro komunikaci napříč místy založenou na zprávách. Služba Azure Relay je založená na službě Service Bus a poskytuje obousměrné vzory odpovědí na požadavky a toky datagramu.

K řešení těchto scénářů můžete použít také model mostu zasílání zpráv .

Témata a předplatná

Service Bus podporuje vzor Publisher-Subscriber prostřednictvím témat a odběrů.

Témata a odběry umožňují producentovi vysílat zprávy více příjemcům. Když téma obdrží zprávu, přepošla ji všem přihlášeným uživatelům. Volitelně můžete do odběru přidat kritéria filtru, aby příjemci dostávali jenom podmnožinu zpráv. Každý konzument získává zprávy z odběru, podobně jako ve frontě.

Udržujte logiku směrování jednoduchou. Vyhněte se vkládání složitých obchodních pravidel do filtrů předplatného. Preferujte přístup inteligentních koncových bodů a jednoduchého potrubí. Použijte zprostředkovatele pro spolehlivé přenosy a rozsáhlé směrování, ale řešte složité rozhodovací logiky v rámci služby.

Další informace najdete v tématech služby Service Bus.

Protokoly ve službě Service Bus

Service Bus používá protokol AMQP (Advanced Message Queueing Protocol) pro interoperabilitu na úrovni celého odvětví. Tato služba také podporuje standard rozhraní Java Message Service (JMS) API.

Další informace o schématu formátu zprávy naleznete v tématu Zprávy, datové části a serializace.

Event Grid

Event Grid slouží k diskrétním událostem. Event Grid se řídí vzorem Publisher-Subscriber. Když zdroje událostí aktivují události, publikují je do témat Event Gridu. Příjemci těchto událostí vytvářejí odběry služby Event Grid zadáním typů událostí a obslužné rutiny události pro zpracování událostí. Každá událost může mít více odběrů.

Push model ve službě Event Grid

Event Grid může doručovat zprávy odběratelům v trvalém push modelu. Předpokládejme, že máte předplatné Event Gridu s webhookem. Když přijde nová událost, Event Grid publikuje událost do koncového bodu webhooku. Pokud v modelu nabízených oznámení neexistují žádní odběratelé nebo odběratelé opakovaně nereagují, Služba Event Grid události zahodí.

Pokud koncový bod dodržuje specifikaci webhooku, můžete vytvořit vlastní koncový bod pro příjem událostí. Nebo můžete použít integrované funkce, jako jsou vazby Event Gridu pro Azure Functions.

Integrujte s Azure

Pokud chcete dostávat oznámení o prostředcích Azure, zvolte Event Grid. Řada služeb Azure slouží jako zdroje událostí, které obsahují integrovaná témata event Gridu. Event Grid také podporuje různé služby Azure, které můžete nastavit jako obslužné rutiny událostí. Můžete se přihlásit k odběru těchto témat 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 při vytváření nebo odstraňování objektu blob úložiště.

Vlastní témata

Pokud chcete odesílat události z vaší aplikace nebo ze služby Azure, se kterou event Grid neintegruje, vytvořte vlastní témata Event Gridu.

Předpokládejme například, že chcete sledovat průběh celé obchodní transakce. Zúčastněné služby vyvolávají události během zpracování svých individuálních obchodních operací. Tato událost se zobrazí ve webové aplikaci. Pokud chcete toto monitorování implementovat, vytvořte vlastní téma a přidejte předplatné, které vaši webovou aplikaci zaregistruje jako webhook HTTP. Když obchodní služby odesílají události do vlastního tématu, Služba Event Grid odešle události do vaší webové aplikace.

Filtrované události

V odběru můžete zadat filtry, které udávají službě Event Grid pokyn, aby směroval pouze podmnožinu událostí do specifického zpracovatele událostí. Zadejte filtry ve schématu předplatného. Když producenti odesílají události do tématu, Event Grid automaticky předává pouze události s hodnotami, které odpovídají filtru pro dané předplatné.

Aplikace například nahrávají obsah v různých formátech do služby Blob Storage. Blob Storage vyvolá a publikuje událost do Event Gridu při každém přijetí souboru. Do odběru můžete přidat filtr, který omezuje události jenom na obrázky, aby obslužná rutina události vygenerovala miniatury.

Další informace najdete v tématu Filtrování událostí pro Event Grid.

Vysoká propustnost

Event Grid má několik vrstev , které podporují případy použití s vysokou propustností a vysokým objemem. Dostupnost a propustnost funkcí se liší podle úrovně.

Odolné doručování

Úspěšné doručování událostí je důležité méně než u příkazů, ale v závislosti na typu události můžete přesto chtít záruky doručení. Event Grid se pokusí doručit každou zprávu alespoň jednou pro každé předplatné. Můžete zapnout a přizpůsobit funkce, jako jsou 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 Grid a opakování.

Proces opakování služby Event Grid zlepšuje odolnost, ale nezaručuje doručení. Event Grid může zprávu doručit vícekrát, přeskočit nebo zpozdit některé opakování, když koncový bod po delší dobu nereaguje. Další informace najdete v tématu Plán opakování.

Když zapnete záznam nedoručených událostí, Služba Event Grid ukládá nedoručené události do účtu služby Blob Storage. Pokud koncový bod služby Blob Storage přestane reagovat, Služba Event Grid zpožďuje doručení a nakonec událost zahodí. Další informace najdete v tématu Nastavení umístění nedoručených písmen a zásad opakování.

Event Grid nezaručuje pořadí při doručování událostí.

Vyžádání modelu ve službě Event Grid

Kromě push modelu služba Event Grid podporuje pull doručování na základě protokolu HTTP, které používá sémantiku podobnou frontě. Tento model použijte, pokud mají příjemci událostí následující charakteristiky:

• Zpracování událostí podle plánu místo průběžného zpracování
• Neustálá dostupnost brání spolehlivému doručení oznámení v reálném čase pomocí push technologie.
• Máte omezení sítě, která vyžadují privátní propojení
• Nelze zveřejnit koncový bod pro push oznámení

Event Grid zůstává optimalizovaný pro distribuci diskrétních událostí s vysokou propustností, dokonce i s pull doručováním. Pokud vaše úloha vyžaduje funkce podnikového zasílání zpráv, jako je přísně uspořádané zpracování (relace), transakce nebo detekce duplicit, použijte místo toho Service Bus.

Protokoly ve službě Event Grid

Event Grid podporuje dvě schémata událostí:

• Schéma CloudEvents: Upřednostňujte toto schéma formátu pro události. Je založená na otevřené specifikaci pro popis dat událostí a poskytuje vysokou interoperabilitu mezi systémy dodavatelů.

• Schéma Event Gridu: Toto proprietární schéma formátu používejte pouze v případě, že nemůžete použít schéma CloudEvents. Toto schéma je specifické pro Event Grid.

Event Grid podporuje dva protokoly pro interakci zprostředkovatele zpráv:

• Vlastní rozhraní API pro publikování HTTP pro příjem událostí do systému pro distribuci.

• Funkce zprostředkovatele přenosu telemetrie pro MQTT (Message Queuing Telemetry Transport), která umožňuje klientům MQTT publikovat a odebírat zprávy. Tato funkce může například poskytovat obousměrnou komunikaci pro scénáře IoT.

Centra událostí

Při práci se streamy událostí použijte službu Event Hubs jako zprostředkovatele zpráv. Event Hubs ukládá velké objemy dat do vyrovnávací paměti s nízkou latencí. Více uživatelů může číst data souběžně z vyrovnávací paměti. Přijatá data můžete transformovat pomocí libovolného poskytovatele analýz v reálném čase. Event Hubs také ukládá události do účtu úložiště.

Vysoký objem příjmu

Event Hubs může ingestovat miliony událostí za sekundu. Event Hubs připojí události ke streamu a objednává je podle času.

Vyžádání modelu ve službě Event Hubs

Event Hubs poskytuje funkce vydavatele a odběratele. Klíčovým rozdílem mezi jinými frontami a službou Event Hubs je způsob, jakým služba Event Hubs zpřístupňuje data událostí odběratelům. Služba Event Hubs používá model založený na vyžádání, ve kterém připojuje události do streamu místo jejich umístění do tradiční fronty. 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ří načítají data ze služby Event Hubs pro transformaci a statistickou analýzu. Pro komplexní zpracování, jako je agregace v průběhu času nebo detekce anomálií, použijte Azure Stream Analytics nebo Apache Spark. Event Hubs můžete také integrovat s Microsoft Fabric načtením dat do centra událostí nebo vytvořením streamu událostí.

Ke zpracování jednotlivých událostí v jednotlivých oddílech můžete použít EventProcessorHost, integrované konektory, jako jsou Azure Logic Apps nebo triggery a vazby služby Event Hubs pro Azure Functions.

Partitioning

Oddíl je část streamu událostí. Služba Event Hubs rozděluje události 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í. Vzhledem k tomu, že Event Hubs přijímá události, přesouvá je do samostatných oddílů. V rámci každého oddílu služba Event Hubs řadí všechny události chronologicky.

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 jen určitý oddíl. Více oddílů vede k rychlejšímu zpracování, protože stream může souběžně číst 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 detekovat anomálie, jako je špička teploty. Jiný uživatel může číst stejný datový proud, aby vypočítal průměrnou teplotu v časovém intervalu.

Služba Event Hubs implementuje model Publisher-Subscriber prostřednictvím více skupin příjemců, kde každá skupina slouží jako samostatný odběratel.

Další informace o dělení služby Event Hubs najdete v tématu Oddíly.

Zachytávání služby Event Hubs

Funkci zachycení můžete použít k uložení datového proudu událostí ve službě Blob Storage nebo Azure Data Lake Storage. Capture poskytuje spolehlivé úložiště, protože uchovává vaše data po určitou dobu v případě, že účet úložiště není dostupný, a poté zapíše data do úložiště, jakmile bude dostupné.

Služby úložiště také poskytují další funkce pro analýzu událostí. Například pomocí úrovní přístupu účtu Blob Storage můžete ukládat události v horké vrstvě pro data, která potřebují častý přístup. Tato data můžete použít pro vizualizaci. Případně můžete data ukládat do archivní úrovně a občas je načíst pro účely auditování.

Capture ukládá všechny události, které služba Event Hubs ingestuje, a poskytuje možnosti dávkového zpracování. Sestavy dat můžete generovat pomocí funkce MapReduce. Zachycená data můžou sloužit také jako zdroj pravdy. Pokud v agregovaných datech chybí konkrétní podrobnosti, můžete je načíst ze zachycených dat.

Další informace o této funkci najdete v tématu Zachycení událostí prostřednictvím služby Event Hubs ve službě Blob Storage nebo 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 překrývání

Můžete zkombinovat dvě služby zasílání zpráv, abyste získali výhody. Tento přístup zvyšuje efektivitu systému zasílání zpráv. Předpokládejme například, že používáte fronty služby Service Bus ke zpracování zpráv při obchodních transakcích. Nečinné fronty, které občas přijímají zprávy, vytvářejí neefektivitu tím, že spotřebitel neustále prohlíží frontu kvůli novým zprávám. Jako obslužnou rutinu události můžete nastavit odběr event Gridu a použít funkci Azure. Pokaždé, když fronta obdrží zprávu a žádní příjemci neposlouchají, služba Event Grid odešle oznámení, které vyvolá funkci Azure pro vyprázdnění fronty.

Na levé straně fronta služby Service Bus odesílá zprávy. V centru odesílá odběr Služby Event Grid oznámení. Odběr Služby Event Grid odkazuje na aplikaci logiky, která vyprázdní frontu.

Další informace najdete v tématu Přehled integrace služby Service Bus do event Gridu.

Architektura podnikové integrace, která používá fronty zpráv a události, zahrnuje integraci služby Service Bus do služby Event Grid.

Jako další příklad přijímá Event Grid sadu událostí. Některé události vyžadují pracovní postup a jiné události aktivují oznámení. Metadata zprávy označují typ události. Pokud chcete zkontrolovat metadata, použijte funkci filtrování v odběru událostí. Pokud událost vyžaduje pracovní postup, Služba Event Grid ji odešle do fronty služby Service Bus. Příjemci této fronty mohou provádět konkrétní akce. Event Grid odesílá události oznámení do Logic Apps, aby odesílala e-maily s upozorněními.

Na levé straně události skupiny prostředků odkazují na odběr, který filtruje události na základě metadat. Z předplatného odkazuje jedna šipka na frontu služby Service Bus, která ukládá příkazy. Další šipka odkazuje na aplikaci logiky, která odesílá e-maily s upozorněními.

Související vzory

Při implementaci asynchronního zasílání zpráv zvažte následující vzory:

• Model konkurenčních příjemců: Více příjemců může potřebovat soutěžit o čtení zpráv z fronty. 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: Pokud obchodní logika vyžaduje zpracování zpráv s prioritou, tento model popisuje, jak spotřebitelé zpracovávají zprávy s vyšší prioritou před zprávami s nižší prioritou.

• Queue-Based vzorec vyrovnávání zatížení: Tento vzorec používá zprostředkovatele zpráv k tomu, aby sloužil jako vyrovnávací paměť mezi producentem a příjemcem. Tento model pomáhá minimalizovat dopad přerušovaných náročných zatížení na dostupnost a odezvu producenta i spotřebitele.

• Model opakování: Producenti nebo příjemci můžou dočasně ztratit připojení k frontě kvůli přechodným selháním. Tento model popisuje, jak opakovat operace během přechodných selhání, aby se zachovala odolnost aplikace.

• Vzor Scheduler Agent Supervisor: Pracovní postupy často vyžadují zasílání zpráv ke koordinaci distribuovaných služeb. Tento model ukazuje, jak zasílání zpráv koordinuje distribuované akce a pomáhá systémům zotavit se ze selhání opakováním neúspěšných operací.

• Model hierarchie: Tento model ukazuje, jak mohou služby používat zasílání zpráv k řízení pracovního postupu obchodní transakce.

• Claim-Check pattern: Tento vzorec ukazuje, jak rozdělit velkou zprávu na claim check a datovou část.

Komunitní zdroje

• Blogový příspěvek: Idempotence
• Blogový příspěvek: Co myslíte řízeným událostmi?