Javaslatok átmeneti hibák kezelésére

  • Cikk

Erre az Azure Well-Architected Framework megbízhatósági ellenőrzőlistára vonatkozó javaslatra vonatkozik:

RE:07 Önmegőrző és önjavító intézkedések végrehajtásával erősítheti a számítási feladatok rugalmasságát és helyreállíthatóságát. Képességeket építhet be a megoldásba infrastruktúra-alapú megbízhatósági minták és szoftveralapú tervezési minták használatával az összetevők hibáinak és átmeneti hibáinak kezeléséhez. Képességeket építhet be a rendszerbe a megoldás-összetevők hibáinak észleléséhez, és automatikusan korrekciós műveletet kezdeményezhet, miközben a számítási feladat továbbra is teljes vagy csökkentett funkcionalitással működik.

Kapcsolódó útmutatók:Háttérfeladatok | Önmegőrzés

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ó alkalmazásoknak érzékenynek kell lenniük az átmeneti hibákra. Ez különösen igaz a felhőben futó alkalmazásokra, ahol a környezet természete és az interneten keresztüli kapcsolat miatt ez a hiba valószínűleg gyakrabban jelentkezik. Az átmeneti hibák közé tartozik az összetevőkhöz és szolgáltatásokhoz való hálózati kapcsolat pillanatnyi megszakadása, a szolgáltatás ideiglenes elérhetetlensége, valamint a szolgáltatás foglaltsága esetén előforduló időtúllépések. Ezek a hibák gyakran önjavítóak, így ha a művelet megfelelő késleltetés után ismétlődik, akkor valószínűleg sikeres lesz.

Ez a cikk általános útmutatást nyújt az átmeneti hibakezeléshez. Az átmeneti hibák kezelésével kapcsolatos információkért tekintse meg az újrapróbálkozási mintát , és az Azure-szolgáltatások használatakor tekintse meg az Azure-szolgáltatások újrapróbálkozási útmutatóját.

Fő tervezési stratégiák

Az átmeneti hibák bármilyen környezet, platform vagy operációs rendszer esetén, illetve bármilyen típusú 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 történik, az összetevők és erőforrások pedig egymás közelében találhatók. Ez a megközelítés kisebb valószínűséggel okoz meghibásodást, de átmeneti hibák továbbra is előfordulhatnak, ahogy a váratlan események, például 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 révén számos árualapú 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 szabályozni kell az erőforrásokhoz való hozzáférést. Egyes szolgáltatások elutasítják a kapcsolatokat, amikor a terhelés egy adott szintre emelkedik, vagy amikor eléri a maximális átviteli sebességet, a meglévő kérések feldolgozásának engedélyezése és a szolgáltatás teljesítményének fenntartása érdekében az összes felhasználó számára. A szabályozá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 nagyszámú árucikk-hardveregységet használnak. A teljesítményt a terhelés több számítási egység és infrastruktúra-összetevő közötti dinamikus elosztásával biztosítják. A sikertelen egységek automatikus újrahasznosításával vagy cseréjével biztosítják a megbízhatóságot. A dinamikus természet miatt időnként átmeneti hibák és ideiglenes csatlakozási hibák fordulhatnak elő.

  • 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 alkalmanként további kapcsolódási késést és átmeneti kapcsolati hibákat 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ó az interneten keresztül történik. Még a helyszíni helyeken is a nagy forgalmú terhelések lelassíthatják a kommunikációt, és időszakos csatlakozási hibákat okozhatnak.

Problémák

Az átmeneti hibák jelentős hatással lehetnek az alkalmazások vélt rendelkezésre állására, még akkor is, ha minden előre látható körülmények között alaposan tesztelték. Ahhoz, hogy a felhőben üzemeltetett alkalmazások megbízhatóan működjenek, meg kell győződnie arról, hogy képesek reagálni a következő kihívásokra:

  • Az alkalmazásnak képesnek kell lennie észlelni a hibák előfordulását, és meg kell állapítania, hogy a hibák valószínűleg átmenetiek, tartósak vagy terminálhibák. 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 tárolóból olvas, a hiba válasza eltérhet a tárolóba írásakor kapott választól. Számos erőforrás és szolgáltatás rendelkezik jól dokumentált átmeneti meghibásodási szerződéssel. 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 újrapróbálkozására, ha megállapítja, hogy a hiba valószínűleg átmeneti. Azt is nyomon kell követnie, hogy hányszor kísérelték meg újra a műveletet.

  • Az alkalmazásnak megfelelő stratégiát kell használnia az újrapróbálkozáshoz. A stratégia meghatározza, hogy az alkalmazásnak hány alkalommal kell újrapróbálkoznia, az egyes kísérletek közötti késleltetést és a sikertelen kísérletek után végrehajtandó műveleteket. Gyakran nehéz meghatározni a kísérletek megfelelő számát és az egyes próbálkozások közötti késést. A stratégia az erőforrás típusától, valamint az erőforrás és az alkalmazás aktuális üzemeltetési feltételeitől függően változik.

Általános irányelvek

Az alábbi irányelvek segítségével megfelelő átmeneti hibakezelési mechanizmusokat tervezhet az alkalmazásokhoz.

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

  • Számos szolgáltatás biztosít átmeneti hibakezelési mechanizmust tartalmazó SDK-t vagy ügyfélkódtárat. A mechanizmus által használt újrapróbálkozási szabályzat általában a célszolgáltatás természetéhez és követelményeihez igazodik. Alternatív megoldásként a szolgáltatások REST-felületei olyan információkat is visszaadhatnak, amelyek segíthetnek meghatározni, hogy az újrapróbálkozások megfelelőek-e, és mennyi ideig kell várniuk a következő újrapróbálkozási kísérlet előtt.

  • 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 az újrapróbálkozás más viselkedését teszik megfelelőbbé.

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

  • Csak akkor hajtsa végre az újrapróbálkozási műveleteket, ha a hibák átmenetiek (általában a hiba természete jelzi), és ha legalább valószínű, hogy a művelet sikeres lesz az újrapróbálkozáskor. Nincs értelme olyan műveletek újrapróbálkozásának, 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ás vagy erőforrás kérését, amely végzetes hibát szenvedett.

  • Általában csak akkor hajtsa végre az újrapróbálkozásokat, ha meg tudja határozni ennek teljes hatását, és ha a feltételek jól ismertek és érvényesíthetők. Ellenkező esetben hagyja, hogy a híváskód újrapróbálkozásokat implementáljon. Ne feledje, hogy a kontrollon kívüli erőforrásokból és szolgáltatásokból visszaadott hibák idővel változhatnak, és előfordulhat, hogy újra meg kell látogatnia az átmeneti hibaészlelési logikát.

  • Amikor szolgáltatásokat vagy összetevőket hoz létre, érdemes lehet olyan hibakódokat és üzeneteket implementálni, amelyek segítenek az ügyfeleknek meghatározni, hogy újra meg kell-e próbálkozniuk a sikertelen műveletekkel. Különösen azt jelzi, hogy az ügyfélnek újra meg kell-e próbálnia a műveletet (például 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 definiált egyéni hibák visszaadását. Annak ellenére, hogy az általános ügyfelek nem tudják elolvasni ezeket a hibákat, hasznosak lehetnek az egyéni ügyfelek létrehozásakor.

A megfelelő újrapróbálkozási szám és időköz meghatározása

  • Optimalizálja az újrapróbálkozási számot és az időközt a használati eset típusára. Ha nem próbálkozik elég alkalommal, az alkalmazás nem tudja végrehajtani a műveletet, és valószínűleg sikertelen lesz. Ha túl sokszor próbálkozik újra, vagy túl rövid idő telik el a próbálkozások között, előfordulhat, hogy az alkalmazás hosszú ideig tárol erőforrásokat, például szálakat, kapcsolatokat és memóriát, ami hátrányosan befolyásolja az alkalmazás állapotát.

  • Módosítsa az időintervallum értékeit és az újrapróbálkozási kísérletek számát 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ási kísérletre kell törekednie. Ezzel a megközelítéssel 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ó elérhetőségé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 többször újrapróbálkozni.

  • Ne feledje, hogy a sikeres stratégia kialakításának legnehezebb része az újrapróbálkozások közötti megfelelő intervallumok meghatározása. A stratégiák általában az alábbi újrapróbálkozási időköztípusokat használják:

    • Exponenciális visszalépés. Az alkalmazás rövid időt vár 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 újra megkísérli a műveletet 3 másodperc, 12 másodperc, 30 másodperc stb. után.

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

    • Rendszeres időközök. Az alkalmazás ugyanannyi ideig várakozik a próbálkozások 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, amelyet egy olyan esemény okozhat, mint egy hálózati csomag ütközése vagy egy hardverösszetevő kiugrása. Ebben az esetben a művelet azonnali újrapróbálkozása megfelelő lehet, mert akkor lehet sikeres, ha a hiba törlődik abban az időben, amikor az alkalmazásnak össze kell állítania és el kell küldenie a következő kérést. Azonban soha nem lehet több azonnali újrapróbálkozási kísérlet. Ha az azonnali újrapróbálkozás sikertelen, váltson alternatív stratégiákra, például exponenciális visszatartási vagy tartalék műveletekre.

    • Véletlenszerűsítés. 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 újrapróbálkozási kísérleteket. Az egyik példány például 3 másodperc, 11 másodperc, 28 másodperc stb. után próbálkozhat újra a művelettel, míg egy másik példány 4 másodperc, 12 másodperc, 26 másodperc stb. után újrapróbálhatja a műveletet. A véletlenszerűsítés hasznos módszer, amely más stratégiákkal kombinálható.

  • Általános útmutatóként használjon exponenciális háttérstratégiát a háttérműveletekhez, és használjon azonnali vagy rendszeres időközönkénti újrapróbálkozási stratégiákat az interaktív műveletekhez. Mindkét esetben úgy kell kiválasztania a késleltetést és az újrapróbálkozások számát, hogy az újrapróbálkozási kísérletek maximális késleltetése megfeleljen a végpontok közötti késés szükséges követelményeinek.

  • Vegye figyelembe az összes olyan tényező kombinációját, amely hozzájárul egy újrapróbálkozási művelet teljes maximális időtúllépéséhez. Ezek közé a tényezők közé tartozik a sikertelen kapcsolat válaszhoz való előállításához szükséges idő (általában az ügyfél időtúllépési értéke), az újrapróbálkozási kísérletek közötti késleltetés és az újrapróbálkozások maximális száma. Az összes ilyen idő összesen hosszú általános műveleti 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 az egyes hibák után gyorsan nő. Ha egy folyamatnak meg kell felelnie egy adott szolgáltatásiszint-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 is, az SLA-ban meghatározott korlátokon belül kell lennie.

  • Ne alkalmazzon túlzottan agresszív újrapróbálkozési stratégiákat. Ezek olyan stratégiák, amelyek időközei túl rövidek, vagy túl gyakori újrapróbálkozások. Ezek kedvezőtlen 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 a 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 egy ördögi kört eredményez, ahol a rendszer egyre több kérést küld az erőforrásnak vagy szolgáltatásnak. Következésképpen a helyreállítás 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érletek azonnali indítását (például ha az időtúllépési időszak hasonló az újrapróbálkozási időközhöz). Azt is vegye figyelembe, hogy a teljes lehetséges időtartamot (az időtúllépést és az újrapróbálkozási időközöket) egy adott teljes idő alatt kell-e tartania. 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árnia, és milyen gyakran kell újrapróbálkoznia a művelettel.

  • Az újrapróbálkozások számának és a közöttük lévő időköznek a optimalizálásához használja a kivétel típusát és a benne található adatokat, illetve a szolgáltatástól kapott hibakódokat és üzeneteket. Egyes kivételek vagy hibakódok (például az 503-at tartalmazó HTTP-kód, a Szolgáltatás nem érhető el, a válaszban egy Retry-After fejléccel) jelezhetik, hogy mennyi ideig tarthat a hiba, vagy hogy a szolgáltatás sikertelen volt, és nem fog válaszolni az ezt követő kísérletekre.

  • Érdemes lehet kézbesítetlen üzenetsor-megközelítést használni annak érdekében, hogy a bejövő hívás összes információja ne vesszenek el az újrapróbálkozási kísérletek kimerítése után.

Kerülje az antimintákat

  • A legtöbb esetben kerülje az újrapróbálkozási kód duplikált rétegeit tartalmazó implementációkat. Kerülje azokat a 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, hacsak nem rendelkezik az ehhez szükséges konkrét követelményekkel. Ezekben a kivételes esetekben használjon olyan szabályzatokat, amelyek megakadályozzák a túl sok újrapróbálkozást és a túl nagy késleltetési időközöket, és győződjön meg róla, 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 az újrapróbálkozást mindkét hívásnál három darabszámmal valósítja meg, összesen kilenc újrapróbálkozási kísérlet történik a szolgáltatással szemben. Számos szolgáltatás és erőforrás implementál egy beépített újrapróbálkozési mechanizmust. Meg kell vizsgálnia, hogyan tilthatja le vagy módosíthatja ezeket a mechanizmusokat, ha magasabb szintű újrapróbálkozásokra van szüksége.

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

  • Soha ne végezzen azonnali újrapróbálkozást egynél több alkalommal.

  • Kerülje a 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 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ány egyidejűleg küldjön újrapróbálkozásokat. 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.

Az újrapróbálkozási stratégia és az implementáció tesztelése

  • Az újrapróbálkozás stratégiáját a lehető legszélesebb körben tesztelje, különösen akkor, ha az alkalmazás és az általa használt célerőforrások vagy szolgáltatások is rendkívül nagy terhelés alatt vannak. A következőképpen ellenőrizheti a viselkedést a tesztelés közben:

    • Átmeneti és nem átmeneti hibákat szúr be a szolgáltatásba. Például küldjön érvénytelen kéréseket, vagy adjon hozzá egy kódot, amely észleli a tesztelési kéréseket, és különböző típusú hibákat ad vissza válaszként.

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

    • A létrehozott és üzembe helyezendő egyéni szolgáltatások esetében kényszerítse az átmeneti hibák előfordulását a szolgáltatás ideiglenes letiltásával vagy túlterhelésével. (Ne kíséreljen meg túlterhelni 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 kerekítési időt adhatnak hozzá, csomagokat vethetnek el, fejléceket módosíthatnak, vagy akár maguk a kérés törzsét is módosíthatják. Ez lehetővé teszi a hibaállapotok egy részhalmazának determinisztikus tesztelését átmeneti hibák és más típusú hibák esetén.

    • Amikor egy ügyfél webalkalmazás átmeneti hibákra való 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 szimulálására vagy letiltására vonatkozó képességét.

    • Végezzen nagy terhelési tényezőt és egyidejű teszteket annak é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 kedvezőtlen hatással az ügyfél működésére, és ne okozzon keresztszennyezettséget a kérések között.

Újrapróbálkozások szabályzatkonfigurációinak 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 visszatartás és véletlenszerűsítés), a tényleges időközé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 rögzítetten kódolták, fontolja meg egy központi pont használatát az összes szabályzat tárolásához. Tárolhatja például az értékeket, például az időközt és az újrapróbálkozások számát az alkalmazáskonfigurációs fájlokban, elolvashatja őket futásidőben, és programozott módon létrehozhatja az újrapróbálkozási szabályzatokat. Ez megkönnyíti a beállítások kezelését, valamint az értékek módosítását és finomhangolását a változó követelményeknek és forgatókönyveknek megfelelően. Azonban úgy tervezheti meg a rendszert, hogy tárolja az értékeket a konfigurációs fájl minden egyes újraolvasása helyett, és használjon megfelelő alapértelmezett értékeket, ha az értékek nem kérhetők le a konfigurációból.

  • Tárolja az újrapróbálkozási szabályzatok futásidőben történő létrehozásához használt értékeket 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 általában általánosak. Egyes forgatókönyvekben ezekre lehet csak szüksége, más forgatókönyvekben azonban nem kínálják az adott követelményeknek megfelelő lehetőségek teljes körét. A legmegfelelőbb értékek meghatározásához tesztelést kell végeznie annak megértéséhez, hogy a beállítások hogyan befolyásolják 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 tartalmazzon kivételkezelést és más olyan kialakítást, amely naplózza az újrapróbálkozási kísérleteket. Időnként átmeneti hiba és újrapróbálkozás várható, és nem jelez problémát. A rendszeres és egyre növekvő számú újrapróbálkozás azonban gyakran olyan probléma jele, amely hibát okozhat, vagy rontja az alkalmazás teljesítményét és rendelkezésre állását.

  • Az átmeneti hibákat ne hibabejegyzésként, hanem figyelmeztető bejegyzéské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.

  • Érdemes lehet olyan értéket a naplóbejegyzésekben tárolni, amely jelzi, hogy az újrapróbálkozások a szolgáltatásban való szabályozás vagy más típusú hibák, például csatlakozási hibák miatt vannak-e, így megkülönböztetheti őket az adatok elemzése során. A szabályozási hibák számának növekedése gyakran egy tervezési hibát jelez az alkalmazásban, vagy azt, hogy át kell váltani egy dedikált hardvereket kínáló prémium szolgáltatásra.

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

  • Érdemes lehet olyan telemetriai és monitorozási rendszert implementálni, amely riasztásokat hozhat létre, 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 teljes idő növekszik.

Folyamatosan sikertelen műveletek kezelése

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

    • Bár az újrapróbálkozási stratégia meghatározza, hogy egy műveletet legfeljebb hányszor kell újrapróbálkozni, nem akadályozza meg, hogy az alkalmazás ugyanazzal a számú újrapróbálkozással ismételje meg újra a műveletet. Ha például egy rendelésfeldolgozó szolgáltatás végzetes hibával meghiúsul, amely véglegesen leáll, az újrapróbálkozási stratégia észlelheti a kapcsolat időtúllépését, és átmeneti hibának tekintheti. A kód megadott számú alkalommal újrapróbálkozott a művelettel, majd feladja a műveletet. Amikor azonban egy másik ügyfél lead egy rendelést, a rendszer újra megkísérli 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 azonnal hibaként térnek vissza a hívóhoz, és nem kísérel meg hozzáférni a sikertelen erőforráshoz vagy szolgáltatáshoz.

    • Az alkalmazás időszakosan és a kérések közötti hosszú időközökkel rendszeres időközönként tesztelheti a szolgáltatást annak észleléséhez, hogy 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 lehet bármi. Ha a teszt sikeres, az alkalmazás folytathatja a normál műveleteket, és továbbíthatja a kéréseket az újonnan helyreállított szolgáltatásnak.

    • Addig is előfordulhat, hogy vissza tud állni 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. Előfordulhat például, hogy a szolgáltatásra vonatkozó kéréseket egy üzenetsorban vagy adattárban kell tárolni, majd később újrapróbálkozhat velük. 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 vissza tud küldeni egy üzenetet a felhasználónak, amely jelzi, hogy az alkalmazás jelenleg nem érhető el.

További szempontok

  • Amikor az újrapróbálkozások számának és egy szabályzat újrapróbálkozási időközeinek értékeiről dönt, fontolja meg, hogy a szolgáltatáson vagy erőforráson futó művelet egy hosszú ideig futó vagy többlépéses művelet része-e. Nehéz vagy költséges lehet kompenzálni az összes olyan működési lépést, amely már sikeres volt, ha az egyik sikertelen volt. Ebben az esetben egy nagyon hosszú időköz é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.

  • Gondolja át, hogy ugyanannak a műveletnek az újrapróbálása inkonzisztenciákat 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 ad. Ha egy üzenetsorba üzenetet küldő művelet megismétlése inkonzisztenciá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 tervezze meg az egyes lépéseket idempotens műveletként. 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 olyan szinten implementálni az újrapróbálkozási kódot, amely több műveletet is magában foglal, és újrapróbálkozhat velük, ha az egyik meghibásodik. Ez azonban idempotenciaproblé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 teljes késését az újrapróbálkozási időközök meghatározásakor, a művelet eltelt idejének monitorozása és a hibákra vonatkozó riasztások létrehozása előtt.

  • Gondolja át, hogy az újrapróbálkozás stratégiája milyen hatással lehet a szomszédokra és más bérlőkre egy megosztott alkalmazásban, illetve amikor megosztott erőforrásokat és szolgáltatásokat használ. Az agresszív újrapróbálkozási szabályzatok egyre több átmeneti hibát okozhatnak a többi felhasználónál, és az olyan alkalmazásokban, amelyek közösen használják ezeket az erőforrásokat és szolgáltatásokat. Hasonlóképpen, az alkalmazásra hatással lehetnek az erőforrások és szolgáltatások más felhasználói által implementált újrapróbálkozési szabályzatok. Üzleti szempontból kritikus fontosságú alkalmazások esetén érdemes lehet olyan prémium szolgáltatásokat használni, amelyek nincsenek megosztva. Ezzel jobban szabályozhatja ezeknek az erőforrásoknak és szolgáltatásoknak a terhelését és ennek következtében történő szabályozását, ami segíthet igazolni a többletköltségeket.

Megjegyzés

A kompromisszumokkal és kockázatokkal kapcsolatos további útmutatásért tekintse meg az Újrapróbálkozási minta cikkben található problémákat és szempontokat.

Azure-beli segítségnyújtás

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 mindegyik 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.

Szolgáltatás Újrapróbálkozási képességek Szabályzatkonfiguráció Hatókör Telemetriafunkciók
Microsoft Entra ID Natív a Microsoft Authentication Libraryben (MSAL) Beágyazva az MSAL-kódtárba Belső None
Azure Cosmos DB Natív a szolgáltatásban Nem konfigurálható Globális TraceSource
Azure Data Lake Storage Natív az ügyfélben Nem konfigurálható Egyéni műveletek None
Azure Event Hubs Natív az ügyfélben Szoftveres Ügyfél None
Azure IoT Hub Natív az ügyféloldali SDK-ban Szoftveres Ügyfél None
Azure Cache for Redis Natív az ügyfélben Szoftveres Ügyfél TextWriter
Azure Cognitive Search Natív az ügyfélben Szoftveres Ügyfél ETW vagy egyéni
Azure Service Bus Natív az ügyfélben Szoftveres NamespaceManager, MessagingFactory és ügyfél ETW
Azure Service Fabric Natív az ügyfélben Szoftveres Ügyfél None
adatbázis Azure SQL ADO.NET Polly Deklaratív és szoftveres Önálló utasítások vagy kódblokkok Egyéni
SQL Database with Entity Framework Natív az ügyfélben Szoftveres Alkalmazástartományonként globális None
SQL Database with Entity Framework Core Natív az ügyfélben Szoftveres Alkalmazástartományonként globális None
Azure Storage Natív az ügyfélben Szoftveres Ügyfél- és különálló műveletek TraceSource

Megjegyzés

Az Azure beépített újrapróbálkozési mechanizmusainak többsége 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 optimális átlagos teljesítményt és rendelkezésre állást biztosít. A szabályzat finomhangolásának egyik módja a naplófájlok elemzése a felmerülő átmeneti hibák típusának meghatározásához.

Példa

A cikkben ismertetett számos mintát használó példát a .NET-hez készült Reliable webalkalmazás-minta című témakörben talál. A GitHubon referenciaimplementá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