Ez a cikk az üzenetkezelési infrastruktúrában részt vevő különböző típusú üzeneteket és entitásokat ismerteti. Az egyes üzenettípusok követelményei alapján a cikk az Azure üzenetkezelési szolgáltatásokat javasolja. A lehetőségek közé tartozik az Azure Service Bus Messaging, az Azure Event Grid és az Azure Event Hubs. A termék összehasonlítását lásd : Üzenetkezelési szolgáltatások összehasonlítása.
Architekturális szinten az üzenet egy entitás (gyártó) által létrehozott adatgram, amely információkat terjeszt, hogy más entitások (fogyasztók) tisztában legyenek és ennek megfelelően járjanak el. A gyártó és a fogyasztó közvetlenül vagy opcionálisan kommunikálhat egy közvetítő entitáson (üzenetközvetítőn) keresztül. Ez a cikk az üzenetközvetítővel végzett aszinkron üzenetküldésre összpontosít.
Az üzeneteket két fő kategóriába sorolhatjuk. Ha a gyártó műveletet vár a fogyasztótól, az üzenet egy parancs. Ha az üzenet tájékoztatja a fogyasztót, hogy műveletet hajtottak végre, akkor az üzenet egy esemény.
Parancsok
A gyártó egy parancsot küld azzal a szándékkal, hogy a fogyasztó(k) egy üzleti tranzakció hatókörén belül hajtanak végre egy műveletet.
A parancsok nagy értékű üzenetek, amelyeket legalább egyszer kell kézbesíteni. Ha egy parancs elveszik, a teljes üzleti tranzakció meghiúsulhat. Emellett a parancsokat nem szabad többször feldolgozni. Ez téves tranzakciót okozhat. Előfordulhat, hogy egy ügyfél duplikált megrendeléseket kap, vagy kétszer számlázzák ki.
A parancsokat gyakran használják többhelyes üzleti tranzakciók munkafolyamatának kezelésére. 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ó a megfelelő intézkedési módot választhatja.
Események
Az esemény egy olyan üzenettípus, amelyet egy gyártó a tények bejelentésére hív fel.
A gyártónak (ebben a kontextusban a közzétevőnek ) nincs olyan elvárása, hogy az események bármilyen műveletet eredményeznek.
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. Két különböző előfizető különböző műveletekkel reagálhat egy eseményre, és nem lehet tisztában egymással.
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ényeknek két kategóriája van:
A producer eseményeket hoz fel, hogy bejelentse a különálló 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. Az események előfizetője lehet egy logikai alkalmazás, amely riasztási e-maileket küld.
A gyártó egy adott időszakban sorozatban vagy eseményfolyamban hoz létre kapcsolódó eseményeket. A streamek általában statisztikai kiértékeléshez lesznek felhasználva. A kiértékelés történhet egy időablakban vagy események érkezésekor. A telemetria gyakori használati eset (például egy rendszer állapot- és terhelésfigyelése). Egy másik eset az IoT-eszközökről származó eseménystreamelés.
Az eseménytovábbítás implementálásának gyakori mintája a Publisher-Előfizető minta.
Az üzenetközvetítő szerepe és előnyei
A köztes üzenetközvetítő az üzenetek gyártóról fogyasztóra történő áthelyezésének funkcióját biztosítja, és további előnyöket is kínálhat.
Szétválasztás
Az üzenetközvetítő leválasztja a gyártót a fogyasztótól az üzeneteket létrehozó és használó logikában. Egy összetett munkafolyamatban a közvetítő ösztönözheti az üzleti műveleteket a leválasztásra, és segíthet koordinálni a munkafolyamatot.
Egy üzleti tranzakcióhoz például eltérő műveletek szükségesek, amelyeket üzleti logika szerint hajtanak végre. A gyártó kiad egy parancsot, amely arra utasítja a fogyasztót, hogy kezdjen el egy műveletet. A fogyasztó egy külön üzenetsorban nyugtázza az üzenetet, amely a gyártó válaszainak sorba foglalására van fenntartva. A gyártó csak a válasz beérkezése után küld új üzenetet a következő művelet elindításához a sorozatban. Egy másik fogyasztói folyamat, amely üzenetet küld, és befejező üzenetet küld a válaszsornak. Az üzenetkezelés használatával a szolgáltatások egymás között koordinálják a tranzakció munkafolyamatát.
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. Ezzel szemben a fogyasztót nem korlátozza a gyártó rendelkezésre állása.
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 leválasztás segít a felhasználói felületnek a válaszkészségben. A rendszer nem blokkolja az üzenetek aszinkron kezelése közben.
Bizonyos műveletek végrehajtása hosszú időt vehet igénybe. Miután kiad egy parancsot, a gyártónak nem kell megvárnia, amíg a fogyasztó befejezi azt. Az üzenetközvetítő segít az üzenetek aszinkron feldolgozásában.
Terheléselosztás
A gyártók számos olyan üzenetet tehetnek közzé, amelyeket sok fogyasztó kiszolgál. Az üzenetközvetítővel eloszthatja a feldolgozást a kiszolgálók között, és javíthatja az átviteli sebességet. A felhasználók különböző kiszolgálókon futtathatják a terhelést. A felhasználók dinamikusan bővíthetők a rendszer méretezéséhez, ha szükséges, vagy más módon eltávolíthatók.
A konkurens fogyasztók mintája azt ismerteti, 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, valamint a számítási feladat egyensúlyának javítása érdekében.
Terhelés simítás
A gyártó vagy a gyártócsoport által generált üzenetek mennyisége változó lehet. Időnként előfordulhat, hogy egy nagy kötet miatt megugrik az üzenetek száma. Ahelyett, hogy fogyasztókat ad hozzá a munka kezeléséhez, az üzenetközvetítő pufferként működhet, és a felhasználók fokozatosan üríthetik az üzeneteket a saját tempójukban anélkül, hogy a rendszer terhelését hangsúlyozták.
A várólista-alapú terheléselegyenlítési minta további információkat nyújt.
Megbízható üzenetkezelés
Az üzenetközvetítők biztosítják, hogy az üzenetek ne vesszenek el, még akkor sem, ha a gyártó és a fogyasztó közötti kommunikáció meghiúsul. A gyártó üzeneteket tehet közzé az üzenetközvetítőnek, és a fogyasztó lekérheti őket a kommunikáció újbóli létrehozásakor. A gyártó csak akkor lesz letiltva, ha elveszíti a kapcsolatot az üzenetközvetítővel.
Rugalmas üzenetkezelés
Az üzenetközvetítők rugalmasságot adhatnak a rendszer felhasználóinak. Ha egy fogyasztó egy üzenet feldolgozása során meghiúsul, a fogyasztó egy másik példánya feldolgozhatja ezt az üzenetet. Az újrafeldolgozás azért lehetséges, mert az üzenet megmarad a közvetítőben.
Az üzenetközvetítő technológiai lehetőségei
Az Azure számos üzenetközvetítő szolgáltatást biztosít, amelyek mindegyike számos funkcióval rendelkezik. A szolgáltatás kiválasztása előtt határozza meg az üzenet szándékát és követelményeit.
Azure Service Bus-üzenetkezelés
Az Azure Service Bus Üzenetkezelési üzenetsorok jól használhatók a parancsok gyártóktól a fogyasztókhoz való továbbításához. Íme néhány szempont.
Lekéréses modell
A Service Bus-üzenetsor felhasználója folyamatosan lekérdezi a Service Bust, hogy ellenőrizze, vannak-e új üzenetek. Az ügyféloldali SDK-k és az Azure Functions-eseményindítók a Service Bus absztrakt modellhez. Ha új üzenet érhető el, a rendszer 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 lehetővé teszi a fogyasztó számára, hogy betekintsen az üzenetsorba, és zároljon egy üzenetet más fogyasztóktól.
A fogyasztó felelőssége, hogy jelentse az üzenet feldolgozási állapotát. A Service Bus csak akkor távolítja el az üzenetet az üzenetsorból, ha a fogyasztó a felhasználtként jelöli meg az üzenetet. 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. Így az üzenetek nem vesznek el az átvitel során.
Előfordulhat, hogy egy gyártó kétszer is ugyanazt az üzenetet küldi el. Egy gyártópéldány például egy üzenet elküldése után meghiúsul. Egy másik gyártó lecseréli az eredeti példányt, és újra elküldi az üzenetet. Az Azure Service Bus-üzenetsorok beépített duplikálási képességet biztosítanak, amely észleli és eltávolítja az ismétlődő üzeneteket. Még mindig van rá esély, hogy egy üzenetet kétszer kézbesítenek. Ha például egy fogyasztó a feldolgozás során meghiúsul, az üzenet visszakerül az üzenetsorba, és ugyanaz vagy egy másik fogyasztó kéri le. A fogyasztó üzenetfeldolgozási logikájának idempotensnek kell lennie, így a rendszer állapota akkor sem változik, ha a munka ismétlődik.
Üzenetrendezés
Ha azt szeretné, hogy a felhasználók az üzeneteket az elküldött sorrendben kapják meg, a Service Bus-üzenetsorok munkamenetek használatával garantálják az első előtti kézbesítést (FIFO). A munkamenetek egy vagy több üzenetet tartalmazhatnak. Az üzenetek a SessionId tulajdonsággal vannak korrelálva. A munkamenet részét képező üzenetek soha nem járnak le. A munkamenetek zárolhatók egy fogyasztó számára, hogy megakadályozzák, hogy az üzeneteket egy másik fogyasztó kezelje.
További információ: Üzenet-munkamenetek.
Üzenetmegőrzés
A service bus-üzenetsorok támogatják az időbeli szétválasztást. Még ha egy fogyasztó nem is érhető el, vagy nem tudja feldolgozni az üzenetet, akkor is az üzenetsorban marad.
Ellenőrzőpont hosszú ideig futó tranzakciók
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 egy tranzakció meghiúsulása esetén.
A Service Bus-üzenetsorok lehetővé teszik az ellenőrzőpont-ellenőrzést a munkamenet állapotának képességén keresztül. Az állapotadatok növekményesen lesznek rögzítve az üzenetsorban (SetState) a munkamenethez tartozó üzenetek esetében. A fogyasztók például az állapot (GetState) ellenőrzésével nyomon követhetik az előrehaladást. Ha egy fogyasztó meghibásodik, egy másik felhasználó állapotinformációkat használhat a munkamenet folytatásához használt utolsó ismert ellenőrzőpont meghatározásához.
Kézbesítetlen levelek üzenetsora (DLQ)
A Service Bus-üzenetsornak van egy alapértelmezett allekérdezése, amelyet kézbesítetlen levelek üzenetsorának (DLQ) hívunk, hogy olyan üzeneteket tároljon, amelyeket nem sikerült kézbesíteni vagy 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 le nem kéri őket az üzenetsorból.
Íme néhány példa arra, amikor egy üzenet a DLQ-ban végződhet:
A méregüzenet olyan üzenet, amelyet nem lehet kezelni, mert hibás vagy váratlan információkat tartalmaz. A Service Bus-üzenetsorokban az üzenetsor MaxDeliveryCount tulajdonságának beállításával észlelheti a mérgező üzeneteket. Ha az üzenet fogadásának száma meghaladja ezt a tulajdonságértéket, a Service Bus áthelyezi az üzenetet a DLQ-ba.
Előfordulhat, hogy egy üzenet már nem releváns, ha nem dolgozzák fel egy adott időszakon belül. A Service Bus-üzenetsorok lehetővé teszik a gyártó számára az üzenetek közzétételét egy idő–élő attribútummal. Ha ez az időszak az üzenet fogadása előtt lejár, az üzenet a DLQ-ban lesz elhelyezve.
Vizsgálja meg az üzeneteket a DLQ-ban a hiba okának meghatározásához.
Hibrid megoldás
A Service Bus helyszíni rendszereket és felhőmegoldásokat hidat létesít. A helyszíni rendszereket gyakran nehéz elérni a tűzfalkorlátozások miatt. A gyártó és a fogyasztó (akár a helyszínen, akár a felhőben) használhatja a Service Bus-üzenetsor végpontját az üzenetek felvételi és leküldési helyeként.
Az Üzenetkezelési híd minta egy másik módja ezeknek a forgatókönyveknek.
Témakörök és előfizetések
A Service Bus Service Bus-témakörök és -előfizetések segítségével támogatja a Publisher-Előfizető mintát.
Ez a funkció lehetővé teszi, hogy a gyártó üzeneteket közvetítsen több fogyasztónak. Amikor egy témakör üzenetet kap, a rendszer az összes feliratkozott felhasználónak továbbítja azt. Az előfizetések szűrőfeltételekkel is rendelkezhetnek, amelyek lehetővé teszik a fogyasztó számára az üzenetek egy részhalmazának lekérését. Minden fogyasztó az üzenetsorhoz hasonlóan kéri le az üzeneteket egy előfizetésből.
További információkért tekintse meg az Azure Service Bus témakörét.
Azure Event Grid
A különálló eseményekhez az Azure Event Gridet javasoljuk. Az Event Grid a Publisher-Előfizető mintát követi. Amikor az eseményforrások eseményt aktiválnak, azok közzé lesznek téve az Event Grid-témakörökben. Ezen események felhasználói Event Grid-előfizetéseket hoznak létre az eseményeket feldolgozó eseménytípusok és eseménykezelők megadásával. Ha nincsenek előfizetők, a rendszer elveti az eseményeket. Minden esemény több előfizetéssel is rendelkezhet.
Leküldéses modell
Az Event Grid 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é.
Integrálva 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 olyan eseményforrásként működik, 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, amelyek eseménykezelőként konfigurálhatók. Könnyen 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 blobtároló létrehozásakor vagy törlésekor.
Egyéni témakörök
Hozzon létre egyéni Event Grid-témaköröket, ha az alkalmazásból vagy egy olyan Azure-szolgáltatásból szeretne eseményeket küldeni, amelyek nincsenek integrálva az Event Griddel.
Egy teljes üzleti tranzakció előrehaladásának megtekintéséhez például azt szeretné, hogy a részt vevő szolgáltatások eseményeket emeljenek az egyéni üzleti műveletek feldolgozása során. Egy webalkalmazás megjeleníti ezeket az eseményeket. Ennek a feladatnak az egyik módja, ha létrehoz egy egyéni témakört, és hozzáad egy előfizetést egy HTTP WebHook-on keresztül regisztrált webalkalmazáshoz. Ahogy az üzleti szolgáltatások eseményeket küldenek az egyéni témakörbe, az Event Grid leküldi őket 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. Az előfizetési sémában adja meg a szűrőket. A szűrőnek megfelelő értékeket tartalmazó témakörbe küldött eseményeket a rendszer automatikusan továbbítja az előfizetésnek.
A különböző formátumú tartalmak például feltöltődnek a Blob Storage-ba. Minden alkalommal, amikor hozzáad egy fájlt, a rendszer eseményt hoz létre és közzétevő az Event Gridben. Előfordulhat, hogy az esemény-előfizetés olyan szűrővel rendelkezik, amely csak képekhez küld eseményeket, így az eseménykezelő miniatűröket hozhat létre.
A szűrésről 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 másodpercenként 10 000 000 eseményt irányíthat át régiónként. A havi első 100 000 művelet ingyenes. A költségekre vonatkozó szempontokat az Event Grid mennyibe kerül?
Rugalmas kézbesítés
Annak ellenére, hogy az események sikeres kézbesítése nem olyan fontos, mint a parancsok, az esemény típusától függően még mindig érdemes lehet némi garanciát kapnia. Az Event Grid olyan funkciókat kínál, amelyeket engedélyezhet és testre szabhat, például újrapróbálkozási szabályzatokat, lejárati időt és holt betűt. További információ: Event Grid üzenetkézbesítés és újrapróbálkozás.
Az Event Grid újrapróbálkozása segíthet a rugalmasságban, de nem biztonságos. Az újrapróbálkozás során az Event Grid többször is kézbesítheti az üzenetet, kihagyhat vagy késleltethet néhány újrapróbálkozást, ha a végpont hosszú ideig nem válaszol. További információ: Újrapróbálkozás ütemezése.
A kézbesítetlen eseményeket a blob storage-fiókban is megőrizheti a kézbesítetlen levelek engedélyezésével. Késik az üzenet kézbesítése a Blob Storage-végpontnak, és ha a végpont nem válaszol, az Event Grid elveti az eseményt. További információ: Holtbetűhely beállítása és újrapróbálkozás szabályzata.
Azure Event Hubs
Eseménystream használata esetén az Azure Event Hubs az ajánlott üzenetközvetítő. Lényegében ez egy nagy puffer, amely nagy mennyiségű adatot képes fogadni alacsony késéssel. A fogadott adatok gyorsan olvashatók egyidejű műveleteken keresztül. A fogadott adatokat bármely valós idejű elemzési szolgáltatóval átalakíthatja. Az Event Hubs emellett lehetővé teszi az események tárfiókban való tárolását is.
Gyors betöltés
Az Event Hubs másodpercenként több millió esemény betöltésére képes. Az események csak a streamhez vannak hozzáfűzve, és idő szerint vannak rendezve.
Lekéréses modell
Az Event Gridhez hasonlóan az Event Hubs is kínál Publisher-Előfizető képességeket. Az Event Grid és az Event Hubs közötti fő különbség az, ahogyan az eseményadatok elérhetővé válnak az előfizetők számára. Az Event Grid leküldi a betöltött adatokat az előfizetőknek, míg az Event Hubs egy lekéréses modellben teszi elérhetővé az adatokat. Az események fogadása során az Event Hubs hozzáfűzi őket a streamhez. 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 Azure Stream Analytics és az Apache Spark használata összetett feldolgozáshoz, például az időalapú összesítéshez vagy az anomáliadetektáláshoz.
Ha minden eseményt partíciónként szeretne végrehajtani, lekérheti az adatokat eseményfeldolgozó gazdagép használatával, vagy beépített összekötő, például az Azure Logic Apps használatával az átalakítási logika biztosításához. Egy másik lehetőség az Azure Functions használata.
Particionálás
A partíció az eseménystream egy része. Az események partíciókulcs használatával vannak elosztva. 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. Az események betöltésekor az Event Hubs külön partíciókra helyezi át őket. Az egyes partíciókon belül minden esemény idő szerint van rendezve.
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ó használata gyorsabb feldolgozást eredményez, mivel a streamet egyszerre több felhasználó is elolvashatja.
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. Az egyik fogyasztói csoport beolvassa a streamet, hogy észlelje az olyan rendellenességeket, mint a hőmérséklet megugrása. Egy másik képes olvasni ugyanazt a streamet, hogy kiszámítsa a gördülő átlaghőmérsékletet egy időablakban.
Az Event Hubs több fogyasztói csoport engedélyezésével támogatja a Publisher-Előfizető mintát. Minden fogyasztói csoport előfizető.
További információ az Event Hubs particionálásáról: Partíciók.
Event Hubs Capture
A Rögzítés funkcióval az eseménystreamet egy Azure Blob Storage- vagy Data Lake Storage-tárolóban tárolhatja. Az események tárolásának ez a módja megbízható, mert még ha a tárfiók nem is érhető el, a Capture egy ideig megőrzi az adatokat, majd a rendelkezésre állás után a tárolóba ír.
A tárolási szolgáltatások további funkciókat is kínálnak az események elemzéséhez. Ha például kihasználja a blobtároló-fiókok hozzáférési szintjeit, az eseményeket egy gyakori elérésű adatrétegben tárolhatja. Ezeket az adatokat vizualizációhoz használhatja. Másik lehetőségként tárolhatja az adatokat az archív rétegben, és időnként lekérheti azokat naplózás céljából.
A Capture az Event Hubs által betöltött összes eseményt tárolja, és a kötegelt feldolgozáshoz hasznos. 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 bizonyos tények kimaradtak az adatok összesítése során, hivatkozhat a rögzített adatokra.
A funkcióval kapcsolatos részletekért lásd : Események rögzítése az Azure Event Hubson keresztül az Azure Blob Storage-ban vagy az Azure Data Lake Storage-ban.
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
Bizonyos esetekben előnyös két üzenetkezelési szolgáltatást kombinálni.
A szolgáltatások kombinálása növelheti az üzenetkezelési rendszer hatékonyságát. Az üzleti tranzakcióban például azure Service Bus-üzenetsorokkal kezeli az üzeneteket. A többnyire tétlen és időnként üzeneteket fogadó üzenetsorok nem hatékonyak, mivel a fogyasztó folyamatosan kérdezi le az üzenetsort az új üzenetekhez. Eseménykezelőként beállíthatja az Event Grid-előfizetést egy Azure-függvénnyel. Minden alkalommal, amikor az üzenetsor kap egy üzenetet, és nem figyelnek a felhasználók, az Event Grid értesítést küld, amely meghívja az üzenetsort ürítő Azure-függvényt.
A Service Bus és az Event Grid összekapcsolásával kapcsolatos részletekért tekintse meg az Azure Service Bus és az Event Grid integrációjának áttekintését.
Az üzenetsorokat és események referenciaarchitektúráját használó vállalati integráció a Service Bus és az Event Grid integrációját mutatja be.
Íme egy másik példa: Az Event Grid olyan eseményeket fogad, amelyekben egyes események munkafolyamatot igényelnek, míg mások értesítést kérnek. Az üzenet metaadatai az esemény típusát jelzik. A különbségtétel egyik módja a metaadatok ellenőrzése az esemény-előfizetés szűrési funkciójával. Ha munkafolyamatra van szüksége, az Event Grid elküldi azt az Azure Service Bus-üzenetsorba. Az üzenetsor fogadói elvégezhetik a szükséges műveleteket. Az értesítési eseményeket a Rendszer elküldi a Logic Appsnek a riasztási e-mailek küldéséhez.
Kapcsolódó minták
Az aszinkron üzenetkezelés megvalósításakor vegye figyelembe ezeket a mintákat:
- Versengő felhasználókat ismertető minta. Előfordulhat, hogy több felhasználónak is versengenie kell az üzenetsorból érkező üzenetek 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, valamint a számítási feladat egyensúlyának javítása érdekében.
- Elsőbbségi üzenetsor mintája. Azokban az esetekben, amikor az üzleti logika megköveteli, hogy egyes üzeneteket mások előtt dolgozzanak fel, ez a minta azt írja le, hogy a magasabb prioritású gyártó által közzétett üzeneteket a fogyasztó gyorsabban fogadja és dolgozza fel, mint az alacsonyabb prioritású üzeneteket.
- Üzenetsor-alapú terheléskiegyenlítési minta. Ez a minta egy üzenetközvetítő használatával pufferként működik egy gyártó és egy fogyasztó között, hogy a lehető legkisebbre csökkentse az időszakosan nagy terhelések rendelkezésre állására és válaszképességére gyakorolt hatást mindkét entitás esetében.
- Újrapróbálkozási minta. Előfordulhat, hogy egy gyártó vagy fogyasztó nem tud csatlakozni egy üzenetsorhoz, de a hiba okai ideiglenesek és gyorsan átadhatók. Ez a minta azt ismerteti, hogyan kezelheti ezt a helyzetet, hogy rugalmasságot adjon egy alkalmazáshoz.
- Scheduler Agent Supervisor minta. Az üzenetkezelést gyakran használják munkafolyamat-implementáció részeként. Ez a minta bemutatja, hogyan koordinálhatja az üzenetkezelés a műveletek egy halmazát elosztott szolgáltatások és más távoli erőforrások között, és hogyan teszi lehetővé a rendszer számára a sikertelen műveletek helyreállítását és újrapróbálkozását.
- 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.
- Jogcím-ellenőrzési minta. Ez a minta bemutatja, hogyan oszthat fel nagy méretű üzeneteket jogcím-ellenőrzésre és hasznos adatokra.
Közösségi források
Jonathon Oliver blogbejegyzése: Idempotency
Martin Fowler blogbejegyzése: Mit jelent az "eseményvezérelt"?