Aszinkron üzenetkezelési beállítások

Ez a cikk az üzenetkezelési infrastruktúrában részt vevő különböző típusú üzeneteket és entitásokat ismerteti. Az üzenettípusokra vonatkozó követelmények alapján az Azure olyan üzenetkezelési szolgáltatásokat biztosít, amelyek tartalmazzák az Azure Service Bus-üzenetkezelést, az Azure Event Gridet és az Azure Event Hubsot. További információ: Üzenetkezelési szolgáltatások összehasonlítása.

Architekturális szinten a termelői entitás létrehoz egy üzenet-adatgramot az információk terjesztéséhez. A fogyasztói entitások tudomást szereznek az információkról, és ennek megfelelően járnak el. A gyártó és a fogyasztók közvetlenül vagy közvetítő üzenetközvetítő entitáson keresztül kommunikálhatnak. Ez a cikk az üzenetközvetítőt használó aszinkron üzenetküldésre összpontosít.

Az aszinkron üzenetkezelés összetevőit bemutató diagram.

Az üzenetek két fő kategóriával rendelkeznek:

  • A parancs egy üzenet, amely egy adott műveletet kér a fogyasztótól.
  • Az esemény egy üzenet, amely tájékoztatja a fogyasztót a műveletről.

Parancsok

A gyártó egy olyan parancsot küld, amely egy üzleti tranzakción belüli művelet végrehajtására kéri a fogyasztót.

A parancsok olyan nagy értékű üzenetek, amelyek szigorú kézbesítési követelményeket támasztanak. Egy parancsot legalább egyszer le kell kézbesíteni. Ha egy parancs nem éri el a célhelyét, a teljes üzleti tranzakció meghiúsulhat. A legtöbb esetben a felhasználók nem dolgoznak fel többször egy parancsot. A duplikált feldolgozás téves tranzakciókat okozhat, például ismétlődő megrendeléseket vagy kettős számlázást.

A parancsok gyakran kezelik a többhelyes üzleti tranzakciók munkafolyamatát. Az üzleti logikától függően a gyártó elvárhatja, hogy a fogyasztó nyugtázza az üzenetet, és jelentse a művelet eredményeit. Az eredmény alapján a gyártó kiválaszthatja, hogyan folytassa.

Events

Az esemény egy olyan üzenet, amelyet egy előállító generál, hogy bejelentse, hogy valami történt. A gyártó (ebben a kontextusban a közzétevő ) nem várja el, hogy az esemény bármilyen konkrét műveletet eredményez.

Az érdekelt fogyasztók előfizethetnek, meghallgathatják az eseményeket, és a használati forgatókönyvüktől függően műveleteket hajthatnak végre. Az események több előfizetőt is tartalmazhatnak, vagy egyáltalán nem lehetnek előfizetők. A különböző előfizetők különböző műveletekkel, egymástól függetlenül reagálhatnak ugyanarra az eseményre.

A gyártó és a fogyasztó lazán kapcsolódik egymáshoz, és egymástól függetlenül kezelik. A gyártó nem várja el a fogyasztótól, hogy nyugtázza az eseményt a gyártónak. Az események iránt már nem érdekelt fogyasztó leiratkozhat, amely anélkül távolítja el a fogyasztót a folyamatból, hogy az hatással van a gyártóra vagy a rendszer általános működésére.

Az események két kategóriába sorolhatók:

  • Különálló események: A producer eseményeket szervez, hogy bejelentse az egyes tényeket. Gyakori használati eset az eseményértesítés. Az Azure Resource Manager például eseményeket hoz létre, módosít vagy töröl erőforrásokat. A logikai alkalmazások feliratkozhatnak ezekre az eseményekre, és riasztási e-maileket küldhetnek.

  • Eseménystreamek: A gyártó egy sor kapcsolódó eseményt vet fel az idő függvényében. A felhasználók általában statisztikai célokra értékelik a streameket, akár időkereten belül, akár események érkezésekor. A telemetria gyakori használati eset, például a rendszer állapotának és terhelésének monitorozása. Egy másik használati eset az eszközök internetes hálózatáról (IoT) származó események streamelése.

Az eseménytovábbítást a Publisher-Subscriber mintával valósíthatja meg.

Az eseményküldés Publisher-Subscriber mintájának diagramja.

Az üzenetközvetítő szerepe és előnyei

A köztes üzenetközvetítő tárolja és áthelyezi az üzeneteket a gyártótól a fogyasztóhoz. Más előnyöket is biztosíthat.

Szétválasztás

Az üzenetközvetítő elválasztja a gyártó üzenetgenerálási logikáját a fogyasztó üzenetfeldolgozási logikájától. Egy összetett munkafolyamatban ez az elkülönítés segít az üzleti műveletek szétválasztásában és a munkafolyamat koordinálásában.

Vegyünk egy olyan üzleti tranzakciót, amely egymás után különböző műveleteket igényel:

  1. A gyártó kiad egy parancsot, amely arra utasítja a fogyasztót, hogy kezdjen el egy műveletet.

  2. A fogyasztó egy külön válaszsorban nyugtázza az üzenetet, amely a gyártó számára fenntartott válaszok sorba foglalásához van fenntartva.

  3. Miután a gyártó megkapta a választ, egy új üzenetet küld a következő művelet elindításához.

  4. Egy másik fogyasztó feldolgozza azt az üzenetet, és befejező üzenetet küld a válaszsorba.

Az üzenetkezelés használatával a szolgáltatások egymás között koordinálják a tranzakciós munkafolyamatot.

A termelő és a fogyasztó közötti kommunikáció diagramja.

Az üzenetközvetítő időbeli szétválasztást biztosít. A gyártónak és a fogyasztónak nem kell párhuzamosan futnia. A gyártó a fogyasztó elérhetőségétől függetlenül küldhet üzenetet az üzenetközvetítőnek. És a gyártó elérhetősége nem korlátozza a fogyasztót.

Egy webalkalmazás felhasználói felülete például üzeneteket hoz létre, és üzenetközvetítőként egy üzenetsort használ. Ha a fogyasztó készen áll, lekérheti az üzeneteket az üzenetsorból, és elvégezheti a munkát. Az időbeli elkülönítés segít a felhasználói felületnek a válaszkészségben és a letiltás feloldásában, miközben az üzenetek aszinkron módon vannak kezelve.

Egyes műveletek hosszú időt is igénybe vehetnek. Miután a gyártó kiad egy parancsot, nem kell megvárnia, amíg a fogyasztó befejezi a műveletet. Az üzenetközvetítő segít az üzenetek aszinkron feldolgozásában.

Terheléselosztás

A gyártók számos üzenetet tehetnek közzé több felhasználó számára, hogy feldolgozzák. Az üzenetközvetítővel eloszthatja a feldolgozást a kiszolgálók között, és javíthatja az átviteli sebességet. A fogyasztók különböző kiszolgálókon futtathatják a terhelés elosztásához. Igény szerint dinamikusan adhat hozzá vagy távolíthat el felhasználókat a rendszer méretezéséhez.

A versengő fogyasztók mintájának diagramja.

A konkurens fogyasztók mintája egyszerre több üzenetet dolgoz fel az átviteli sebesség optimalizálása, a méretezhetőség és a rendelkezésre állás javítása, valamint a számítási feladat egyensúlyának javítása érdekében.

Terhelés simítás

A termelők különböző üzenetmennyiségeket hoznak létre, amelyek hirtelen megnövekedhetnek. Ahelyett, hogy fogyasztókat ad hozzá a többletterhelés kezeléséhez, egy üzenetközvetítő puffereli az üzeneteket. A felhasználók ezután kezelhető sebességgel dolgozzák fel az üzeneteket a rendszer túlterhelése nélkül.

A várólista-alapú terhelésegyensúlyozási minta diagramja.

További információ: Sor-alapú terhelés-kiegyenlítési minta.

Megbízható üzenetkezelés

Az üzenetközvetítő biztosítja, hogy az üzenetek a gyártó és a fogyasztó közötti kommunikációs hibákon keresztül is megmaradnak. A gyártó üzeneteket küld a közvetítőnek, és a fogyasztó a kommunikáció folytatása után kéri le őket. A gyártót nem blokkolják, kivéve, ha elveszíti a kapcsolatot az üzenetközvetítővel.

Rugalmas üzenetkezelés

Az üzenetközvetítő rugalmasságot ad a rendszer felhasználóinak. Ha egy fogyasztó meghibásodik, miközben feldolgoz egy üzenetet, egy másik fogyasztói példány feldolgozhatja ezt az üzenetet. A közvetítő megőrzi az üzenetet, amely támogatja ezt az újrafeldolgozást.

Nagyméretű üzenetek

Ha a terhelés túllépi az üzenetközvetítő méretkorlátját, vagy ha a felhasználóknak csak alkalmanként kell hozzáférniük a nagy terhelésekhez, használja a Claim-Check mintát. Tárolja a nagy hasznos adatokat egy külső tárolóban, például az Azure Blob Storage-ban. Küldjön egy üzenetet a közvetítőnek, amely egy mutatót tartalmaz a tárolt payloadra. A fogyasztó a mutatóval, amikor szükséges, lekéri a teheradatokat. Ez a megközelítés megakadályozza, hogy a nagy adatgramok túlterhelik a közvetítőt és a fogyasztókat.

Az üzenetközvetítő technológiai lehetőségei

Az Azure számos üzenetközvetítő szolgáltatást biztosít, amelyek mindegyike különböző funkciókkal rendelkezik. Mielőtt kiválaszt egy szolgáltatást, határozza meg az üzenet szándékát és követelményeit.

Service Bus-üzenetkezelés

A Service Bus üzenetsoraival parancsokat továbbíthat a gyártóktól a fogyasztóknak.

Lekéréses modell

A Service Bus-üzenetsor felhasználója folyamatosan lekérdezi a Service Bust, hogy új üzeneteket keressen. A Service Bus ügyféloldali SDK-jai és az Azure-függvények eseményindítója automatikusan kezeli ezt a lekérdezést. Amikor egy üzenet elérhetővé válik, az SDK meghívja a fogyasztó visszahívását, és elküldi az üzenetet a fogyasztónak.

Garantált kézbesítés

A Service Bus egy "peek-lock" mechanizmust használ. Amikor egy fogyasztó lekéri az üzenetet, a Service Bus ideiglenesen zárolja azt. Ez a zár megakadályozza, hogy más fogyasztók feldolgozzák ugyanazt az üzenetet.

A fogyasztónak jelentenie kell az üzenet feldolgozási állapotát. Amikor a fogyasztó felhasználtként jelöli meg az üzenetet, a Service Bus eltávolítja az üzenetet az üzenetsorból. Ha hiba, időtúllépés vagy összeomlás történik, a Service Bus feloldja az üzenetet, hogy más felhasználók is le tudják kérni. Ez a módszer megakadályozza az üzenetek elvesztését az átvitel során.

Előfordulhat, hogy egy gyártó kétszer is ugyanazt az üzenetet küldi el. Például, egy producer példány hibát tapasztal, miután elküld egy üzenetet. Egy másik gyártó lecseréli az eredeti példányt, és újra elküldi az üzenetet. A Service Bus üzenetsorok beépített deduplikációs képességgel rendelkeznek, amely észleli és eltávolítja az ismétlődő üzeneteket. Előfordulhat, hogy a Service Bus még mindig kétszer kézbesít egy üzenetet. Ha például egy fogyasztó a feldolgozás során sikertelen, a Service Bus visszaküldi az üzenetet a sorba, és ugyanaz a fogyasztó vagy egy másik fogyasztó ismét lekéri. A fogyasztó üzenetfeldolgozási logikájának idempotensnek kell lennie, hogy az ismétlődő feldolgozás ne változtassa meg a rendszer állapotát.

Üzenetek sorrendjének meghatározása

Annak érdekében, hogy az üzenetek kézbesítése az elküldött sorrendben történjen, a Service Bus-üzenetsorok munkamenetekkel biztosítják a megrendelt kézbesítést. A munkamenetek egy vagy több üzenetet tartalmazhatnak. A Service Bus a tulajdonság használatával korrelálja az SessionId üzeneteket. A munkamenethez tartozó üzenetek soha nem járnak le. Zárolhat egy munkamenetet egy fogyasztó számára, hogy megakadályozza, hogy egy másik fogyasztó kezelje az üzeneteit.

További információ: Üzenet-munkamenetek.

Üzenetmegőrzés

A Service Bus-üzenetsorok támogatják a tartós időbeli leválasztást. Még akkor is az üzenet várólistán marad, ha egy felhasználó nem érhető el vagy nem tudja feldolgozni az üzenetet.

Ellenőrzőpont a hosszú futásidejű tranzakcióknál

Az üzleti tranzakciók hosszú ideig futtathatók. A tranzakció minden műveletének több üzenete lehet. Az ellenőrzőpontokkal koordinálhatja a munkafolyamatot, és rugalmasságot biztosíthat, ha egy tranzakció meghiúsul.

A Service Bus-üzenetsorok támogatják az ellenőrzőpont-ellenőrzést a munkamenet állapotának képességén keresztül. SetSessionStateAsync A felhasználók a munkamenethez tartozó üzenetek állapotadatait növekményesen rögzítik az üzenetsorban. A fogyasztó például az állapot ellenőrzésére rendszeres hívással GetSessionStateAsync nyomon követheti az előrehaladást. Ha egy fogyasztó meghibásodik, egy másik felhasználó az állapotinformációk segítségével meghatározhatja az utolsó ismert ellenőrzőpontot, és folytathatja a munkamenetet.

Kézbesítetlen levelek üzenetsora

A Service Bus-üzenetsornak van egy alapértelmezett allekérdezése, az úgynevezett kézbesítetlen levelek üzenetsora (DLQ), amely olyan üzenetek tárolására szolgál, amelyeket a Service Bus nem tud kézbesíteni, vagy amelyeket a felhasználók nem tudnak feldolgozni. A Service Bus vagy a fogyasztó üzenetfeldolgozási logikája üzeneteket adhat hozzá a DLQ-hoz. A DLQ mindaddig megőrzi az üzeneteket, amíg egy fogyasztó le nem kéri őket az üzenetsorból.

A Service Bus az alábbi esetekben helyezi át az üzeneteket a DLQ-ba:

  • A méregüzenet olyan üzenet, amelyet a fogyasztó nem tud kezelni, mert helytelenül formázott, vagy váratlan információkat tartalmaz. A Service Bus-üzenetsorokban lévő méregüzenetek észleléséhez állítsa be az MaxDeliveryCount üzenetsor tulajdonságát. Ha a fogyasztó többször kapja meg ugyanazt az üzenetet, mint amennyit ez a tulajdonságérték megenged, a Service Bus áthelyezi az üzenetet a DLQ-ba.

  • Előfordulhat, hogy egy üzenet már nem releváns, ha egy fogyasztó nem dolgozza fel egy adott időszakon belül. A Service Bus üzenetsorok lehetővé teszik, hogy a feladó lejárati idő (TTL) attribútummal tegyen közzé üzeneteket. Ha ez az időszak lejár, mielőtt a fogyasztó megkapja az üzenetet, a Service Bus az üzenetet a DLQ-ban helyezi el.

Ellenőrizze az üzeneteket a DLQ-ban a hiba okának megállapításához. Előfordulhat, hogy nem tudja újra feldolgozni ezeket az üzeneteket, és szükség lehet egy egyéni kompenzáló műveletre.

Hibrid megoldás

A Service Bus helyszíni rendszereket és felhőmegoldásokat köt össze. A helyszíni rendszereket gyakran nehéz elérni a tűzfalkorlátozások miatt. A gyártó és a fogyasztó egyaránt használhatja a helyszíni vagy a felhőbeli Service Bus-üzenetsor végpontot az üzenetek cseréjéhez.

Az Azure Relay hibrid kapcsolatai kulcsrakész implementációt biztosítanak az üzenetalapú, helyszíni kommunikációhoz. Az Azure Relay a Service Busra épül, és kétirányú, kérés-válasz mintákat és adatgramfolyamatokat biztosít.

Az Üzenetkezelési híd mintával is kezelheti ezeket a forgatókönyveket.

Témakörök és előfizetések

A Service Bus témákon és előfizetéseken keresztül támogatja a Publisher-Subscriber mintát.

A témakörök és előfizetések lehetővé teszik, hogy a gyártó üzeneteket közvetítsen több fogyasztónak. Amikor egy témakör üzenetet kap, az minden feliratkozott felhasználónak továbbítja az üzenetet. Igény szerint szűrőfeltételeket is hozzáadhat egy előfizetéshez, így a felhasználók csak az üzenetek egy részhalmazát kapják meg. Minden fogyasztó az üzenetsorhoz hasonló üzeneteket kér le egy előfizetésből.

Tartsa egyszerűnek az útválasztási logikát. Kerülje az összetett üzleti szabályok beágyazását az előfizetési szűrőkbe. Az intelligens végpontok és a buta csövek megközelítésének előnyben részesítése. A közvetítőt megbízható szállításhoz és széles körű útválasztáshoz használhatja, de összetett döntési logikát kezelhet a fogyasztó szolgáltatáson belül.

További információ: Service Bus-témakörök.

Protokollok a Service Busban

A Service Bus az Advanced Message Queueing Protocol (AMQP) protokollt használja az iparági szintű együttműködéshez. A szolgáltatás a Java Message Service (JMS) API szabványt is támogatja.

További információ az üzenetformátum sémájáról: Üzenetek, hasznos adatok és szerializálás.

Event Grid

Az Event Grid használata különálló eseményekhez. Az Event Grid a Publisher-Subscriber mintát követi. Amikor az eseményforrások eseményt aktiválnak, közzéteszik őket az Event Grid-témakörökben. Az események felhasználói eseménytípusok és eseménykezelők megadásával event Grid-előfizetéseket hoznak létre az események feldolgozásához. Minden esemény több előfizetéssel is rendelkezhet.

Leküldő modell az Event Gridben

Az Event Grid tartós leküldéses modellben propagálja az üzeneteket az előfizetőknek. Tegyük fel, hogy webhookkal rendelkező Event Grid-előfizetéssel rendelkezik. Amikor új esemény érkezik, az Event Grid közzéteszi az eseményt a webhook végpontja felé. A leküldéses modellben, ha nincsenek előfizetők, vagy az előfizetők ismétlődően nem válaszolnak, az Event Grid elveti az eseményeket.

Létrehozhat egy egyéni végpontot események fogadásához, ha a végpont a webhook specifikációját követi. Vagy használhat beépített képességeket, például az Azure Functions Event Grid-kötéseit.

Integrálás az Azure-ral

Válassza az Event Gridet, ha értesítéseket szeretne kapni az Azure-erőforrásokról. Számos Azure-szolgáltatás szolgál olyan eseményforrásként, amely beépített Event Grid-témaköröket használ. Az Event Grid különböző Azure-szolgáltatásokat is támogat, amelyeket eseménykezelőként állíthat be. Feliratkozhat ezekre a témakörökre, hogy az eseményeket a választott eseménykezelőkhöz irányíthassa. Az Event Grid használatával például meghívhat egy Azure-függvényt egy tárolóblob létrehozásakor vagy törlésekor.

Egyéni témakörök

Egyéni Event Grid-témaköröket hozhat létre, ha eseményeket szeretne küldeni az alkalmazásból vagy egy olyan Azure-szolgáltatásból, amellyel az Event Grid nem integrálható.

Tegyük fel például, hogy egy teljes üzleti tranzakció előrehaladását szeretné figyelni. A részt vevő szolgáltatások eseményeket szerveznek az egyéni üzleti műveletek feldolgozása során. Egy webalkalmazás megjeleníti ezeket az eseményeket. A monitorozás implementálásához hozzon létre egy egyéni témakört, és adjon hozzá egy előfizetést, amely HTTP-webhookként regisztrálja a webalkalmazást. Amikor az üzleti szolgáltatások eseményeket küldenek az egyéni témakörbe, az Event Grid leküldi az eseményeket a webalkalmazásba.

Szűrt események

Az előfizetésben szűrőket is megadhat, amelyek arra utasítják az Event Gridet, hogy csak az események egy részhalmazát irányítsa egy adott eseménykezelőhöz. Adja meg a szűrőket az előfizetési sémában. Amikor a gyártók eseményeket küldenek a témakörbe, az Event Grid automatikusan csak a szűrőnek megfelelő értékekkel rendelkező eseményeket továbbítja az adott előfizetésnek.

Az alkalmazások például különböző formátumú tartalmakat töltenek fel a Blob Storage-ba. A Blob Storage minden egyes fájl érkezésekor eseményt hoz létre és tesz közzé az Event Gridben. Hozzáadhat egy szűrőt az előfizetéshez, amely csak képekre korlátozza az eseményeket, így az eseménykezelő miniatűröket hozhat létre.

További információt az Event Grid eseményeinek szűrése című témakörben talál.

Nagy átviteli sebesség

Az Event Grid több szinttel rendelkezik a nagy átviteli sebesség és a nagy mennyiségű használati esetek támogatásához. A funkciók rendelkezésre állása és átviteli sebessége szintenként eltérő.

Rugalmas kézbesítés

Az események sikeres kézbesítése kevésbé számít, mint a parancsok esetében, de az esemény típusától függően továbbra is szüksége lehet kézbesítési garanciákra. Az Event Grid minden előfizetéshez legalább egyszer megkísérli kézbesíteni az egyes üzeneteket. Bekapcsolhatja és testre szabhatja az olyan funkciókat, mint az újrapróbálkozási szabályzatok, a lejárati idő és a halott betűzés. További információ: Event Grid üzenetkézbesítés és újrapróbálkozás.

Az Event Grid újrapróbálkozása javítja a rugalmasságot, de nem garantálja a kézbesítést. Az Event Grid több alkalommal is kézbesítheti az üzenetet, kihagyhat vagy késleltethet néhány újrapróbálkozást, ha a végpont hosszabb ideig nem válaszol. További információ: Újrapróbálkozás ütemezése.

Ha bekapcsolja a halott betűket, az Event Grid megőrzi a nem kézbesített eseményeket egy Blob Storage-fiókban. Ha a Blob Storage-végpont nem válaszol, az Event Grid késlelteti a kézbesítést, és végül elveti az eseményt. További információ: Holtbetűhely beállítása és újrapróbálkozás szabályzata.

Az Event Grid nem garantálja az eseménykézbesítés megrendelését.

Lehúzásos modell az Event Gridben

A leküldéses modell mellett az Event Grid támogatja a HTTP-alapú lekéréses kézbesítést , amely üzenetsorszerű szemantikát használ. Ezt a modellt akkor használja, ha az eseményfelhasználók a következő jellemzőkkel rendelkeznek:

  • Események feldolgozása ütemezés szerint ahelyett, hogy folyamatosan
  • Időszakos rendelkezésre állással rendelkezik, amely megakadályozza a megbízható valós idejű leküldéses kézbesítést
  • Privát kapcsolatot igénylő hálózati korlátozások
  • Nem lehet leküldéses értesítési végpontot hozzáférhetővé tenni

Az Event Grid továbbra is a különálló események nagy átviteli sebességű elosztására van optimalizálva, még lekéréses kézbesítés esetén is. Ha a számítási feladat nagyvállalati üzenetkezelési funkciókat igényel, például szigorúan rendezett feldolgozást (munkameneteket), tranzakciókat vagy duplikált észlelést, használja inkább a Service Busot.

Protokollok az Event Gridben

Az Event Grid két eseménysémát támogat:

  • CloudEvents-séma: Az események formátumséma előnyben részesítése. Az eseményadatok leírására szolgáló nyílt specifikáción alapul, és nagy interoperabilitást biztosít a szállítói rendszerek között.

  • Event Grid-séma: Ezt a védett, nem használható formátumsémát csak akkor használja, ha nem tudja használni a CloudEvents sémát. Ez a séma az Event Gridre vonatkozik.

Az Event Grid két protokollt támogat az üzenetközvetítők közötti interakcióhoz:

Event Hubs

Amikor eseménystreamekkel dolgozik, az Event Hubsot használja üzenetközvetítőként. Az Event Hubs kis késéssel pufferel nagy mennyiségű adatot. A pufferből egyszerre több felhasználó is beolvashatja az adatokat. A fogadott adatokat bármely valós idejű elemzési szolgáltatóval átalakíthatja. Az Event Hubs egy tárfiókban is tárolja az eseményeket.

Nagy mennyiségű bevitel

Az Event Hubs másodpercenként több millió eseményt képes feldolgozni. Az Event Hubs hozzáfűzi az eseményeket a streamhez, és idő szerint megrendeli őket.

Lekérési modell az Event Hubsban

Az Event Hubs közzétevő-előfizetői képességeket biztosít. A többi üzenetsor és az Event Hubs közötti lényeges különbség az, hogy az Event Hubs hogyan teszi elérhetővé az eseményadatokat az előfizetők számára. Az Event Hubs egy lekéréses alapú modellt használ, amelyben az eseményeket hozzáfűzi egy streamhez ahelyett, hogy hagyományos üzenetsorba helyezi őket. Az előfizetők kezelhetik a kurzort, és előre és visszaléphetnek a streamben, kijelölhetnek egy időeltolódást, és lejátszhatnak egy sorozatot a tempójukban.

A streamfeldolgozók olyan előfizetők, amelyek adatokat kérnek le az Event Hubsból átalakítási és statisztikai elemzés céljából. Az olyan összetett feldolgozásokhoz, mint az aggregáció az időablakokban vagy az anomáliák észlelésében, használja az Azure Stream Analyticset vagy az Apache Sparkot. Az Event Hubs és a Microsoft Fabric integrálható úgy is, hogy adatokat tölt be az eseményházba , vagy létrehoz egy eseménystreamet.

Az egyes partíciók egyes eseményeinek feldolgozásához használhatja az EventProcessorHostot, a beépített összekötőket, például az Azure Logic Appst vagy az Event Hubs eseményindítóját és kötéseit az Azure Functionshez.

Partitioning

A partíció az eseménystream egy része. Az Event Hubs partíciókulcs használatával osztja el az eseményeket. Több IoT-eszköz például eszközadatokat küld egy eseményközpontba. A partíciókulcs az eszköz azonosítója. Ahogy az Event Hubs betölti az eseményeket, azokat külön partíciókra helyezi át. Az Event Hubs az egyes partíciókon belül az összes eseményt idő szerint rendezi.

A fogyasztó az eseményadatokat feldolgozó kódpéldány. Az Event Hubs particionált fogyasztói mintát követ. Minden fogyasztó csak egy adott partíciót olvas be. Több partíció gyorsabb feldolgozást eredményez, mert egyszerre több felhasználó is elolvashatja a streamet.

Ugyanazon fogyasztó példányai egyetlen fogyasztói csoportot alkotnak. Több fogyasztói csoport is elolvashatja ugyanazt a streamet különböző szándékokkal. Tegyük fel, hogy egy eseményfolyam egy hőmérséklet-érzékelő adataival rendelkezik. Egy fogyasztói csoport elolvashatja a streamet, hogy észlelje az olyan rendellenességeket, mint a hőmérséklet megugrása. Egy másik fogyasztó ugyanazt a streamet olvashatja, hogy kiszámítsa a gördülő átlaghőmérsékletet egy időablakban.

Az Event Hubs több fogyasztói csoporton keresztül valósítja meg a Publisher-Subscriber mintát, ahol minden csoport külön előfizetőként szolgál.

További információ az Event Hubs particionálásáról: Partíciók.

Event Hubs-rögzítés

A rögzítési funkcióval tárolhatja az eseménystreamet a Blob Storage-ban vagy az Azure Data Lake Storage-ban. A Capture megbízható tárolást biztosít, mert az adatokat egy ideig megőrzi, ha a tárfiók nem érhető el, majd a tárterületre ír, miután elérhetővé válik.

A tárolási szolgáltatások további funkciókat is biztosítanak az események elemzéséhez. Egy Blob Storage-fiók hozzáférési szintjeivel például gyakori hozzáférésű adatokhoz tárolhatja az eseményeket egy gyakori szinten. Ezeket az adatokat vizualizációhoz használhatja. Azt is megteheti, hogy az adatokat az archív szinten tárolja, és alkalmanként lekéri naplózási célból.

A Capture tárolja az Event Hubs által fogadott összes eseményt, és kötegelt feldolgozási képességeket biztosít. A MapReduce függvény használatával jelentéseket hozhat létre az adatokról. A rögzített adatok az igazság forrásaként is szolgálhatnak. Ha az összesített adatokból hiányoznak konkrét részletek, lekérheti azokat a rögzített adatokból.

A funkcióval kapcsolatos további információkért lásd: Események rögzítése a Blob Storage-ban vagy a Data Lake Storage-ban található Event Hubson keresztül.

Apache Kafka-ügyfelek támogatása

Az Event Hubs végpontot biztosít az Apache Kafka-ügyfelek számára. A meglévő ügyfelek frissíthetik a konfigurációjukat, hogy a végpontra mutasson, és eseményeket küldjenek az Event Hubsnak. Nem kell módosítania a kódokat.

További információ: Event Hubs for Apache Kafka.

Keresztátvételi forgatókönyvek

Két üzenetkezelési szolgáltatást kombinálhat az előnyök eléréséhez. Ez a megközelítés növeli az üzenetkezelési rendszer hatékonyságát. Tegyük fel például, hogy Service Bus üzenetsorokat használ az üzleti tranzakció üzeneteinek kezeléséhez. Az időnként üzeneteket fogadó tétlen üzenetsorok nem hatékonyak, mert a kliens folyamatosan lekérdezi az üzenetsort új üzenetekért. Event Grid-előfizetést állíthat be, és egy Azure-függvényt használhat eseménykezelőként. Minden alkalommal, amikor az üzenetsor kap egy üzenetet, és nem figyelnek a felhasználók, az Event Grid egy értesítést küld, amely meghívja az Azure-függvényt az üzenetsor kiürítéséhez.

A Service Bus és az Event Grid integrációját bemutató ábra.

További információ: Service Bus–Event Grid integráció áttekintése.

Az üzenetsorokat és eseményeket használó vállalati integrációs architektúra tartalmazza a Service Bus és az Event Grid integrációját.

Egy másik példaként az Event Grid eseménykészletet kap. Egyes eseményekhez munkafolyamatra van szükség, más események pedig értesítéseket váltanak ki. Az üzenet metaadatai az esemény típusát jelzik. A metaadatok ellenőrzéséhez használja a szűrési funkciót az esemény-előfizetésben. Ha egy eseményhez munkafolyamatra van szükség, az Event Grid elküldi azt egy Service Bus-üzenetsorba. Az üzenetsor fogadói elvégezhetik a szükséges műveleteket. Az Event Grid elküldi az értesítési eseményeket a Logic Appsnek riasztási e-mailek küldéséhez.

Az Event Grid és a Service Bus integrációjának diagramja.

Az aszinkron üzenetkezelés megvalósításakor vegye figyelembe az alábbi mintákat:

  • Versengő fogyasztók mintája: Előfordulhat, hogy több fogyasztónak is versengenie kell az üzenetek üzenetsorból való olvasásához. Ez a minta bemutatja, hogyan dolgozhat fel egyszerre több üzenetet az átviteli sebesség optimalizálása, a méretezhetőség és a rendelkezésre állás javítása és a számítási feladatok egyensúlyának javítása érdekében.

  • Prioritási üzenetsor-minta: Ha az üzleti logika rangsoros üzenetfeldolgozást igényel, ez a minta azt ismerteti, hogy a felhasználók hogyan dolgozzák fel a magasabb prioritású üzeneteket az alacsonyabb prioritású üzenetek előtt.

  • Queue-Based terhelésegyenlítési minta: Ez a minta egy üzenetközvetítő használatával pufferként működik a gyártó és a fogyasztó között. Ez a minta segít minimalizálni az időszakos nagy terhelések hatását mind a gyártó, mind a fogyasztó rendelkezésre állására és válaszkészségére.

  • Újrapróbálkozási minta: Átmeneti hibák miatt előfordulhat, hogy az előállítók vagy a fogyasztók ideiglenesen elveszítik az üzenetsorhoz való kapcsolatot. Ez a minta azt ismerteti, hogyan lehet újrapróbálkozási műveleteket végezni átmeneti hibák során az alkalmazás rugalmasságának fenntartása érdekében.

  • Scheduler Agent Supervisor-minta: A munkafolyamatokhoz gyakran üzenetküldésre van szükség az elosztott szolgáltatások koordinálásához. Ez a minta bemutatja, hogyan koordinálja az üzenetkezelés az elosztott műveleteket, és segít a rendszereknek helyreállítani a hibákat a sikertelen műveletek újrapróbálkozásával.

  • Koreográfiai minta: Ez a minta azt mutatja be, hogy a szolgáltatások hogyan használhatják az üzenetkezelést egy üzleti tranzakció munkafolyamatának szabályozására.

  • Claim-Check minta: Ez a minta bemutatja, hogyan szétválasztja a nagy üzenetet egy jogcím-ellenőrzési adatra és egy hasznos terhelésre.

Közösségi erőforrások

  • Last updated on