Megosztás a következőn keresztül:

Javaslatok az átmeneti hibák kezelésére

Ez az útmutató a felhőalkalmazások átmeneti hibáinak kezelésére vonatkozó javaslatokat ismerteti. A távoli szolgáltatásokkal és erőforrásokkal kommunikáló összes alkalmazásnak érzékenynek kell lennie az átmeneti hibákra. Ez különösen igaz a felhőben futó alkalmazásokra, ahol a környezet jellege és az interneten keresztüli kapcsolat miatt az ilyen típusú hibák valószínűleg gyakrabban fordulnak elő. Az átmeneti hibák közé tartozik az összetevők és szolgáltatások hálózati kapcsolatának pillanatnyi megszakadása, a szolgáltatás ideiglenes elérhetetlensége, valamint a szolgáltatás foglaltsága esetén bekövetkező időtúllépések. Ezek a hibák gyakran önjavítóak, így ha a műveletet megfelelő késleltetés után megismétlik, akkor valószínűleg sikerrel jár.

Ez a cikk általános útmutatást nyújt az átmeneti hibakezeléshez. Az átmeneti hibák kezelésére szolgáló újrapróbálkozások alkalmazáskódban való implementálásával kapcsolatos információkért tekintse meg az újrapróbálkozási mintát , valamint az Azure-szolgáltatások újrapróbálkozási útmutatóját.

Átmeneti hibák

Átmeneti hibák bármilyen környezetben, bármilyen platformon vagy operációs rendszeren, valamint bármilyen alkalmazásban előfordulhatnak. A helyi helyszíni infrastruktúrán futó megoldások esetében az alkalmazás és összetevői teljesítménye és rendelkezésre állása általában költséges és gyakran kihasználatlan hardveres redundancián keresztül marad fenn, az összetevők és erőforrások pedig egymás közelében találhatók. Ez a megközelítés kevésbé valószínű, de átmeneti hibák továbbra is előfordulhatnak, ahogy az olyan előre nem látott események, mint a külső áramellátás vagy a hálózati problémák, vagy a vészforgatókönyvek által okozott kimaradások is.

A felhőalapú üzemeltetés, beleértve a magánfelhőrendszereket is, magasabb általános rendelkezésre állást kínálhat megosztott erőforrások, redundancia, automatikus feladatátvétel és dinamikus erőforrás-kiosztás használatával számos értékes számítási csomóponton. A felhőkörnyezetek természetéből adódóan azonban az átmeneti hibák nagyobb valószínűséggel fordulnak elő. Ennek több oka is van:

  • A felhőkörnyezetben számos erőforrás meg van osztva, és az erőforrások védelme érdekében az erőforrásokhoz való hozzáférés szabályozás alá esik. Egyes szolgáltatások megtagadják a kapcsolatokat, amikor a terhelés egy adott szintre emelkedik, vagy amikor eléri a maximális átviteli sebességet, hogy lehetővé tegye a meglévő kérések feldolgozását, és fenntartsa a szolgáltatás teljesítményét az összes felhasználó számára. A korlátozás segít fenntartani a szolgáltatás minőségét a megosztott erőforrást használó szomszédok és más bérlők számára.

  • A felhőkörnyezetek nagy mennyiségű kommoditizált hardveregységet használnak. A teljesítményt úgy biztosítják, hogy dinamikusan osztják el a terhelést több számítási egység és infrastruktúra-összetevő között. A hibás egységek automatikus újrahasznosításával vagy cseréjével biztosítják a megbízhatóságot. A dinamikus jelleg miatt időnként átmeneti hibák és ideiglenes csatlakozási hibák léphetnek fel.

  • Az alkalmazás és az általa használt erőforrások és szolgáltatások között gyakran több hardverösszetevő van, például hálózati infrastruktúra, például útválasztók és terheléselosztók. Ez a további infrastruktúra esetenként további csatlakozási késést és átmeneti csatlakozási hibákat is okozhat.

  • Az ügyfél és a kiszolgáló közötti hálózati feltételek változók lehetnek, különösen akkor, ha a kommunikáció keresztezi az internetet. Még a helyszíni helyeken is a nagy forgalom lelassíthatja a kommunikációt, és időszakos csatlakozási hibákat okozhat.

Az átmeneti hibák jelentős hatással lehetnek az alkalmazás észlelt rendelkezésre állására, még akkor is, ha azt minden előrelátható körülmény között alaposan tesztelték. Annak érdekében, hogy a felhőben üzemeltetett alkalmazások megbízhatóan működjenek, gondoskodnia kell arról, hogy a következő kihívásokra válaszolhassanak:

  • Az alkalmazásnak képesnek kell lennie észlelni a hibákat, amikor azok előfordulnak, és meg kell állapítania, hogy a hibák valószínűleg átmenetiek, tartósak vagy terminálhibák-e. A különböző erőforrások valószínűleg különböző válaszokat adnak vissza hiba esetén, és ezek a válaszok a művelet környezetétől függően is változhatnak. Ha például az alkalmazás a tárolóból olvas, a hiba válasza eltérhet a tárolóba való íráskor kapott választól. Számos erőforrás és szolgáltatás jól dokumentált átmeneti meghibásodási szerződéssel rendelkezik. Ha azonban ezek az információk nem érhetők el, nehéz lehet felderíteni a hiba természetét és azt, hogy az valószínűleg átmeneti-e.

  • Az alkalmazásnak képesnek kell lennie a művelet újraindítására, ha úgy ítéli meg, hogy a hiba valószínűleg átmeneti. Azt is nyomon kell követnie, hogy hányszor próbálkozik újra a művelet.

  • Az alkalmazásnak megfelelő stratégiát kell használnia az újrapróbálkozásokhoz. A stratégia határozza meg, hogy az alkalmazás hányszor próbálkozzon újra, mekkora késleltetést ér el az egyes kísérletek között, és milyen műveleteket kell végrehajtania a sikertelen kísérlet után. A kísérletek megfelelő számát és az egyes kísérletek közötti késleltetést gyakran nehéz meghatározni. A stratégia az erőforrás típusától, valamint az erőforrás és az alkalmazás aktuális működési körülményeitől függően változik.

Az alábbi irányelvek segíthetnek az alkalmazások számára megfelelő átmeneti hibakezelési mechanizmusok megtervezésében.

Újrapróbálkozási próbálkozások implementálása

Annak megállapítása, hogy van-e beépített újrapróbálkozási mechanizmus

  • Számos szolgáltatás átmeneti hibakezelési mechanizmust tartalmazó SDK-t vagy ügyfélkódtárat biztosít. Az általa használt újrapróbálkozási szabályzat általában a célszolgáltatás jellegéhez és követelményeihez igazodik. Azt is megteheti, hogy a szolgáltatások REST-felületei olyan információkat adnak vissza, amelyek segíthetnek meghatározni, hogy megfelelő-e az újrapróbálkozás, és mennyi ideig kell várni a következő újrapróbálkozási kísérletig.

  • Ha elérhető, használja a beépített újrapróbálkozási mechanizmust, kivéve, ha olyan konkrét és jól érthető követelményekkel rendelkezik, amelyek megfelelőbbé teszik a másik újrapróbálkozási viselkedést.

Annak megállapítása, hogy a művelet alkalmas-e az újrapróbálkozásra

  • Csak akkor hajtson végre újrapróbálkozási műveleteket, ha a hibák átmenetiek (általában a hiba jellege jelzi), és ha legalább bizonyos valószínűséggel a művelet sikeres lesz az újrapróbálkozáskor. Nincs értelme olyan műveleteket újrapróbálkozni, amelyek érvénytelen műveletet kísérelnek meg, például egy nem létező elem adatbázis-frissítését, vagy egy olyan szolgáltatásra vagy erőforrásra irányuló kérést, amely végzetes hibát szenvedett.

  • Az újrapróbálkozásokat általában csak akkor hajthatja végre, ha meg tudja határozni ennek teljes hatását, és ha a feltételek jól érthetőek és érvényesíthetők. Ellenkező esetben hagyja, hogy a hívó kód implementáljon újrapróbálkozásokat. Ne feledje, hogy az Ön ellenőrzésén kívül eső erőforrások és szolgáltatások által visszaadott hibák idővel változhatnak, és előfordulhat, hogy újra meg kell vizsgálnia az átmeneti hibaészlelési logikát.

  • Szolgáltatások vagy összetevők létrehozásakor érdemes lehet olyan hibakódokat és üzeneteket implementálni, amelyek segítenek az ügyfeleknek eldönteni, hogy újrapróbálkoznak-e a sikertelen műveletek. Jelezze például, hogy az ügyfélnek újra meg kell-e próbálnia a műveletet (esetleg az isTransient érték visszaadásával), és javasoljon megfelelő késleltetést a következő újrapróbálkozási kísérlet előtt. Ha webszolgáltatást hoz létre, fontolja meg a szolgáltatási szerződésekben meghatározott egyéni hibák visszaadását. Annak ellenére, hogy az általános ügyfelek nem tudják elolvasni ezeket a hibákat, hasznosak az egyéni ügyfelek létrehozásakor.

Megfelelő újrapróbálkozások számának és időközének meghatározása

  • Optimalizálja az újrapróbálkozások számát és az időközt a használati eset típusához. Ha nem próbálkozik újra elég alkalommal, az alkalmazás nem tudja befejezni a műveletet, és valószínűleg sikertelen lesz. Ha túl sokszor próbálkozik újra, vagy túl rövid időközzel próbálkozik a próbálkozások között, előfordulhat, hogy az alkalmazás hosszú ideig olyan erőforrásokat tárol, mint a szálak, a kapcsolatok és a memória, ami hátrányosan befolyásolja az alkalmazás állapotát.

  • Az időintervallum és az újrapróbálkozási kísérletek számának értékeinek igazítása a művelet típusához. Ha például a művelet egy felhasználói interakció része, az időköznek rövidnek kell lennie, és csak néhány újrapróbálkozást kell megkísérelni. Ezzel a módszerrel elkerülheti, hogy a felhasználók megvárják a választ, ami nyitott kapcsolatokat tartogat, és csökkentheti a többi felhasználó rendelkezésre állását. Ha a művelet egy hosszú ideig futó vagy kritikus munkafolyamat része, ahol a folyamat megszakítása és újraindítása költséges vagy időigényes, érdemes hosszabb időt várni a kísérletek között, és újra próbálkozni.

  • Ne feledje, hogy az újrapróbálkozások közötti megfelelő időközök meghatározása a sikeres stratégia megtervezésének legnehezebb része. A tipikus stratégiák a következő típusú újrapróbálkozási időközöket használják:

    • Exponenciális visszalépés. Az alkalmazás vár egy rövid ideig az első újrapróbálkozás előtt, majd exponenciálisan növeli az egyes további újrapróbálkozások közötti időt. Előfordulhat például, hogy 3 másodperc, 12 másodperc, 30 másodperc stb. után újrapróbálkozik a művelettel. A stratégia továbbfejlesztése érdekében jitter adható hozzá az exponenciális visszalépéshez. A Jitter véletlenszerű késleltetést vezet be minden újrapróbálkozási kísérlethez, ami segít megakadályozni, hogy több ügyfél egyszerre próbálkozzon újra, és a terhelés megugrását okozza

    • Növekményes intervallumok. Az alkalmazás rövid ideig várakozik az első újrapróbálkozás előtt, majd növekményesen növeli az egyes újrapróbálkozások közötti időt. Előfordulhat például, hogy újrapróbálkozza a műveletet 3 másodperc, 7 másodperc, 13 másodperc stb. után.

    • Rendszeres időközönként. Az alkalmazás ugyanannyi ideig vár az egyes kísérletek között. Előfordulhat például, hogy 3 másodpercenként újrapróbálkozza a műveletet.

    • Azonnali újrapróbálkozás. Előfordulhat, hogy egy átmeneti hiba rövid életű, amelyet olyan események okozhatnak, mint például egy hálózati csomag ütközése vagy egy hardverkomponensben bekövetkező hirtelen növekedés. Ebben az esetben a művelet azonnali újrapróbálkozása megfelelő lehet, mert akkor lehet sikeres, ha a hiba abban az időben törlődik, amikor az alkalmazás összeáll és elküldi a következő kérést. Azonban soha nem lehet egynél több azonnali újrapróbálkozási kísérlet. Ha az azonnali újrapróbálkozás meghiúsul, váltson alternatív stratégiákra, például exponenciális visszalépési vagy tartalék műveletekre.

    • Véletlenszerűség. A korábban felsorolt újrapróbálkozási stratégiák bármelyike tartalmazhat véletlenszerűsítést, amely megakadályozza, hogy az ügyfél több példánya egyszerre küldjön további újrapróbálkozási kísérleteket. Előfordulhat például, hogy egy példány 3 másodperc, 11 másodperc, 28 másodperc stb. után újrapróbálkozza a műveletet, míg egy másik példány 4 másodperc, 12 másodperc, 26 másodperc stb. után újrapróbálkozza a műveletet. A véletlenszerűség hasznos technika, amely más stratégiákkal kombinálható.

  • Általános útmutatásként a háttérműveleteknél használjon exponenciális visszalépést jitterrel kombinálva, és alkalmazzon azonnali vagy rendszeres időközönkénti újrapróbálkozási stratégiákat az interaktív műveletekhez. Mindkét esetben válassza ki a késleltetést és az újrapróbálkozások számát, hogy az összes újrapróbálkozási kísérlet maximális késése a szükséges végpontok közötti késési követelményen belül legyen.

  • Vegye figyelembe azoknak az összes tényezőnek a kombinációját, amelyek hozzájárulnak az újrapróbálkozás teljes maximális időtúllépéséhez. Ezek a tényezők magukban foglalják a sikertelen kapcsolat válasz előállításához szükséges idejét (amit általában a kliens időtúllépési értéke határoz meg), az újrapróbálkozási kísérletek közötti késést és az újrapróbálkozások maximális számát. Ezen idők összege hosszú általános működési időt eredményezhet, különösen akkor, ha exponenciális késleltetési stratégiát használ, ahol az újrapróbálkozások közötti időköz gyorsan növekszik az egyes hibák után. Ha egy folyamatnak meg kell felelnie egy adott szolgáltatói szerződésnek (SLA), a teljes működési időnek, beleértve az összes időtúllépést és késést, az SLA-ban meghatározott korlátokon belül kell lennie.

  • Ne valósítson végre túl agresszív újrapróbálkozási stratégiákat. Ezek olyan stratégiák, amelyek túl rövid időközökkel vagy túl gyakori újrapróbálkozásokkal rendelkeznek. Káros hatással lehetnek a célerőforrásra vagy szolgáltatásra. Ezek a stratégiák megakadályozhatják, hogy az erőforrás vagy szolgáltatás helyreálljon a túlterhelt állapotából, és továbbra is blokkolja vagy elutasítja a kéréseket. Ez a forgatókönyv ördögi kört eredményez, ahol egyre több kérést küld az erőforrásnak vagy szolgáltatásnak. Következésképpen a gyógyulási képessége tovább csökken.

  • Az újrapróbálkozási időközök kiválasztásakor vegye figyelembe a műveletek időtúllépését, hogy elkerülje a későbbi kísérlet azonnali indítását (például ha az időtúllépési időszak az újrapróbálkozási időközhöz hasonló). Fontolja meg azt is, hogy a teljes lehetséges időtartamot (az időtúllépés és az újrapróbálkozási időközök összegét) egy meghatározott teljes idő alatt kell-e tartani. Ha egy művelet szokatlanul rövid vagy hosszú időtúllépéssel rendelkezik, az időtúllépés befolyásolhatja, hogy mennyi ideig kell várni, és hogy milyen gyakran próbálkozzon újra a művelettel.

  • A kivétel típusát és a benne lévő adatokat, illetve a szolgáltatásból visszaadott hibakódokat és üzeneteket használva optimalizálhatja az újrapróbálkozések számát és a köztük lévő intervallumot. Egyes kivételek vagy hibakódok (például az 503-as HTTP-kód, a szolgáltatás nem érhető el, a válaszban egy Retry-After fejléc) jelezhetik, hogy mennyi ideig tarthat a hiba, vagy hogy a szolgáltatás meghiúsult, és nem válaszol a későbbi kísérletekre.

  • Fontolja meg a halott betű üzenetsor megközelítés alkalmazását annak biztosítására, hogy a bejövő hívás összes információja ne vesszen el az újrapróbálkozási kísérletek kimerítése után.

Kerülje a kizárási mintákat

  • A legtöbb esetben kerülje az olyan implementációkat, amelyek duplikált újrapróbálkozási kódrétegeket tartalmaznak. Kerülje az olyan terveket, amelyek kaszkádolt újrapróbálkozási mechanizmusokat tartalmaznak, vagy amelyek újrapróbálkozást hajtanak végre egy olyan művelet minden szakaszában, amely a kérések hierarchiáját foglalja magában, kivéve, ha vannak olyan konkrét követelmények, amelyek ezt megkövetelik. Ilyen kivételes körülmények között használjon olyan szabályzatokat, amelyek megakadályozzák a túl sok újrapróbálkozást és késleltetési időszakot, és győződjön meg arról, hogy tisztában van a következményekkel. Tegyük fel például, hogy az egyik összetevő kérést küld egy másiknak, amely ezután hozzáfér a célszolgáltatáshoz. Ha mindkét hívásnál háromra számolva valósítja meg az újrapróbálkozást, összesen kilenc újrapróbálkozási kísérlet történik a szolgáltatáson. Számos szolgáltatás és erőforrás beépített újrapróbálkozási mechanizmust valósít meg. Meg kell vizsgálnia, hogyan tilthatja le vagy módosíthatja ezeket a mechanizmusokat, ha magasabb szinten kell megvalósítania az újrapróbálkozásokat.

  • Soha ne valósítson meg végtelen újrapróbálkozási mechanizmust. Ez valószínűleg megakadályozza, hogy az erőforrás vagy szolgáltatás helyreálljon a túlterhelési helyzetekből, és a szabályozás és a megtagadott kapcsolatok hosszabb ideig folytatódjanak. Használjon véges számú újrapróbálkozási lehetőséget, vagy implementáljon egy olyan mintát, mint az Áramkör Megszakító, hogy a szolgáltatás helyreálljon.

  • Soha ne hajtson végre egynél többször azonnali újrapróbálkozást.

  • Ne használjon rendszeres újrapróbálkozási időközt, amikor az Azure-beli szolgáltatásokhoz és erőforrásokhoz fér hozzá, különösen akkor, ha nagy számú újrapróbálkozási kísérlete van. Ebben a forgatókönyvben a legjobb módszer egy exponenciális visszalépési stratégia, amely áramkör-megszakító képességgel rendelkezik.

  • Megakadályozza, hogy ugyanazon ügyfél több példánya vagy több különböző ügyfélpéldánya egyszerre küldjön újrapróbálkozási elemet. Ha ez a forgatókönyv valószínűleg bekövetkezik, vezessen be véletlenszerűsítést az újrapróbálkozási időközökbe.

Újrapróbálkozási stratégiák és megvalósítás tesztelése

  • Az újrapróbálkozási stratégiát a lehető legszélesebb körben tesztelheti, különösen akkor, ha az alkalmazás és az általa használt célerőforrások vagy -szolgáltatások is extrém terhelés alatt vannak. A tesztelés során a viselkedés ellenőrzéséhez a következőket teheti:

    • Az átmeneti hibákat belefoglalhatja a káosztervezésbe és a hibainjektálási eljárásokba azáltal, hogy szándékosan bevezeti őket a nem termelési és éles környezetekbe. Például érvénytelen kéréseket küldhet, vagy hozzáadhat olyan kódot, amely észleli a tesztkéréseket, és különböző típusú hibákkal válaszol.

    • Hozzon létre egy mintapéldányt az erőforrásról vagy szolgáltatásról, amely a valós szolgáltatás által visszaadott hibák tartományát adja vissza. Fedje le az újrapróbálkozási stratégia által észlelt összes hibatípust.

    • A létrehozott és üzembe helyezett egyéni szolgáltatások esetében a szolgáltatás ideiglenes letiltásával vagy túlterhelésével kényszerítheti az átmeneti hibákat. (Ne próbálja meg túlterhelni a megosztott erőforrásokat vagy megosztott szolgáltatásokat az Azure-ban.)

    • Használjon olyan kódtárakat vagy megoldásokat, amelyek elfogják és módosítják a hálózati forgalmat, hogy kedvezőtlen forgatókönyveket replikáljanak az automatizált tesztekből. A tesztek például további visszautazási időket adhatnak hozzá, csomagokat dobhatnak el, fejléceket módosíthatnak, vagy akár magát a kérés tartalmát is módosíthatják. Ez lehetővé teszi a hibafeltételek egy részhalmazának determinisztikus tesztelését az átmeneti hibák és más típusú hibák esetében.

    • Amikor egy ügyfél-webalkalmazás átmeneti hibákkal szembeni rugalmasságát teszteli, használja a böngésző fejlesztői eszközeit vagy a tesztelési keretrendszer hálózati kérések utánzására vagy blokkolására való képességét . ...

    • Nagy terhelési tényezőt és egyidejű teszteket hajthat végre annak biztosítása érdekében, hogy az újrapróbálkozási mechanizmus és a stratégia megfelelően működjön ezekben a feltételekben. Ezek a tesztek azt is biztosítják, hogy az újrapróbálkozás ne legyen káros hatással az ügyfél működésére, és ne okozzon keresztszennyeződést a kérések között.

Újrapróbálkozási szabályzatkonfigurációk kezelése

  • Az újrapróbálkozási szabályzat az újrapróbálkozási stratégia összes elemének kombinációja. Meghatározza az észlelési mechanizmust, amely meghatározza, hogy egy hiba valószínűleg átmeneti-e, a használandó időköz típusa (például rendszeres, exponenciális visszakapcsolás és véletlenszerűség), a tényleges intervallumértékek és az újrapróbálkozások száma.

  • Az újrapróbálkozások megvalósítása sok helyen, még a legegyszerűbb alkalmazásban is, és az összetettebb alkalmazások minden rétegében. Ahelyett, hogy az egyes szabályzatok elemeit több helyen is keményen kódolták, fontolja meg egy központi pont használatát az összes szabályzat tárolásához. Tárolja például az olyan értékeket, mint az intervallum és az újrapróbálkozások száma az alkalmazáskonfigurációs fájlokban, olvassa el őket futásidőben, és programozott módon hozza létre az újrapróbálkozási szabályzatokat. Ezzel egyszerűbbé válik a beállítások kezelése, valamint az értékek módosítása és finomhangolása a változó követelményeknek és forgatókönyveknek megfelelően. Azonban úgy tervezheti meg a rendszert, hogy tárolja az értékeket ahelyett, hogy minden alkalommal újraolvasná a konfigurációs fájlt, és megfelelő alapértelmezett értékeket használjon, ha az értékek nem kérhetők le a konfigurációból.

  • Tárolja azokat az értékeket, amelyek az újrapróbálkozási szabályzatok futásidőben történő létrehozásához használatosak az alkalmazás konfigurációs rendszerében, így anélkül módosíthatja őket, hogy újra kellene indítania az alkalmazást.

  • Használja ki az ön által használt ügyfél API-kban elérhető beépített vagy alapértelmezett újrapróbálkozési stratégiákat, de csak akkor, ha azok megfelelnek az Ön forgatókönyvének. Ezek a stratégiák jellemzően általánosak. Bizonyos esetekben előfordulhat, hogy csak ezekre van szüksége, de más esetekben nem kínálják az Ön igényeinek megfelelő lehetőségek teljes skáláját. A legmegfelelőbb értékek meghatározásához tesztelést kell végeznie, hogy megértse, hogyan befolyásolják a beállítások az alkalmazást.

Átmeneti és nem átmeneti hibák naplózása és nyomon követése

  • Az újrapróbálkozási stratégia részeként tartalmazza a kivételkezelést és az újrapróbálkozási kísérleteket naplózó egyéb rendszerállapotokat. Időnként átmeneti hiba és újrapróbálkozás várható, és nem jelez problémát. A rendszeres és növekvő számú újrapróbálkozás azonban gyakran olyan problémát jelez, amely hibát okozhat, vagy rontja az alkalmazás teljesítményét és rendelkezésre állását.

  • Az átmeneti hibákat figyelmeztető bejegyzésekként, nem pedig hibabejegyzésekként naplózza, hogy a figyelési rendszerek ne észleljék őket olyan alkalmazáshibákként, amelyek téves riasztásokat válthatnak ki.

  • Fontolja meg egy olyan érték tárolását a naplóbejegyzésekben, amely jelzi, hogy az újrapróbálkozásokat a szolgáltatás szabályozása vagy más típusú hibák, például kapcsolati hibák okozzák-e, hogy az adatok elemzése során meg tudja különböztetni őket. A szabályozási hibák számának növekedése gyakran jelzi az alkalmazás tervezési hibáját, vagy azt, hogy egy dedikált hardvert kínáló prémium szolgáltatásra kell váltani.

  • Fontolja meg az újrapróbálkozási mechanizmust tartalmazó műveletek összesített eltelt idejének mérését és naplózását. Ez a metrika jól jelzi az átmeneti hibáknak a felhasználói válaszidőkre, a folyamat késésére és az alkalmazáshasználati esetek hatékonyságára gyakorolt általános hatását. Naplózza az újrapróbálkozások számát is, hogy megértse a válaszidőhöz hozzájáruló tényezőket.

  • Fontolja meg egy olyan telemetriai és monitorozási rendszer megvalósítását, amely riasztásokat küldhet, ha a hibák száma és aránya, az újrapróbálkozások átlagos száma vagy a műveletek sikeressége előtt eltelt idő növekszik.

Folyamatosan sikertelen műveletek kezelése

  • Gondolja át, hogyan kezelheti azokat a műveleteket, amelyek minden kísérletnél továbbra is sikertelenek. Az ilyen helyzetek elkerülhetetlenek.

    • Bár az újrapróbálkozási stratégia meghatározza a művelet újrapróbálkozásának maximális számát, nem akadályozza meg, hogy az alkalmazás ugyanazzal a számú újrapróbálkozással ismételje meg a műveletet. Ha például egy rendelésfeldolgozó szolgáltatás végzetes hibával meghiúsul, ami miatt véglegesen működésképtelenné válik, az újrapróbálkozási stratégia észlelheti ezt az állapotot úgy, hogy a kapcsolat időtúllépését átmeneti hibaként kezeli. A kód egy megadott számú alkalommal újrapróbálkozza a műveletet, majd feladja. Amikor azonban egy másik ügyfél lead egy megrendelést, a rendszer újra megpróbálja végrehajtani a műveletet, annak ellenére, hogy minden alkalommal sikertelen lesz.

    • A folyamatosan sikertelen műveletek folyamatos újrapróbálkozásának megakadályozása érdekében fontolja meg az áramkör-megszakító minta implementálását. Ha ezt a mintát használja, ha egy megadott időkereten belül a hibák száma meghaladja a küszöbértéket, a kérések hibaként azonnal visszatérnek a hívóhoz, és nem kísérlik meg elérni a sikertelen erőforrást vagy szolgáltatást.

    • Az alkalmazás rendszeres időközönként és a kérések közötti hosszú időközönként tesztelheti a szolgáltatást, hogy észlelje, mikor válik elérhetővé. A megfelelő időköz olyan tényezőktől függ, mint a művelet kritikussága és a szolgáltatás jellege. Néhány perc és több óra között bármi lehet. Ha a teszt sikeres, az alkalmazás folytathatja a normál működést, és átadhatja a kéréseket az újonnan helyreállított szolgáltatásnak.

    • Addig is előfordulhat, hogy vissza tud esni a szolgáltatás egy másik példányára (esetleg egy másik adatközpontban vagy alkalmazásban), használhat egy hasonló szolgáltatást, amely kompatibilis (talán egyszerűbb) funkciókat kínál, vagy alternatív műveleteket hajthat végre annak reménye alapján, hogy a szolgáltatás hamarosan elérhető lesz. Célszerű lehet például a szolgáltatásra vonatkozó kéréseket egy üzenetsorban vagy adattárban tárolni, majd később újrapróbálkozni. Vagy átirányíthatja a felhasználót az alkalmazás egy másik példányára, csökkentheti az alkalmazás teljesítményét, de továbbra is elfogadható funkciókat kínálhat, vagy egyszerűen elküldhet egy üzenetet a felhasználónak, amely jelzi, hogy az alkalmazás jelenleg nem érhető el.

Újrapróbálkozási implementáció optimalizálása

  • Amikor egy szabályzat újrapróbálkozási időközének és újrapróbálkozási időközének értékeiről dönt, fontolja meg, hogy a szolgáltatáson vagy erőforráson végzett művelet egy hosszú ideig futó vagy többlépéses művelet része-e. Előfordulhat, hogy nehéz vagy költséges kompenzálni az összes többi olyan működési lépést, amely már sikeres volt, ha az egyik sikertelen. Ebben az esetben egy nagyon hosszú intervallum és sok újrapróbálkozás elfogadható lehet, ha ez a stratégia nem blokkolja a többi műveletet a szűkös erőforrások tartásával vagy zárolásával.

  • Fontolja meg, hogy ugyanazon művelet újrapróbálkozása inkonzisztenciát okozhat-e az adatokban. Ha egy többlépéses folyamat egyes részei ismétlődnek, és a műveletek nem idempotensek, inkonzisztenciák léphetnek fel. Ha például egy értéket növekményes művelet ismétlődik, érvénytelen eredményt eredményez. Ha egy üzenetsorba üzenetet küldő művelet megismétlése inkonzisztencia-problémát okozhat az üzenet fogyasztójában, ha a fogyasztó nem észleli az ismétlődő üzeneteket. A forgatókönyvek elkerülése érdekében minden lépést idempotens műveletként tervezzen meg. További információ: Idempotencia-minták.

  • Vegye figyelembe az újrapróbálkozott műveletek hatókörét. Egyszerűbb lehet például az újrapróbálkozási kódot olyan szinten megvalósítani, amely több műveletet is magában foglal, és ha az egyik sikertelen, újra próbálkozni. Ez azonban idempotenciával kapcsolatos problémákat vagy szükségtelen visszaállítási műveleteket eredményezhet.

  • Ha olyan újrapróbálkozási hatókört választ, amely több műveletet is magában foglal, vegye figyelembe az összes művelet összesített késleltetését az újrapróbálkozási időközök meghatározásakor, a műveletek eltelt idejének monitorozásakor, és mielőtt riasztásokat hozna létre a hibák miatt.

  • Gondolja át, hogyan befolyásolhatja az újrapróbálkozás stratégiája a megosztott alkalmazás szomszédait és más bérlőit, valamint a megosztott erőforrások és szolgáltatások használatát. Az agresszív újrapróbálkozási szabályzatok egyre több átmeneti hibát okozhatnak ezeknél a többi felhasználónál, valamint az erőforrásokat és szolgáltatásokat megosztó alkalmazásoknál. Hasonlóképpen az alkalmazásra is hatással lehetnek az erőforrások és szolgáltatások más felhasználói által implementált újrapróbálkoztatási szabályzatok. Üzleti szempontból kritikus fontosságú alkalmazások esetén érdemes lehet olyan prémium szintű szolgáltatásokat használni, amelyek nincsenek megosztva. Az erőforrások és szolgáltatások terhelésének és korlátozásának jobb szabályozásával jobban igazolható a többletköltség.

Megjegyzés:

A kompromisszumokkal és kockázatokkal kapcsolatos további útmutatásért tekintse meg az Újrapróbálkozási minta cikk problémáit és szempontjait.

Az Azure megkönnyítése

A legtöbb Azure-szolgáltatás és ügyféloldali SDK újrapróbálkozási mechanizmust biztosít. Ezek a mechanizmusok azonban eltérnek, mivel minden szolgáltatás különböző jellemzőkkel és követelményekkel rendelkezik, és minden újrapróbálkozási mechanizmus az adott szolgáltatásra van hangolva. Ez a szakasz néhány gyakran használt Azure-szolgáltatás újrapróbálkozési mechanizmusának funkcióit foglalja össze.

Service Újrapróbálkozások képességei Szabályzatkonfiguráció Scope Telemetriai funkciók
Microsoft Entra-azonosító Natív a Microsoft Authentication Libraryben (MSAL) Beágyazás az MSAL-kódtárba Belső None
Azure Cosmos DB Natív a szolgáltatásban Nem konfigurálható Global TraceSource
Azure Data Lake Storage Natív a kliensben Nem konfigurálható Egyedi műveletek None
Azure-eseményközpontok Natív a kliensben Programmatic Ügyfél None
Azure IoT Hub Natív az ügyféloldali SDK-ban Programmatic Ügyfél None
Azure Cognitive Search Natív a kliensben Programmatic Ügyfél ETW vagy egyéni
Azure Service Bus Natív a kliensben Programmatic NamespaceManager, MessagingFactory és ügyfél ETW
Azure Service Fabric Natív a kliensben Programmatic Ügyfél None
Azure SQL Database with ADO.NET Polly Deklaratív és programozott Önálló utasítások vagy kódblokkok Személyre szabott
SQL Database az Entity Framework használatával Natív a kliensben Programmatic Globális alkalmazástartományonként None
SQL-adatbázis Entity Framework Core-ral Natív a kliensben Programmatic Globális alkalmazástartományonként None
Azure Storage Natív a kliensben Programmatic Ügyfél- és egyéni műveletek TraceSource

Megjegyzés:

Az Azure beépített újrapróbálkozásának legtöbb mechanizmusa esetében jelenleg nem lehet eltérő újrapróbálkozési szabályzatot alkalmazni a különböző típusú hibákra vagy kivételekre. Olyan szabályzatot kell konfigurálnia, amely az optimális átlagos teljesítményt és rendelkezésre állást biztosítja. A szabályzat finomhangolásának egyik módja a naplófájlok elemzése az átmeneti hibák típusának meghatározásához.

Example

Tekintse meg a .NET megbízható webalkalmazás-mintáját , amely a cikkben ismertetett számos mintát használja. A GitHubon referencia-implementáció is található.

Megbízhatósági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Megbízhatósági ellenőrzőlista

  • Last updated on