Bevált módszerek átmeneti hibakezeléshez

A távoli szolgáltatásokkal és erőforrásokkal kommunikáló összes alkalmazásnak észlelnie és helyre kell állítania az átmeneti hibákat. Ez a követelmény különösen igaz a felhőben futó alkalmazásokra. A felhőkörnyezet jellege és az interneten keresztüli kapcsolat miatt az alkalmazás valószínűleg gyakrabban tapasztal átmeneti hibákat. 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 fellépő időtúllépések. Ezek a hibák általában beavatkozás nélkül megoldódnak, ezért a művelet valószínűleg sikeres lesz, ha az alkalmazás megfelelő késleltetés után újrapróbálkozza.

Az átmeneti hibakezelés kulcsfontosságú rugalmassági technika az Azure Well-Architected-keretrendszer megbízhatósági pillérén belül. Ha alkalmazásszinten észleli és helyreállítja az átmeneti hibákat, segít megelőzni azokat a kaszkádolt hibákat, amelyek szélesebb körű incidenskezelési vagy vészhelyreállítási (DR) eljárásokat válthatnak ki. A hatékony átmeneti hibakezelés segít a számítási feladatnak a rutinszerű fennakadások elviselésében és a rendelkezésre állás fenntartásában az infrastruktúraszintű helyreállítási eljárások eszkalálása nélkül.

Miért fordulnak elő átmeneti hibák a felhőben?

Átmeneti hibák bármilyen környezetben, bármilyen platformon vagy operációs rendszeren, és bármilyen alkalmazásban előfordulhatnak. A helyszíni infrastruktúrán futó megoldások esetében a redundáns hardverek általában fenntartják az alkalmazás és összetevői teljesítményét és rendelkezésre állását. Az összetevők és az erőforrások szintén egymás közelében találhatók. Ez a módszer kevésbé valószínű, de átmeneti hibák továbbra is előfordulhatnak. A váratlan események, például a külső áramellátás, a hálózati problémák vagy más vészforgatókönyvek kimaradásokat okozhatnak. A redundáns hardverek költségesek is lehetnek, és gyakran kihasználatlanok.

A felhőkörnyezetek nagyobb általános rendelkezésre állást biztosíthatnak, mivel a számítási feladatokat számos kiszolgálón elosztják, és redundanciát, automatikus feladatátvételt és dinamikus erőforrás-lefoglalást használnak. A felhőkörnyezetek természete azonban több okból is valószínűbbé teszi az átmeneti hibákat:

• A felhőkörnyezetben számos erőforrás meg van osztva, és az erőforrások védelme érdekében szabályozás vonatkozik ezekhez az erőforrásokhoz. Egyes szolgáltatások elutasítják a kapcsolatokat, ha a terhelés eléri a megadott szintet vagy maximális átviteli sebességet. Ez a megközelítés lehetővé teszi a szolgáltatás számára a meglévő kérések feldolgozását és az összes felhasználó teljesítményének fenntartását. A forgalomkorlá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 számú normál 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.

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

• Az ügyfél és a kiszolgáló közötti hálózati feltételek gyakran eltérőek, különösen akkor, ha a kommunikáció az interneten keresztül történik. A nagy forgalmú terhelések még a helyszíni helyeken is lelassíthatják a kommunikációt, és időszakos csatlakozási hibákat okozhatnak.

Kihívások

Az átmeneti hibák jelentősen befolyásolhatják az alkalmazások érzékelt rendelkezésre állását, még akkor is, ha a várt körülmények között alaposan teszteli. Annak érdekében, hogy a felhőalapú alkalmazások megbízhatóan működjenek, a következő kihívásokkal kell foglalkozniuk:

• Az alkalmazásnak képesnek kell lennie észlelni a hibákat, amikor előfordulnak, és meg kell állapítania, hogy a hibák átmenetiek, tartósak vagy terminálhibák-e. A különböző erőforrások általában különböző válaszokat adnak vissza hiba esetén. Ezek a válaszok a művelet kontextusától függően is változhatnak. Előfordulhat például, hogy egy olyan hiba válasza, amikor az alkalmazás beolvassa a tárolóból, eltérhet a tárolóba írásakor megjelenő hiba válaszától.

  Számos erőforrás és szolgáltatás jól dokumentált átmeneti meghibásodási szerződéssel rendelkezik. Ha ezek az információk nem érhetők el, nehezebb meghatározni 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 lesz. Azt is nyomon kell követnie, hogy hányszor próbálkozik újra a művelettel.

• Az alkalmazásnak olyan újrapróbálkozési stratégiát kell használnia, amely megfelel a követelményeknek. A stratégia meghatározza, hogy az alkalmazásnak hányszor kell újrapróbálkoznia, a kísérletek közötti késést és a sikertelen kísérletek után végrehajtandó műveleteket. A kísérletek száma és az egyes próbálkozások közötti késés gyakran nehezen határozható meg. 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.

Általános irányelvek

Az alábbi irányelvek segítenek megfelelő átmeneti hibakezelési mechanizmusok kialakításában az alkalmazások számára.

Ellenőrizze, hogy létezik-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. Alternatív megoldásként a szolgáltatások REST-felületei olyan információkat is visszaadhatnak, amelyek segíthetnek meghatározni, hogy szükség van-e újrapróbálkozásra, és mennyi ideig kell várni a következő kísérlet előtt.

Használja a beépített újrapróbálkozás mechanizmust, ha egy beépített lehetőség áll rendelkezésre, kivéve, ha olyan konkrét és jól érthető követelményekkel rendelkezik, amelyek egy másik újrapróbálkozásra alkalmasabb viselkedést tesznek lehetővé a forgatókönyvhöz.

Az Azure-szolgáltatások mindegyike eltérően kezeli az átmeneti hibákat. Egyes szolgáltatások SDK-szintű újrapróbálkozási szabályzatokat biztosítanak, amelyek konfigurálható visszalépési algoritmusokat tartalmaznak. Más szolgáltatások olyan platformfunkciókat biztosítanak, mint az állapottesztek és a láthatósági időtúllépések, amelyek kiegészítik az alkalmazásszintű újrapróbálkozások logikáját. Tekintse meg az egyes Azure-szolgáltatások megbízhatósági útmutatójában . Ezek az útmutatók egy dedikált szakaszt tartalmaznak, amely szolgáltatásspecifikus javaslatokat nyújt az újrapróbálkozások konfigurálásához, az időtúllépés finomhangolásához és az állapotfigyeléshez.

Ellenőrizze, hogy az újrapróbálkozás megfelel-e a műveletnek

Csak akkor próbálkozzon újra a feladatokkal, ha a hibák átmenetiek, amit a hiba természete általában jelez, és ha a művelet sikeres lehet újrapróbálkozott. A HTTP-alapú szolgáltatások esetében a 429 (túl sok kérés) és az 5xx kiszolgálói hibák jellemzően újrapróbálkozásra alkalmas hibák. A legtöbb 4xx ügyfélhiba( például 400, 401, 403 és 404) azt jelzi, hogy az újrapróbálkozások nem oldódnak meg. Ne próbálkozzon újra olyan műveletekkel, amelyek nem sikerülhetnek, például frissítsen egy nem létező adatbázis-elemet, vagy hívjon meg egy olyan szolgáltatást, amely végzetes hibát eredményezett.

Az újrapróbálkozásokat általában csak akkor hajthatja végre, ha meg tudja határozni azok teljes hatását, és amikor megérti és érvényesítheti a feltételeket. Ellenkező esetben hagyja, hogy a hívó kód implementáljon újrapróbálkozásokat. Az önön kívül eső erőforrásokból és szolgáltatásokból visszaadott hibák idővel változhatnak, és előfordulhat, hogy újra meg kell ismételnie az átmeneti hibaészlelési logikát.

Szolgáltatások vagy összetevők létrehozásakor olyan hibakódokat és üzeneteket implementálhat, amelyek segítenek az ügyfeleknek eldönteni, hogy újrapróbálkoznak-e a sikertelen műveletek. Adjon vissza például egy isTransient értéket, amely jelzi, hogy az ügyfélnek újra meg kell-e próbálnia a műveletet, é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, a szolgáltatásszerződések által definiált egyéni hibákat adja vissza. Előfordulhat, hogy az általános ügyfelek nem tudják elolvasni ezeket a hibákat, de egyéni ügyfelek létrehozásakor hasznosak.

A megfelelő újrapróbálkozási szám és intervallum meghatározása

Optimalizálja az újrapróbálkozási számot és a használati eset típusának időközét. Ha nem próbálkozik elég alkalommal, az alkalmazás nem tudja végrehajtani a műveletet, és sikertelen lesz. Ha túl sokszor próbálkozik újra, vagy nem vár elég sokáig a próbálkozások között, előfordulhat, hogy az alkalmazás hosszú ideig tart olyan erőforrásokat, mint a szálak, a kapcsolatok és a memória, ami hátrányosan befolyásolja az alkalmazás állapotát. További információ: Újrapróbálkozási minta.

Módosítsa az időintervallum értékeit és az újrapróbálkozások számát a művelet típusához. Ha például a művelet egy felhasználói beavatkozás része, az időköznek rövidnek kell lennie, és csak néhány újrapróbálkozási kísérletet kell végrehajtania. Ezzel a megközelítéssel elkerülheti, hogy a felhasználók várjanak a válaszra, 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, a kísérletek között hosszabb időt is várhat, és többször próbálkozhat újra.

A sikeres stratégia kialakításának legnehezebb része az újrapróbálkozások közötti megfelelő időközök meghatározása. A tipikus stratégiák az alábbi típusú újrapróbálkozási időközt használják:

• Exponenciális visszakapcsolás: Az alkalmazás az első újrapróbálkozás előtt rövid ideig várakozik, majd exponenciálisan növeli az egyes újrapróbálkozások közötti időt. Előfordulhat például, hogy két másodperc, négy másodperc, nyolc másodperc és egy megadott számú próbálkozás vagy teljes időtartam után próbálja újra végrehajtani a műveletet. Minden újrapróbálkozási időközhöz adjon hozzá egy kis véletlenszerű késleltetést, amely megakadályozza, hogy több ügyfél szinkronizálja az újrapróbálkozást, és terhelési csúcsokat hozzon létre a célszolgáltatáson.

• Növekményes időközök: 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 3 másodperc, 7 másodperc és 11 másodperc után újrapróbálkozza a műveletet.

• Rendszeres időközök: Az alkalmazás minden kísérlet között ugyanazt az időtartamot várja. Előfordulhat például, hogy három másodpercenként újrapróbálkozza a műveletet.

• Azonnali újrapróbálkozás: Az olyan átmeneti hibák, mint a hálózati csomagok ütközése vagy a hardverösszetevők kiugrása, általában időszakosak. Ezekben az esetekben a művelet azonnali újrapróbálkozása segíthet, 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. Ne próbálkozzon egynél több azonnali újrapróbálkozási kísérlettel. Ha az azonnali újrapróbálkozás sikertelen, váltson alternatív stratégiákra, például exponenciális visszalépé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 annak érdekében, hogy a kliens különböző példányai ne egyszerre küldjenek 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 vagy 28 másodperc után újrapróbálkozza a műveletet, míg egy másik példány 4 másodperc, 12 másodperc vagy 26 másodperc után újrapróbálkozza a műveletet. A véletlenszerűség hasznos módszer, amelyet más stratégiákkal kombinálhat.

Használjon exponenciális visszalépéses stratégiát a háttérműveleteknél jitter használatával, é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ésést és az újrapróbálkozások számát, hogy az újrapróbálkozási kísérletek maximális késése megfeleljen a végpontok közötti késésre vonatkozó követelménynek.

A tényezők kombinációja hozzájárul az újrapróbálkozott műveletek teljes maximális időtúllépéséhez. Fontolja meg a következő tényezőket:

• A sikertelen kapcsolatra adott válasz előállításához szükséges idő. Az ügyfélben beállított időtúllépési érték általában meghatározza ezt az időt.

• Az újrapróbálkozási kísérletek közötti késés.

• Az újrapróbálkozések maximális száma.

Ezeknek az időknek az összege 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övekszik. Ha egy folyamatnak meg kell felelnie egy adott szolgáltatásiszint-célkitűzésnek (SLO), a teljes műveleti időnek, beleértve az összes időtúllépést és késést, az SLO-ban meghatározott korlátokon belül kell lennie.

Az újrapróbálkozási időközök kiválasztásakor figyelembe kell vennie 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 az újrapróbálkozási időközhöz hasonló. Határozza meg, hogy meg kell-e tartania a teljes lehetséges időszakot, azaz az időtúllépést és az újrapróbálkozási időközöket egy adott teljes időkorlát alatt. 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.

Állítson be időtúllépéseket minden kimenő híváshoz az újrapróbálkozás logikája implementálása előtt. Az időtúllépések, az újrapróbálkozások és a visszalépési módszerek együttműködnek. Az újrapróbálkozási stratégia csak olyan hatékony, mint az egyes kísérleteket szabályozó időtúllépések. A túl hosszú időtúllépések miatt a szálak és kapcsolatok halmozódnak fel a kimaradások során. A túl rövid időtúllépések idő előtti meghibásodásokat okoznak az egyébként sikeres műveleteknél.

Ne alkalmazzon túlzottan agresszív újrapróbálkozési stratégiákat. Ezek a stratégiák túl rövid időközöket használnak, vagy túl gyakran újrapróbálkoznak. Ezek hátrányosan befolyásolhatják a célerőforrást vagy szolgáltatást. Emellett megakadályozhatják az erőforrás vagy szolgáltatás helyreállítását is, így az erőforrás vagy szolgáltatás továbbra is blokkolja vagy elutasítja a kéréseket. Ez a forgatókönyv létrehoz egy ciklust, amelyben az alkalmazás további kéréseket küld az erőforrásnak vagy szolgáltatásnak, ami tovább csökkenti a helyreállítás képességét.

Az újrapróbálkozások számának és a köztük lévő intervallumnak a optimalizálásához használja a kivétel típusát és a benne lévő adatokat, illetve a szolgáltatás által visszaadott hibakódokat és üzeneteket. Egyes kivételek vagy hibakódok, például a HTTP 503 (A szolgáltatás nem érhető el) azt jelezhetik, hogy a szolgáltatás meghiúsult, és nem válaszol a további kísérletekre. Ha egy válasz fejlécet Retry-After tartalmaz, kövesse azt, és várjon legalább a megadott időtartamot a következő kísérlet előtt. Ez a kiszolgáló által biztosított jel tükrözi a szolgáltatás helyreállítási ütemtervét, és elsőbbséget élvez az ügyféloldali háttérszámítással szemben.

Használja a halott üzenetsor megközelítést, hogy a bejövő kérés adatai ne vesszenek el az összes újrapróbálkozási lehetőséget kimerítve. Ez a technika nem elveti, hanem későbbi feldolgozásra halasztja a sikertelen munkát.

Kerülje az antipatterneket

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 használnak, vagy amelyek újrapróbálkozást alkalmaznak a művelet minden szakaszában, amely a kérések hierarchiáját foglalja magában, kivéve, ha konkrét követelményekkel rendelkezik. Ezekben a kivételes esetekben olyan szabályzatokat használjon, amelyek korlátozzák az újrapróbálkozások és a késleltetési időszakok számát, és győződjön meg arról, hogy tisztában van a következményekkel.

Vegyük például azt az összetevőt, amely kérést küld egy másiknak, amely ezután hozzáfér a célszolgáltatáshoz. A három újrapróbálkozás a két híváson összesen kilenc újrapróbálkozási kísérletet eredményez 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. Kapcsolja ki vagy módosítsa ezeket a mechanizmusokat, ha magasabb szinten kell végrehajtania az újrapróbálkozásokat. A nem koordinált újrapróbálkozási kockázatokról további információt az Újrapróbálkozási vihar antiminta című témakörben talál.

Soha ne implementáljon végtelen újrapróbálkozásos mechanizmust. Ez a megközelítés általában megakadályozza, hogy az erőforrás vagy szolgáltatás helyreálljon a túlterhelési helyzetekből, és a teljesítménykorlátozás, valamint a visszautasított kapcsolatok hosszabb ideig tartó fennmaradását okozza. Használjon véges számú újrapróbálkozást, vagy implementáljon egy mintát, mint a Circuit Breaker mintáját, hogy lehetővé tegye a szolgáltatás helyreállítását.

Alkalmazzon újrapróbálkozási költségvetést az újrapróbálkozások teljes számának korlátozásához egy folyamaton vagy szolgáltatáson belüli összes kérelemre az egyes kérések korlátain felül. Engedélyezheti például, hogy egy folyamat percenként legfeljebb 60 újrapróbálkozást hajthasson végre egy adott függőséghez képest. Ha kimeríti a költségvetést, az újrapróbálkozás helyett azonnal meghiúsul a kérés.

A kérelmekre vonatkozó újrapróbálkozási korlátok önmagukban nem akadályozhatják meg azt a forgatókönyvet, amelyben sok egyidejű kérés újrapróbálkozva próbálkozik néhányszor, és együttesen túlterhelik a nehéz alsóbb rétegbeli szolgáltatást. Az újrapróbálkozási költségvetés korlátozza az összesítő újrapróbálkozási terhelést, és különbséget tehet a honosított kapacitással kapcsolatos probléma és a kaszkádolt hiba között.

Soha ne próbálkozzon újra többször.

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 visszaesés stratégiája, amely egy körmegszakító képességet használ.

Kerüld el, hogy ugyanazon ügyfél több példánya vagy különböző ügyfelek több példánya egyszerre küldjenek újrapróbálkozásokat. Ha ez a forgatókönyv valószínű, szúrja be a véletlenszerűségeket az újrapróbálkozási időközökbe.

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

Tesztelje újrapróbálkozási stratégiáját számos feltétel között, különösen akkor, ha az alkalmazás és a célerőforrások vagy szolgáltatások szélsőséges terhelés alatt működnek. A tesztelés során a viselkedés ellenőrzéséhez hajtsa végre a következő műveleteket:

• 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. Küldjön például nem támogatott kéréseket, vagy adjon hozzá olyan kódot, amely észleli a tesztkéréseket, és különböző típusú hibákkal válaszol.

• Hozzon létre egy modellverziót az erőforrás vagy szolgáltatás számára, amely a valós szolgáltatás által visszaadott hibák tartományát adja vissza. Győződjön meg arról, hogy az az újrapróbálkozások stratégiája által észlelt összes hibatípust lefedi.

• A létrehozott és üzembe helyezhető egyéni szolgáltatások esetében kényszerítse az átmeneti hibák előfordulását a szolgáltatás ideiglenes offline állapotba helyezésével vagy a szolgáltatás túlterhelésével. Ne próbálja túlterhelni a megosztott erőforrásokat vagy a megosztott szolgáltatásokat az Azure-ban.

• Fontolja meg egy hibainjektálási szolgáltatás használatát az Azure-erőforrásokon végzett ellenőrzött kísérletek futtatásához. Az Azure Chaos Studio például támogatja a közvetlen szolgáltatáshibákat, például a hálózati késés hozzáadását vagy a gyorsítótárfürt újraindítását, valamint az ügynökalapú hibákat, például a memóriaterhelés alkalmazását vagy egy folyamat virtuális gépen (VM) történő befejezését. A hibainjektálási kísérleteket a folyamatos integrációs és folyamatos kézbesítési (CI/CD) folyamatokba integrálhatja, hogy az üzembe helyezési folyamat részeként folyamatosan ellenőrizze a rugalmasságot.

• HTTP-alapú API-k esetén érdemes lehet egy kódtárat használni az automatizált tesztekben a HTTP-kérések eredményének módosításához, akár extra ciklikus idő hozzáadásával, akár a válasz módosításával, például a HTTP-állapotkód, fejlécek, törzs vagy egyéb tényezők módosításával. Ez a megközelítés segít determinisztikusan tesztelni az átmeneti hibák és más típusú hibák hibafeltételeinek egy részét.

• Futtasson nagy terhelésű és egyidejű teszteket, 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 megerősítik, hogy az újrapróbálkozási kísérletek nem befolyásolják az ügyfélműveleteket, és keresztszennyezettséget okoznak a kérések között.

Újrapróbálkozások szabályzatkonfigurációinak kezelése

A ú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 a következő tényezőket határozza meg:

• Az, hogy egy hiba valószínűleg átmeneti-e
• A használandó intervallum típusa, például rendszeres, exponenciális visszakapcsolás vagy véletlenszerűség
• A tényleges intervallumértékek
• Az újrapróbálkozandó alkalmak száma

Az újrapróbálkozásokat számos helyen implementáljuk, például az alapszintű alkalmazásokban és az összetettebb alkalmazások minden rétegében. A szabályzatelemek több helyen történő kemény kódolása helyett használjon egy központi pontot 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. Ez a megközelítés leegyszerűsíti a beállítások kezelését, valamint az értékek módosítását és finomhangolását, hogy reagáljon a változó követelményekre és forgatókönyvekre. Úgy tervezheti meg a rendszert, hogy tárolja az értékeket ahelyett, hogy minden kéréshez újraolvasná a konfigurációs fájlt, és megfelelő alapértelmezett értékeket használjon, ha a konfiguráció nem adja meg az értékeket.

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, hogy 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ák előnyeit, de csak akkor, ha azok megfelelnek az Ön forgatókönyvének. Ezek a stratégiák általában általánosak. Bizonyos helyzetekben megfelelőek lehetnek, más esetekben azonban nem biztosítják az adott követelményeknek megfelelő lehetőségek teljes körét. A legmegfelelőbb értékek meghatározásához tesztelje, hogy a beállítások hogyan befolyásolják az alkalmazást. A szolgáltatásspecifikus újrapróbálkozások alapértelmezett beállításaiért és konfigurációs beállításaiért tekintse meg az architektúra egyes Azure-szolgáltatásainak megbízhatósági útmutatóját .

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

Az újrapróbálkozási stratégiának tartalmaznia kell a kivételkezelést és az újrapróbálkozási kísérleteket naplózandó egyéb rendszerállapotokat. Időnként átmeneti hiba és újrapróbálkozás várható, és nem jelez problémát. A rendszeres vagy növekvő számú újrapróbálkozás azonban általában olyan problémát jelez, amely meghibásodást okozhat, vagy csökkentheti az alkalmazás teljesítményét és rendelkezésre állását.

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

Tároljon egy értéket a naplóbejegyzésekben, amely jelzi, hogy a szolgáltatásban történő szabályozás vagy más típusú hibák, például a csatlakozási hibák újrapróbálkozást okoznak. Ez a megközelítés segít megkülönböztetni az okokat az adatelemzés során. A szabályozási hibák növekedése általában az alkalmazás tervezési hibáját vagy a dedikált hardvert biztosító prémium szolgáltatásba való migrálás szükségességét jelzi.

Mérje meg és naplózza az újrapróbálkozási mechanizmust tartalmazó műveletek teljes eltelt idejét. Ez a metrika pontosan jelzi, hogy az átmeneti hibák milyen általános hatással vannak 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, hogy megértse a válaszidőhöz hozzájáruló tényezőket.

Telemetria- és monitorozási rendszer implementálása, amely riasztásokat hoz létre a következő metrikák növekedésekor:

• A hibák száma és aránya
• Az újrapróbálkozések átlagos száma
• A műveletek sikeres végrehajtása előtt eltelt teljes idő

Folyamatosan sikertelen műveletek kezelése

Hozzon létre egy tervet a továbbra is sikertelen műveletek kezelésére minden kísérletnél. Ezek a helyzetek elkerülhetetlenek.

• Az újrapróbálkozási stratégia határozza meg, hogy egy alkalmazás legfeljebb hány alkalommal próbálkozzon újra egy műveletet. Ez nem akadályozza meg, hogy az alkalmazás azonos számú újrapróbálkozással kezdje a műveletet. Ha például egy rendelésfeldolgozó szolgáltatás végzetes hibával meghiúsul, amely véglegesen kivezeti azt a szolgáltatásból, az újrapróbálkozási stratégia észlelheti a kapcsolat időtúllépését, és átmeneti hibaként kezelheti azt. A kód újrapróbálkozza a műveletet a megadott számú alkalommal, majd leáll. Amikor egy másik ügyfél megrendelést ad le, az alkalmazás megpróbálja újra végrehajtani a műveletet, de sikertelenül próbálkozik.

• A folyamatosan sikertelen műveletek folyamatos újrapróbálkozásának megakadályozása érdekében implementálja az áramkör-megszakító mintá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 az alkalmazás nem próbál 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 időszakosan tesztelheti a szolgáltatást, hogy észlelje, mikor válik elérhetővé. Az intervallum olyan tényezőktől függ, mint a művelet kritikussága és a szolgáltatás jellege. Ez néhány perctől több óráig terjedhet. 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 esni egy másik adatközpontban vagy alkalmazásban lévő szolgáltatás egy másik példányára. Használhat egy hasonló szolgáltatást is, amely kompatibilis, de egyszerűbb funkciókat biztosít, 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 tárolja, majd később újrapróbálkozza őket. 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 biztosíthat, vagy egyszerűen elküldhet egy üzenetet a felhasználónak, amely jelzi, hogy az alkalmazás jelenleg nem érhető el.

Egyéb szempontok

Amikor meghatározza az újrapróbálkozások számának és a szabályzat újrapróbálkozási időközeinek értékeit, fontolja meg, hogy a szolgáltatás vagy erőforrás művelete 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, amikor az egyik sikertelen volt. Ebben az esetben a hosszú időköz és a nagy számú újrapróbálkozás elfogadható lehet, ha a stratégia nem blokkolja az egyéb műveleteket 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 adatkonzisztenciákat okozhat-e. Ha egy alkalmazás megismétli egy többlépéses folyamat részeit, és a műveletek nem idempotensek, következetlenségek léphetnek fel. Ha például egy értéket növekményes művelet ismétlődik, helytelen eredményt ad. Az üzenetsorba üzenetet küldő ismétlődő műveletek olyan problémákat is okozhatnak a fogyasztó számára, amelyek nem tudják észlelni 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ó: Idempotens fogyasztói minta.

Legyen tudatos az alkalmazás által újra végrehajtandó műveletek hatókörével kapcsolatban. Egyszerűbb lehet például olyan szinten implementálni az újrapróbálkozási logikát, amely több műveletet is tartalmaz, és újrapróbálkozik, ha az egyik sikertelen. Ez a megközelítés azonban idempotencia-problémákhoz vagy szükségtelen visszaállítási műveletekhez vezethet.

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ésleltetését az újrapróbálkozási időközök meghatározásakor, a művelet eltelt idejének figyelésekor, és mielőtt riasztásokat emelne a hibákért.

Ismerje meg, hogy az újrapróbálkoztatási stratégia hogyan befolyásolja a megosztott alkalmazás szomszédait és más bérlőit, valamint hogy mikor használ megosztott erőforrásokat és szolgáltatásokat. Az agresszív újrapróbálkozási szabályzatok növelhetik a többi felhasználó és az erőforrásokat és szolgáltatásokat megosztó alkalmazások átmeneti hibáinak számát. A más felhasználók által implementálható újrapróbálkozással kapcsolatos szabályzatok az alkalmazásra is hatással lehetnek. Az üzletileg kritikus fontosságú alkalmazásokhoz használjon olyan prémium szolgáltatásokat, amelyek nincsenek megosztva. Ez a megközelítés lehetővé teszi az erőforrások és szolgáltatások terhelésének és ennek következtében azok szabályozásának ellenőrzését, ami igazolhatja a többletköltségeket.

Következő lépés

Számítási feladatok tervezése átmeneti hibák kezelésére