Részleges hiba kezelése

Tipp.

Ez a tartalom egy részlet a .NET-alkalmazásokhoz készült .NET-alkalmazásokhoz készült eBook, .NET Microservices Architecture című eBookból, amely elérhető a .NET Docs-on vagy egy ingyenesen letölthető PDF-fájlként, amely offline módban is olvasható.

PDF letöltése

Az elosztott rendszerekben, például a mikroszolgáltatás-alapú alkalmazásokban mindig fennáll a részleges meghibásodás kockázata. Előfordulhat például, hogy egyetlen mikroszolgáltatás/tároló meghibásodik, vagy nem érhető el rövid ideig, vagy egyetlen virtuális gép vagy kiszolgáló összeomlhat. Mivel az ügyfelek és a szolgáltatások különálló folyamatok, előfordulhat, hogy egy szolgáltatás nem tud időben válaszolni az ügyfél kérésére. Előfordulhat, hogy a szolgáltatás túlterhelt, és nagyon lassan válaszol a kérésekre, vagy egyszerűen nem érhető el rövid ideig hálózati problémák miatt.

Vegyük például az eShopOnContainers mintaalkalmazás Rendelés részletei oldalát. Ha a rendelési mikroszolgáltatás nem válaszol, amikor a felhasználó megpróbál elküldeni egy megrendelést, az ügyfélfolyamat (az MVC-webalkalmazás) hibás megvalósítása – például ha az ügyfélkód szinkron RPC-ket használna időtúllépés nélkül – blokkolná a válaszra váró, határozatlan ideig várakozó szálakat. A rossz felhasználói élmény létrehozása mellett minden nem válaszoló várakozás felhasznál vagy blokkol egy szálat, és a szálak rendkívül értékesek a nagymértékben méretezhető alkalmazásokban. Ha sok blokkolt szál van, az alkalmazás futtatókörnyezete végül elfogyhat a szálakból. Ebben az esetben az alkalmazás globálisan nem válaszolhatóvá válhat ahelyett, hogy csak részlegesen nem válaszol, ahogyan a 8–1. ábrán látható.

8-1. ábra. Részleges hibák a szolgáltatáslánc rendelkezésre állását befolyásoló függőségek miatt

Egy nagy mikroszolgáltatás-alapú alkalmazásban minden részleges hiba felerősödhet, különösen akkor, ha a belső mikroszolgáltatások közötti interakciók többsége szinkron HTTP-hívásokon alapul (ez anti-minta). Gondoljon egy olyan rendszerre, amely naponta több millió bejövő hívást fogad. Ha a rendszer rossz kialakítású, amely a szinkron HTTP-hívások hosszú láncán alapul, ezek a bejövő hívások több millió kimenő hívást eredményezhetnek (tegyük fel, hogy az arány 1:4) és több tucat belső mikroszolgáltatás szinkron függőségek. Ez a helyzet a 8–2. ábrán látható, különösen a 3. függőségnél, amely elindít egy láncot, meghívja a 4. függőséget, majd meghívja az 5.

8-2. ábra. A HTTP-kérések hosszú láncait tartalmazó helytelen kialakítás hatása

Az időszakos meghibásodások garantáltak az elosztott és felhőalapú rendszerekben, még akkor is, ha minden függőség kiváló rendelkezésre állással rendelkezik. Ezt figyelembe kell vennie.

Ha nem tervez és implementál olyan technikákat, amelyek biztosítják a hibatűrést, még a kis állásidők is felerősödhetnek. Például a rendelkezésre állás 99,99%-ával rendelkező 50 függőség havonta több órányi állásidőt eredményezne a hullámos hatás miatt. Ha egy mikroszolgáltatás-függőség nagy mennyiségű kérés kezelése közben meghiúsul, ez a hiba gyorsan telítheti az összes elérhető kérésszálat az egyes szolgáltatásokban, és összeomolhatja a teljes alkalmazást.

8-3. ábra. Részleges hiba, amelyet a mikroszolgáltatások felerősítettek a szinkron HTTP-hívások hosszú láncaival

A probléma minimalizálása érdekében az Aszinkron mikroszolgáltatás-integráció a mikroszolgáltatások önállóságát kényszeríti ki, ez az útmutató arra ösztönzi, hogy aszinkron kommunikációt használjon a belső mikroszolgáltatások között.

Emellett elengedhetetlen, hogy mikroszolgáltatásait és ügyfélalkalmazásait úgy tervezhesse meg, hogy kezelni tudják a részleges hibákat, vagyis rugalmas mikroszolgáltatásokat és ügyfélalkalmazásokat építsenek ki.

Előzőkövetkező