Engedélyezheti egy alkalmazás számára, hogy több érdeklődő fogyasztó számára aszinkron módon, a küldők és a fogadók összekapcsolása nélkül jelentsen be eseményeket.
Más néven: Pub/sub messaging
Kontextus és probléma
A felhőalapú és elosztott alkalmazásokban a rendszer összetevőinek gyakran kell információkat szolgáltatnia más összetevőknek az események bekövetkeztekor.
Az aszinkron üzenetkezelés hatékonyan leválaszthatja a feladókat a fogyasztóktól, és elkerülheti, hogy a feladó megvárja a választ. Az egyes felhasználók számára dedikált üzenetsor használata azonban nem hatékonyan méretezhető sok felhasználóra. Emellett előfordulhat, hogy egyes fogyasztókat csak az információk egy részhalmaza érdekel. Hogyan jelentheti be a feladó az eseményeket az összes érdekelt fogyasztónak anélkül, hogy ismerné az identitásukat?
Megoldás
Vezessen be egy aszinkron üzenetkezelési alrendszert, amely a következőket tartalmazza:
A feladó által használt bemeneti üzenetkezelési csatorna. A feladó egy ismert üzenetformátum használatával üzenetekbe csomagolja az eseményeket, és ezeket az üzeneteket a bemeneti csatornán keresztül küldi el. A mintában szereplő feladót közzétevőnek is nevezik.
Feljegyzés
Az üzenet egy adatcsomag. Az esemény egy üzenet, amely értesíti a többi összetevőt egy módosításról vagy egy végrehajtott műveletről.
Fogyasztónként egy kimeneti üzenetküldő csatorna. A fogyasztókat előfizetőknek nevezzük.
Egy mechanizmus, amellyel az egyes üzeneteket a bemeneti csatornáról a kimeneti csatornákra másolhatja az üzenet iránt érdeklődő összes előfizető számára. Ezt a műveletet általában egy közvetítő, például egy üzenetközvetítő vagy egy eseménybusz kezeli.
Az alábbi ábra a minta logikai összetevőit mutatja be:
A pub/alüzenetek az alábbi előnyökkel járnak:
Leválasztja azokat az alrendszereket, amelyeknek továbbra is kommunikálniuk kell. Az alrendszerek egymástól függetlenül felügyelhetők, és az üzenetek akkor is megfelelően kezelhetők, ha egy vagy több fogadó offline állapotban van.
Növeli a méretezhetőséget, és javítja a feladó válaszkészségét. A feladó gyorsan küldhet egyetlen üzenetet a bemeneti csatornának, majd visszatérhet az alapvető feldolgozási feladataihoz. Az üzenetkezelési infrastruktúra feladata, hogy az üzeneteket az érdekelt előfizetőknek kézbesítse.
Ez növeli a megbízhatóságot. Az aszinkron üzenetkezelés segítségével az alkalmazások továbbra is zökkenőmentesen futhatnak a megnövekedett terhelések mellett, és hatékonyabban kezelhetik az időszakos hibákat.
Lehetővé teszi a halasztott vagy ütemezett feldolgozást. Az előfizetők megvárhatják az üzenetek felvételét a csúcsidőn kívüli időpontig, vagy az üzenetek irányíthatók vagy feldolgozhatók egy adott ütemezés szerint.
Egyszerűbb integrációt tesz lehetővé a különböző platformokat, programozási nyelveket vagy kommunikációs protokollokat használó rendszerek, valamint a felhőben futó helyszíni rendszerek és alkalmazások között.
Megkönnyíti az aszinkron munkafolyamatokat egy vállalaton belül.
Javítja a tesztelhetőséget. A csatornák monitorozása és az üzenetek egy átfogó integrációs tesztstratégia részeként vizsgálhatók vagy naplózhatók.
Elkülöníti az alkalmazásokkal kapcsolatos aggályokat. Minden alkalmazás az alapvető képességeire összpontosíthat, míg az üzenetkezelési infrastruktúra mindent kezel, ami ahhoz szükséges, hogy megbízhatóan irányíthassa az üzeneteket több felhasználónak.
Problémák és megfontolandó szempontok
A minta megvalósítása során az alábbi pontokat vegye figyelembe:
Meglévő technológiák. Kifejezetten ajánlott olyan elérhető üzenetkezelési termékeket és szolgáltatásokat használni, amelyek támogatják a közzétételi-előfizetési modellt ahelyett, hogy sajátot építenek ki. Az Azure-ban fontolja meg a Service Bus, az Event Hubs vagy az Event Grid használatát. A pub/alüzenetekhez használható egyéb technológiák közé tartozik a Redis, a RabbitMQ és az Apache Kafka.
Előfizetés kezelése. Az üzenetkezelési infrastruktúrának olyan mechanizmusokat kell biztosítania, amelyekkel a felhasználók feliratkozhatnak vagy leiratkozhatnak az elérhető csatornákról.
Biztonság. Az üzenetcsatornákhoz való csatlakozást biztonsági szabályzatnak kell korlátoznia, hogy megakadályozza a jogosulatlan felhasználók vagy alkalmazások általi lehallgatást.
Az üzenetek részhalmazai. Az előfizetőket általában csak a közzétevő által terjesztett üzenetek részhalmaza érdekli. Az üzenetkezelési szolgáltatások gyakran lehetővé teszik az előfizetők számára, hogy szűkítse a következő üzenetek által fogadott üzeneteket:
- Témák. Minden témakör dedikált kimeneti csatornával rendelkezik, és minden fogyasztó feliratkozhat az összes releváns témakörre.
- Tartalomszűrés. Az üzeneteket az egyes üzenetek tartalma alapján vizsgáljuk meg és terjesztjük. Minden előfizető megadhatja, hogy melyik tartalom érdekli.
Helyettesítő karakterek előfizetői. Fontolja meg, hogy az előfizetők helyettesítő karaktereken keresztül több témakörre is előfizethessenek.
Kétirányú kommunikáció. A közzétételi-előfizetési rendszerek csatornái egyirányúként lesznek kezelve. Ha egy adott előfizetőnek vissza kell küldenie a visszaigazolást, vagy vissza kell küldenie az állapotot a közzétevőnek, fontolja meg a Kérés/Válasz minta használatát. Ez a minta egy csatornával küld üzenetet az előfizetőnek, és egy külön válaszcsatornát a közzétevővel való kommunikációhoz.
Üzenetrendezés. Az a sorrend, amelyben a fogyasztói példányok üzeneteket fogadnak, nem garantált, és nem feltétlenül tükrözi az üzenetek létrehozásának sorrendjét. Úgy tervezze meg a rendszert, hogy az üzenetfeldolgozás idempotens legyen, hogy kiküszöbölje az üzenetkezelés sorrendjének függőségét.
Üzenet prioritása. Egyes megoldásokhoz szükség lehet az üzenetek meghatározott sorrendben történő feldolgozására. A prioritási üzenetsor-minta mechanizmust biztosít bizonyos üzenetek mások elé való kézbesítéséhez.
Méregüzenetek. Ha egy helytelenül formázott üzenet vagy feladat olyan erőforrásokhoz igényel hozzáférést, amelyek nem érhetők el, az a szolgáltatáspéldány sikertelen működéséhez vezethet. A rendszernek meg kell akadályoznia, hogy az ilyen üzenetek visszakerüljenek az üzenetsorba. Ehelyett rögzítse és tárolja az üzenetek részleteit máshol, hogy szükség esetén elemezhetőek legyenek. Egyes üzenetközvetítők, például az Azure Service Bus, támogatják ezt a kézbesítetlen levelek üzenetsor-funkcióin keresztül.
Ismétlődő üzenetek. Előfordulhat, hogy ugyanazt az üzenetet többször is elküldi a rendszer. Előfordulhat például, hogy a feladó meghiúsul egy üzenet közzététele után. Ezután előfordulhat, hogy a feladó egy új példánya elindul, és megismétli az üzenetet. Az üzenetkezelési infrastruktúrának ismétlődő üzenetészlelést és -eltávolítást (más néven duplikálást) kell megvalósítania az üzenetazonosítók alapján annak érdekében, hogy az üzenetek kézbesítése a lehető leghamarabb történjen. Másik lehetőségként, ha olyan üzenetkezelési infrastruktúrát használ, amely nem törli az üzeneteket, győződjön meg arról, hogy az üzenetfeldolgozási logika idempotens.
Üzenet lejárata. Előfordulhat, hogy egy üzenet élettartama korlátozott. Ha nem dolgozzák fel ebben az időszakban, lehet, hogy már nem releváns, és el kell vetni. A feladó megadhat egy lejárati időt az üzenet adatainak részeként. A fogadók megvizsgálhatják ezeket az információkat, mielőtt eldöntik, hogy végrehajtják-e az üzenethez társított üzleti logikát.
Üzenetütemezés. Előfordulhat, hogy egy üzenet ideiglenesen embargózva van, és csak egy adott dátum és időpont után lehet feldolgozni. Az üzenet csak ebben az esetben érhető el a fogadó számára.
Előfizetők horizontális felskálázása. Ha egy adott előfizető nem tudja lépést tartani a fogadott üzenetek arányával, a Versengő fogyasztók minta használatával skálázhatja fel.
Mikor érdemes ezt a mintát használni?
Használja ezt a mintát, ha:
Egy alkalmazásnak jelentős számú fogyasztónak kell adatokat közvetítenie.
Az alkalmazásoknak egy vagy több egymástól függetlenül fejlesztett alkalmazással vagy szolgáltatással kell kommunikálniuk, amelyek különböző platformokat, programozási nyelveket és kommunikációs protokollokat használhatnak.
Az alkalmazások anélkül küldhetnek információkat a fogyasztóknak, hogy valós idejű választ kérnek a fogyasztóktól.
Az integrálandó rendszerek úgy vannak kialakítva, hogy támogassák az adataik konzisztenciamodelljének végső támogatását.
Egy alkalmazásnak több felhasználóval kell kommunikálnia az információkat, amelyek eltérő rendelkezésre állási követelményekkel vagy üzemidő-ütemezéssel rendelkezhetnek, mint a feladó.
Nem érdemes ezt a mintát használni, ha:
Egy alkalmazásnak csak néhány olyan felhasználója van, akiknek jelentősen eltérő információra van szükségük az előállító alkalmazástól.
Az alkalmazások közel valós idejű interakciót igényelnek a felhasználókkal.
Számítási feladatok tervezése
Az építészeknek értékelniük kell, hogyan használható a publisher/előfizetői minta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:
Pillér | Hogyan támogatja ez a minta a pillércélokat? |
---|---|
A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítani, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön. | Az ebben a mintában bevezetett függetlenítés független megbízhatósági célokat tesz lehetővé az összetevőkön, és eltávolítja a közvetlen függőségeket. - RE:03 Hibamód elemzése - RE:07 Háttérfeladatok |
A biztonsági tervezési döntések segítenek biztosítani a számítási feladatok adatainak és rendszereinek titkosságát, integritását és rendelkezésre állását. | Ez a minta egy fontos biztonsági szegmentálási határt vezet be, amely lehetővé teszi az üzenetsor-előfizetők hálózati elkülönítését a közzétevőtől. - SE:04 Szegmentálás |
A költségoptimalizálás a számítási feladatok megtérülésének fenntartására és javítására összpontosít. | Ez a leválasztott kialakítás lehetővé teszi az eseményvezérelt megközelítést az architektúrában, amely jól párosul a fogyasztásalapú számlázással a túlterjedés elkerülése érdekében. - CO:05 Díjoptimalizálás - CO:12 skálázási költségek |
Az operatív kiválóság szabványosított folyamatok és a csapat kohéziója révén segít a számítási feladatok minőségének biztosításában. | Ez a közvetett réteg lehetővé teszi, hogy biztonságosan módosítsa a megvalósítást a közzétevő vagy az előfizetői oldalon anélkül, hogy mindkét összetevő módosításait koordinálnia kellene. - OE:06 Számítási feladatok fejlesztése - OE:11 Biztonságos üzembe helyezési eljárások |
A teljesítményhatékonyság a skálázás, az adatok és a kód optimalizálásával segíti a számítási feladatok hatékony kielégítését . | A közzétevők fogyasztóktól való leválasztásával optimalizálhatja a számítást és a kódot kifejezetten arra a feladatra, amelyet a fogyasztónak el kell végeznie az adott üzenethez. - PE:02 Kapacitástervezés - PE:05 Skálázás és particionálás |
Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.
Példa
Az alábbi ábrán egy vállalati integrációs architektúra látható, amely a Service Bus használatával koordinálja a munkafolyamatokat, az Event Grid pedig értesíti az alrendszereket az eseményekről. További információ: Vállalati integráció az Azure-ban üzenetsorok és események használatával.
Következő lépések
A minta megvalósításakor az alábbi útmutatás lehet releváns:
Válasszon az üzeneteket kézbesítő Azure-szolgáltatások közül.
Az aszinkron üzenetkezelés ismertetése. Az üzenetsorok aszinkron típusú kommunikációs mechanizmusok. Ha a feldolgozói szolgáltatásnak választ kell küldenie egy alkalmazásnak, szükség lehet valamilyen válaszüzenet-küldés alkalmazására. Az aszinkron üzenetkezelés ismertetése információkat nyújt a kérelem/válasz típusú üzenetküldés üzenetsorok használatával történő megvalósításával kapcsolatban.
A minta megvalósításakor a következő minták lehetnek relevánsak:
Megfigyelő minta. A Publish-Subscribe minta a megfigyelői mintára épül azáltal, hogy leválasztja az alanyokat a megfigyelőktől aszinkron üzenetkezeléssel.
Üzenetközvetítő minta. A közzétételi-előfizetési modellt támogató üzenetkezelő alrendszerek közül számos implementálható üzenetközvetítőn keresztül.
Ez a blogbejegyzés a sorrendből érkező üzenetek kezelésének különböző módjait ismerteti.
Kapcsolódó erőforrások
- Az eseményvezérelt architektúrastílus egy olyan architektúrastílus, amely pub-/alüzenet-küldést használ.
- Idempotens üzenetfeldolgozás
- Nagyvállalati integráció az Azure-ban üzenetsorok és események használatával