Tervezés az önjavítást szem előtt tartva

Az alkalmazás tervezése önmaga kijavítására, ha hiba történik

Elosztott rendszerben a hibáknak várhatóan bekövetkezniük kell. Meghibásodhatnak a hardverek. Átmeneti hibák lehetnek a hálózaton. Ritkán fordul elő, hogy egy teljes szolgáltatás, adatközpont vagy akár Azure-régió fennakadást okoz, de még ezeket is a számítási feladatok architektúrájában kell megtervezni. A rugalmasságot és a helyreállítást a számítási feladatok tervezésének korai szakaszában kell kezelni.

Ezért olyan alkalmazást tervezzen, amely hibák esetén öngyógyító. Ehhez az alábbi három pillérre támaszkodó megközelítésre van szükség:

• A hibák észlelése.
• A hibákra adott megfelelő válasz.
• Naplózza és monitorozza a működési megállapításokat figyelő hibákat.

Egy adott hibatípusra való reagálás az alkalmazás rendelkezésre állási követelményeitől függ. Ha például magas rendelkezésre állást igényel, egy régióban több rendelkezésre állási zónában is üzembe helyezheti. A kimaradások elkerülése érdekében még akkor is, ha egy teljes Azure-régió nem valószínű, hogy fennakadást tapasztal, automatikusan átadhatja a feladatátvételt egy másodlagos régióba egy regionális kimaradás során. Ez azonban magasabb költséggel és potenciálisan alacsonyabb teljesítménnyel jár, mint az egyrégiós üzemelő példányok.

Emellett ne csak az olyan nagy eseményeket vegye figyelembe, mint a regionális kimaradások, mert ezek általában ritkán fordulnak elő. Legalább ennyire, vagy még jobban kell összpontosítania a helyi, rövid ideig tartó hibák, például a hálózati kapcsolathibák vagy a meghibásodott adatbázis-kapcsolatok kezelésére.

Ajánlások

Aszinkron módon kommunikáló leválasztott összetevők használata. Ideális esetben az összetevők térben és időben vannak elválasztva. Az időben leválasztott összetevők azt jelentik, hogy az összetevőknek nem kell egyszerre jelen lenniük ahhoz, hogy a kommunikáció lehetséges legyen. A térben leválasztva azt jelenti, hogy a feladónak és a fogadónak nem kell ugyanabban a folyamatban futnia, de bárhol, ahol hatékonyabb. A leválasztott összetevők ideális esetben események használatával kommunikálnak egymással. Ez segít minimalizálni a kaszkádolt hibák esélyét.

A sikertelen műveletek újrapróbálása. Átmeneti hibák a hálózati kapcsolat pillanatnyi megszakadása, megszakadt adatbázis-kapcsolat vagy egy szolgáltatás foglaltsága esetén időtúllépés miatt fordulhatnak elő. Építsen újrapróbálkozási logikát az alkalmazásba az átmeneti hibák kezelésére. Sok Azure-szolgáltatás esetében az ügyfél SDK automatikus újrapróbálkozásokat valósít meg. További információ: Átmeneti hibakezelés és újrapróbálkozási minta.

Hibás távoli szolgáltatások védelme (áramköri megszakító). Az átmeneti hibák után érdemes újrapróbálkozni, ha azonban a hiba továbbra is fennáll, az ahhoz vezethet, hogy túl sok hívó próbál igénybe venni egy hibás szolgáltatást. Ez kaszkádolt hibákhoz vezethet a kérések biztonsági mentésekor. Az áramkör-megszakító mintával gyorsan (a távoli hívás végrehajtása nélkül) meghiúsulhat, ha egy művelet valószínűleg sikertelen lesz.

Kritikus erőforrások elkülönítése (válaszfal). Egy alrendszerben bekövetkező meghibásodás időnként kaszkádolás révén elterjedhet. Ez akkor fordulhat elő, ha egy hiba miatt bizonyos erőforrásokat, például szálakat vagy szoftvercsatornákat nem szabadít fel időben, ami erőforrás-kimerüléshez vezet. Ennek elkerülése érdekében használja a Válaszfal mintát a rendszer izolált csoportokba való particionálására, hogy az egyik partíció meghibásodása ne okozzák a teljes rendszert.

Terheléskiegyenlítés végrehajtása. Az alkalmazások hirtelen megugró forgalomnövekedést tapasztalhatnak, ami túlterhelheti a háttérszolgáltatás szolgáltatásait. Ennek elkerülése érdekében használja az üzenetsor-alapú terheléselosztási mintát a munkaelemek aszinkron futtatásának várólistára helyezéséhez. Az üzenetsor pufferként működik, amely csökkenti a terhelési kiugrásokat.

Feladatátvétel. Ha egy példány nem érhető el, végezzen feladatátvételt egy másik példányra. Az állapot nélküli elemek, például webkiszolgálók esetén, helyezzen több példányt egy terheléselosztó vagy forgalomkezelő mögé. Az állapotot tároló elemek, például adatbázisok esetén, replikákat és feladatátvételt használjon. Az adattártól és a replikálás módjától függően előfordulhat, hogy az alkalmazásnak foglalkoznia kell a végleges konzisztenciával.

A sikertelen tranzakciók kompenzálása. Általában kerülje az elosztott tranzakciókat, mert a szolgáltatások és erőforrások közötti koordinációt igényelnek. Helyette kisebb, önálló tranzakciókból állítsa össze a műveleteket. Ha a művelet menet közben hiúsul meg, kompenzáló tranzakciók használatával vonhatja vissza a már végrehajtott lépéseket.

Ellenőrzőpontok elhelyezése a hosszú ideig futó tranzakciókban. Az ellenőrzőpontok rugalmasságot biztosítanak, ha egy hosszú ideig futó művelet meghiúsul. Amikor a művelet újraindul (például átveszi egy másik virtuális gép), az utolsó ellenőrzőponttól folytatható. Fontolja meg egy olyan mechanizmus implementálását, amely rendszeres időközönként rögzíti a tevékenység állapotadatait, és ezt az állapotot tartós tárolóba menti, amely a feladatot futtató folyamat bármely példánya számára elérhető. Ily módon, ha a folyamat le van állítva, az elvégzett munka egy másik példány használatával folytatható az utolsó ellenőrzőpontról. Vannak olyan kódtárak, amelyek biztosítják ezt a funkciót, például az NServiceBus és a MassTransit. Transzparensen megőrzik az állapotot, ahol az intervallumok az Azure Service Bus üzenetsoraiból érkező üzenetek feldolgozásához igazodnak.

Rontsa le kecsesen, és maradjon válaszkész a hiba során. Néha nem lehet megkerülni egy problémát, ilyenkor azonban biztosíthat csökkentett funkciók, amelyek továbbra is hasznosak. Vegyünk például egy könyvkatalógust megjelenítő alkalmazást. Ha az alkalmazás nem tudja lekérni a borítók miniatűrjét, helyőrző képet jeleníthet meg helyette. Előfordulhat, hogy teljes alrendszerek számítanak nem kritikus fontosságúnak az alkalmazás számára. Egy e-kereskedelmi webhelyen például a termékjavaslatok megjelenítése valószínűleg kevésbé kritikus, mint a megrendelések feldolgozása.

Ügyfelek forgalmának szabályozása. Előfordulhat, hogy néhány felhasználó túlzott terhelést okoz, ami csökkentheti az alkalmazás rendelkezésre állását más felhasználók számára. Ilyen helyzetben bizonyos ideig szabályozhatja az ügyfél forgalmát. Tekintse meg a szabályozás mintáját.

Kártékony elemek blokkolása. Egy ügyfél forgalmának szabályozása még nem jelenti azt, hogy az ügyfél rosszindulatúan viselkedett. Pusztán azt jelenti, hogy az ügyfél túllépte a szolgáltatási kvótát. Ha azonban egy ügyfél rendszeresen túllépi a kvótát, vagy egyéb helytelen magatartást tanúsít, blokkolhatja az ügyfelet. Határozzon meg egy sávon kívüli folyamatot a felhasználó számára a blokkolás feloldásának kéréséhez.

Vezetőválasztás használata. Amikor koordinálnia kell egy feladatot, a vezetőválasztás használatával válasszon koordinátort. Így a koordinátor nem lehet kritikus hibapont. Ha a koordinátor meghiúsul, a rendszer újat választ. A vezetőválasztási algoritmus alapoktól való megvalósítása helyett vegye fontolóra egy azonnal használható megoldás, például a Zookeeper használatát.

Tesztelés hibabeszúrással. A sikerhez vezető utat gyakran túl sokszor tesztelik, a sikertelenséghez vezetőt azonban egyáltalán nem. Egy rendszer hosszú ideig futhat éles üzemben, mielőtt hiba történik. Hibabeszúrással tesztelheti a rendszer meghibásodásokkal szembeni rugalmasságát valódi hibák kiváltása vagy azok szimulálása révén.

Véletlenszerű tesztelés alkalmazása. A chaos engineering kiterjeszti a hibainjektálás fogalmát úgy, hogy véletlenszerűen injektálja a hibákat vagy a rendellenes feltételeket az éles példányokba.

Rendelkezésre állási zónák használata. Számos Azure-régió biztosít rendelkezésre állási zónákat, amelyek a régióban elkülönített adatközpont-csoportok. Egyes Azure-szolgáltatások zónaszerűen helyezhetők üzembe, ami biztosítja, hogy egy adott zónába kerüljenek, és csökkenthetik az azonos számítási feladatban lévő összetevők közötti kommunikáció késését. Alternatív megoldásként egyes szolgáltatások zónaredundanciával is üzembe helyezhetők, ami azt jelenti, hogy az Azure automatikusan replikálja az erőforrást zónák között a magas rendelkezésre állás érdekében. Fontolja meg, hogy melyik megközelítés nyújtja a legjobb kompromisszumot a megoldáshoz. Ha többet szeretne megtudni arról, hogyan tervezheti meg a megoldást a rendelkezésre állási zónák és régiók használatára, tekintse meg a rendelkezésre állási zónák és régiók használatára vonatkozó javaslatokat.

Az alkalmazások öngyógyításának strukturált megközelítésével kapcsolatban lásd : Megbízható alkalmazások tervezése az Azure-hoz.