Rugalmasság tervezése
 A számítási feladatnak továbbra is teljes vagy csökkentett funkcionalitással kell működnie. |
|---|
Az összetevők meghibásodására, a platformkimaradásokra, a teljesítménycsökkenésre és egyéb hibákra kell számítania. Rugalmasságot építhet ki a rendszerben, hogy hibatűrő legyen, és kecsesen csökkenjen.
Példaforgatókönyv
A Contoso Air egy kereskedelmi légitársaság, amely házon belüli fejlesztési részlegekkel rendelkezik. A fő LOB-alkalmazás egy foglalási megoldás, amellyel az ügyfelek közvetlenül a Contoso Air-szel foglalhatnak járatokat. Az alkalmazás az Azure-ban készült, és Azure-alkalmazás Service, Cosmos DB, Azure Functions, Azure Logic Apps és Azure Service Bus szolgáltatást használ.
Hibakockázatok meghatározása
Azonosítsa a rendszer lehetséges meghibásodási pontjait, különösen a kritikus összetevőket, és határozza meg a felhasználóra és a rendszerfolyamatokra gyakorolt hatást.
Elemezze a meghibásodási esetet, a robbanási sugarat és a hiba intenzitását az egyes lehetséges meghibásodási pontok esetében. A meghibásodási esetek és azok intenzitása a viszonylag alacsony hatású forgatókönyvektől, például a háttérfolyamat ideiglenes elvesztésétől a katasztrófákból eredő teljes körű kimaradásokig terjedhet. Az elemzés végrehajtásával meghatározhatja a hibakezelési képességek tervezését az összetevő szintjén.
A Contoso kihívása
- A LOB alkalmazás számos kulcsfontosságú funkciót kínál a marketingtől a kereskedelemig. A jegyvásárlási felhasználói folyamat a legkritikusabb folyamat. A számítási feladatokért felelős csapat megállapította, hogy több megbízhatósági intézkedést kell végrehajtani annak érdekében, hogy a folyamat rugalmasságra legyen optimalizálva.
- A csapat tervezett ideje van az olyan fejlesztésekre, mint az összetevők leválasztása és a folyamatok újratervezése, de biztosítani szeretné, hogy ezt az időt arra használják, hogy a legnagyobb értékű fejlesztésekre összpontosítsanak.
A megközelítés és az eredmények alkalmazása
- A csapat potenciális hibapontként azonosítja a külső fizetési átjárót. Az átjáró magas rendelkezésre állású, de előfordulhat, hogy a felhasználók időnként átmeneti hibákat tapasztalnak, amelyek hálózati problémákból vagy rendkívül magas kérések sorozatából erednek. Előfordulhat, hogy az átjáró elutasít bizonyos kéréseket, ha több egyidejű kérés is túlterhelte.
- A csapat megállapítja, hogy a felhasználóknak újra kell küldeniük a kéréseket, amikor az átjáró elutasítja a kezdeti kéréseiket, ami negatív felhasználói élményt okoz.
Önmegőrző mechanizmusok megvalósítása
Önmegőrző képességeket hozhat létre a tervezési minták helyes használatával, és modularizálhatja a kialakítást a hibák elkülönítése érdekében.
Ha önmegőrző képességeket épít be a rendszerbe, megakadályozhatja, hogy egy probléma hatással legyen az alsóbb rétegbeli összetevőkre. A rendszer képes lesz enyhíteni az átmeneti és állandó hibákat, a teljesítmény szűk keresztmetszeteit és a megbízhatóságot esetlegesen befolyásoló egyéb problémákat. A robbanási sugarat is minimalizálhatja.
A Contoso kihívása
- A csapat szeretné minimalizálni az átmeneti hibák kockázatát, ami miatt a fizetési átjáró elutasítja a felhasználók kéréseit. A hibafeltételek egy részének átmeneti jellege miatt nagy a valószínűsége annak, hogy ugyanaz a kérés sikeres lesz, ha újra be van adva.
A megközelítés és az eredmények alkalmazása
- A csapat egyéni logikát fejleszt a folyamatban, hogy rövid késleltetés után újrapróbálkozzék a tranzakció, amikor egy újrapróbálkozható hiba észlelhető.
- A megoldástervet úgy módosítjuk, hogy az újrapróbálkozási mintát is beépítse, kissé növelve az újrapróbálkozások közötti várakozási időt, amíg a kérés sikeresen fel nem dolgozódik, vagy eléri a hibák maximális számát.
- A csapat emellett úgy dönt, hogy az Azure Service Bus eseményvezérelt megközelítésével leválasztja a folyamat felhasználói interakcióját és háttérbeli fizetésfeldolgozási funkcióit. Ha az üzenet feldolgozása során (az újrapróbálkozások maximális száma után) helyreállíthatatlan hibák lépnek fel, a háttérfeldolgozó leállítja a kérés feldolgozását, így az üzenet a várólistán marad, hogy később újra feldolgozható legyen.
Átfogó redundancia és rugalmasság kiépítése
Redundancia létrehozása rétegekben és rugalmasság különböző alkalmazásszinteken.
A fizikai segédprogramok és az azonnali adatreplikálás redundanciáját célozza meg. A szolgáltatásokra, műveletekre és személyzetre vonatkozó funkcionális réteg redundanciára is törekszik. A redundancia segít minimalizálni az egyes meghibásodási pontokat. Ha például egy vagy több összetevőt, rendelkezésre állási zónát vagy egy teljes régiót érintő kimaradás van, a redundáns (aktív-aktív vagy aktív-passzív) üzembe helyezés lehetővé teszi az üzemidő-célok elérését.
A közvetítők hozzáadása megakadályozza az összetevők közötti közvetlen függőséget, és javítja a pufferelést. Mindkét előny megkeményíti a rendszer rugalmasságát.
A Contoso kihívása
- Az újrapróbálkozási és a fizetési átjáró hívásainak a Felhasználói felületről a Service Bus használatával történő leválasztása jelentősen megnövelte ennek a folyamatnak a megbízhatóságát, de az üzleti érdekelt felek továbbra is aggódnak az elsődleges régió katasztrofális meghibásodása miatt bekövetkező adatvesztés miatt.
A megközelítés és az eredmények alkalmazása
- A csapat úgy dönt, hogy prémium szintű Service Busra frissít. Ezzel kihasználhatják a szint rendelkezésre állási zónáinak támogatási funkcióit. Ezzel a funkcióval az adatok több példánya három fizikailag elkülönített létesítményben (rendelkezésre állási zónákban) van tárolva, és a szolgáltatás elegendő kapacitással rendelkezik ahhoz, hogy azonnal megbirkózzon egy adatközpont teljes, katasztrofális veszteségével.
- Emellett a csapat úgy konfigurálja az Azure Service Bus geo-vészhelyreállítást, hogy folyamatosan replikálja az adatokat egy másodlagos régióba, amelyet az elsődleges régió teljes meghibásodása esetén használnak majd.