Aszinkron üzenetkezelési minták és magas rendelkezésre állás

Az aszinkron üzenetkezelés többféleképpen is implementálható. Az üzenetsorokkal, témakörökkel és előfizetésekkel Azure Service Bus támogatja az aszinkronizálást egy áruházi és továbbítási mechanizmuson keresztül. Normál (szinkron) művelet esetén üzeneteket küld az üzenetsoroknak és a témaköröknek, és üzeneteket fogad az üzenetsorokból és az előfizetésekből. Az ön által írt alkalmazások attól függnek, hogy ezek az entitások mindig elérhetők-e. Amikor az entitás állapota számos körülmény miatt megváltozik, egy olyan csökkentett képességű entitást kell biztosítania, amely a legtöbb igényt kielégíti.

Az alkalmazások általában aszinkron üzenetkezelési mintákat használnak számos kommunikációs forgatókönyv engedélyezéséhez. Létrehozhat olyan alkalmazásokat, amelyekben az ügyfelek üzeneteket küldhetnek a szolgáltatásoknak, még akkor is, ha a szolgáltatás nem fut. A kommunikációcsúcsokat tapasztaló alkalmazások esetében az üzenetsorok segíthetnek a terhelés simításában azáltal, hogy helyet biztosítanak a kommunikáció puffereléséhez. Végül egy egyszerű, de hatékony terheléselosztót kaphat az üzenetek több gép közötti elosztásához.

Ezen entitások rendelkezésre állásának fenntartása érdekében fontolja meg számos különböző módszert, amelyekkel ezek az entitások elérhetetlennek tűnhetnek egy tartós üzenetkezelő rendszer számára. Általánosságban elmondható, hogy az entitás elérhetetlenné válik az általunk írt alkalmazások számára az alábbi módokon:

• Nem lehet üzeneteket küldeni.
• Nem lehet üzeneteket fogadni.
• Az entitások nem kezelhetők (entitások létrehozása, lekérése, frissítése vagy törlése).
• Nem sikerült kapcsolatba lépni a szolgáltatással.

Ezen hibák mindegyikénél különböző hibamódok léteznek, amelyek lehetővé teszik az alkalmazások számára, hogy bizonyos szintű csökkentett kapacitással végezhessék a munkát. Például egy olyan rendszer, amely üzeneteket tud küldeni, de nem fogadja őket, továbbra is fogadhat rendeléseket az ügyfelektől, de nem tudja feldolgozni ezeket a rendeléseket. Ez a témakör az esetlegesen előforduló problémákat és a problémák elhárításának módját ismerteti. A Service Bus számos olyan kockázatcsökkentést vezetett be, amelyet önnek kell engedélyeznie, és ez a témakör a jóváhagyási kockázatcsökkentések használatára vonatkozó szabályokat is ismerteti.

Megbízhatóság a Service Busban

Az üzenetekkel és az entitásokkal kapcsolatos problémák többféleképpen is kezelhetők, és a kockázatcsökkentések megfelelő használatára vonatkozó irányelvek is vonatkoznak. Az irányelvek megértéséhez először meg kell értenie, hogy mi hiúsulhat meg a Service Busban. Az Azure-rendszerek kialakítása miatt ezek a problémák általában rövid életűek. Magas szinten az elérhetetlenség különböző okai a következők:

• Szabályozás olyan külső rendszerről, amelytől a Service Bus függ. A szabályozás a tárolási és számítási erőforrásokkal való interakciókból következik be.
• Olyan rendszer hibája, amelytől a Service Bus függ. A tárterület egy adott része például problémákba ütközhet.
• A Service Bus meghibásodása egyetlen alrendszeren. Ebben az esetben a számítási csomópont inkonzisztens állapotba kerül, és újra kell indítania magát, ami az összes olyan entitást eredményezi, amely a többi csomópont terheléselosztásához szolgál. Ez viszont rövid ideig tartó lassú üzenetfeldolgozást okozhat.
• A Service Bus hibája egy Azure-adatközpontban. Ez egy "katasztrofális hiba", amely során a rendszer több percig vagy néhány óráig nem érhető el.

Megjegyzés

A storage kifejezés az Azure Storage-ot és a SQL Azure is jelentheti.

A Service Bus számos megoldást tartalmaz ezekre a problémákra. Az alábbi szakaszok az egyes problémákat és azok megoldásait ismertetik.

Throttling

A Service Bus segítségével a szabályozás lehetővé teszi az együttműködésen alapuló üzenetsebesség-kezelést. Minden egyes Service Bus-csomópont számos entitásnak ad otthont. Ezen entitások mindegyike a processzor, a memória, a tárolás és más szempontok tekintetében követeli meg a rendszert. Ha ezen aspektusok bármelyike észleli a meghatározott küszöbértékeket meghaladó használatot, a Service Bus megtagadhat egy adott kérést. A hívó foglalt kiszolgálói kivételt kap, és 10 másodperc után újrapróbálkozásokat kezdeményez.

Kockázatcsökkentésként a kódnak be kell olvasnia a hibát, és le kell állítania az üzenet újrapróbálkozását legalább 10 másodpercig. Mivel a hiba az ügyfélalkalmazás egyes részeiben fordulhat elő, várhatóan minden egyes elem egymástól függetlenül hajtja végre az újrapróbálkozás logikáját. A kód csökkentheti a szabályozás valószínűségét azáltal, hogy engedélyezi a particionálást egy névtéren, üzenetsoron vagy témakörön.

További információ arról, hogy az alkalmazáskódnak hogyan kell kezelnie a szabályozási problémákat, tekintse meg a szabályozási mintával kapcsolatos dokumentációt.

Azure-függőség problémái

Az Azure más összetevői időnként szolgáltatásproblémákkal is rendelkezhetnek. Ha például egy Service Bus által használt rendszert frissít, az ideiglenesen csökkentett képességeket tapasztalhat. Az ilyen típusú problémák megkerülése érdekében a Service Bus rendszeresen vizsgálja és implementálja a kockázatcsökkentéseket. A kockázatcsökkentések mellékhatásai megjelennek. A tárolóval kapcsolatos átmeneti problémák kezeléséhez például a Service Bus olyan rendszert implementál, amely lehetővé teszi az üzenetküldési műveletek következetes működését. A kockázatcsökkentés természetéből adódóan az elküldött üzenetek akár 15 percig is eltarthatnak, amíg megjelennek az érintett üzenetsorban vagy előfizetésben, és készen állnak egy fogadási műveletre. Általánosságban elmondható, hogy a legtöbb entitás nem tapasztalja ezt a problémát. Az Azure-on belüli Service Busban található entitások száma miatt azonban ez a kockázatcsökkentés néha a Service Bus-ügyfelek egy kis részhalmazához szükséges.

Service Bus-hiba egyetlen alrendszeren

Bármilyen alkalmazás esetén a körülmények miatt a Service Bus belső összetevője inkonzisztenssé válhat. Amikor a Service Bus ezt észleli, adatokat gyűjt az alkalmazásból a történtek diagnosztizálásához. Az adatok összegyűjtése után az alkalmazás újraindul, és megpróbálja azt konzisztens állapotba visszaküldeni. Ez a folyamat viszonylag gyorsan történik, és egy entitás úgy tűnik, hogy akár néhány percig sem érhető el, bár a tipikus leállási idők sokkal rövidebbek.

Ezekben az esetekben az ügyfélalkalmazás időtúllépési kivételt vagy üzenetküldési kivételt hoz létre. A Service Bus a probléma megoldását automatizált ügyfél-újrapróbálkozás-logika formájában tartalmazza. Ha az újrapróbálkozási időszak kimerült, és az üzenet nem érkezik meg, a szolgáltatáskimaradások és katasztrófák kezeléséről szóló cikkben említett egyéb lehetőségeket is megismerheti.

Következő lépések

Most, hogy megismerte az aszinkron üzenetkezelés alapjait a Service Busban, további részleteket olvashat a szolgáltatáskimaradások és a katasztrófák kezeléséről.