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

Rugalmasság és magas rendelkezésre állás a mikroszolgáltatásokban

  • Cikk

Tipp.

Ez a tartalom egy részlet a .NET-alkalmazásokhoz készült .NET-alkalmazásokhoz készült eBook, .NET Microservices Architecture című eBookból, amely elérhető a .NET Docs-on vagy egy ingyenesen letölthető PDF-fájlként, amely offline módban is olvasható.

PDF letöltése

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

A váratlan hibák kezelése az egyik legnehezebb megoldási probléma, különösen az elosztott rendszerekben. A fejlesztők által írt kód nagy része kivételeket kezel, és itt tölti a legtöbb időt a tesztelés. A probléma több, mint kód írása a hibák kezelésére. Mi történik, ha a mikroszolgáltatást futtató gép meghibásodik? Nem csak ezt a mikroszolgáltatás-hibát kell észlelnie (önmagában nehéz probléma), hanem a mikroszolgáltatás újraindításához is szüksége van valamire.

A mikroszolgáltatásoknak ellenállónak kell lenniük a hibáknak, és gyakran újra kell tudniuk indítani egy másik gépen a rendelkezésre állás érdekében. Ez a rugalmasság a mikroszolgáltatás nevében mentett állapotra is vonatkozik, amelyből a mikroszolgáltatás helyreállíthatja ezt az állapotot, és hogy a mikroszolgáltatás sikeresen újraindulhat-e. Más szóval rugalmasságra van szükség a számítási képességben (a folyamat bármikor újraindulhat), valamint az állapot vagy az adatok rugalmasságának (nincs adatvesztés, és az adatok konzisztensek maradnak).

A rugalmassági problémák más helyzetekben is jelentkeznek, például ha egy alkalmazásfrissítés során hibák lépnek fel. Az üzembe helyezési rendszerrel együttműködő mikroszolgáltatásnak meg kell határoznia, hogy továbbléphet-e az újabb verzióra, vagy visszaállhat-e egy korábbi verzióra a konzisztens állapot fenntartása érdekében. Figyelembe kell venni az olyan kérdéseket, mint például, hogy elegendő gép áll-e rendelkezésre a továbblépéshez, és hogy miként állíthatók helyre a mikroszolgáltatás korábbi verziói. Ehhez a megközelítéshez a mikroszolgáltatásnak ki kell bocsátania az állapotinformációkat, hogy az általános alkalmazás és vezénylő meg tudja hozni ezeket a döntéseket.

A rugalmasság emellett a felhőalapú rendszerek viselkedéséhez is kapcsolódik. Ahogy már említettük, a felhőalapú rendszereknek át kell venniük a hibákat, és meg kell próbálniuk automatikusan helyreállítani őket. Hálózati vagy tárolóhibák esetén például az ügyfélalkalmazásoknak vagy az ügyfélszolgáltatásoknak rendelkezniük kell egy stratégiával az üzenetek újraküldésére vagy a kérések újrapróbálkozására, mivel a felhőbeli hibák sok esetben részlegesek. Az útmutató Rugalmas alkalmazások implementálása szakasza a részleges hibák kezelésével foglalkozik. Olyan technikákat ír le, mint az exponenciális visszalépéssel végzett újrapróbálkozások vagy a .NET-ben a Kapcsolattörő minta a Pollyhoz hasonló kódtárak használatával, amelyek számos szabályzatot kínálnak a téma kezeléséhez.

Állapotkezelés és diagnosztikák a mikroszolgáltatásokban

Nyilvánvalónak tűnhet, és gyakran figyelmen kívül hagyják, de egy mikroszolgáltatásnak jelentenie kell az állapotát és a diagnosztikát. Ellenkező esetben a műveletek szempontjából kevés megállapítás áll rendelkezésre. A diagnosztikai események korrelációja különböző független szolgáltatásokban és a gépi óraeltérések kezelése az eseményrend értelmezéséhez kihívást jelent. Ugyanúgy, ahogyan egy mikroszolgáltatással egyeztetett protokollokkal és adatformátumokkal kommunikál, szabványosítani kell az állapot- és diagnosztikai események naplózását, amelyek végül egy eseménytárba kerülnek a lekérdezéshez és megtekintéshez. A mikroszolgáltatás-megközelítésben kulcsfontosságú, hogy a különböző csapatok egyetlen naplózási formátumot fogadjanak el. Konzisztens megközelítést kell alkalmazni a diagnosztikai események alkalmazásbeli megtekintéséhez.

Állapotellenőrzések

Az állapot eltér a diagnosztikától. Az állapot arról szól, hogy a mikroszolgáltatás az aktuális állapotát jelenti a megfelelő műveletek elvégzéséhez. Jó példa erre a frissítési és üzembehelyezési mechanizmusok használata a rendelkezésre állás fenntartása érdekében. Bár egy szolgáltatás jelenleg nem megfelelő állapotú lehet egy folyamat összeomlása vagy a gép újraindítása miatt, a szolgáltatás továbbra is működőképes lehet. Az utolsó dolog, amire szüksége van, hogy ezt rontsa egy frissítés végrehajtásával. A legjobb módszer az, ha először vizsgálatot végez, vagy időt hagy a mikroszolgáltatás helyreállítására. A mikroszolgáltatásokból származó egészségügyi események segítenek megalapozott döntéseket hozni, és tulajdonképpen öngyógyító szolgáltatásokat létrehozni.

Az útmutató ASP.NET Core-szolgáltatásokban végzett állapotellenőrzések implementálásával foglalkozó szakaszában bemutatjuk, hogyan használhatnak új ASP.NET HealthChecks-kódtárat a mikroszolgáltatásokban, hogy a megfelelő műveletek elvégzéséhez jelentést tudjanak tenni az állapotukról egy monitorozási szolgáltatásnak.

A GitHubon és NuGet-csomagként elérhető AspNetCore.Diagnostics.HealthChecks nevű kiváló nyílt forráskódú kódtárat is használhat. Ez a kódtár az állapotellenőrzéseket is elvégzi, egy csavarral két típusú ellenőrzést kezel:

  • Élőség: Ellenőrzi, hogy a mikroszolgáltatás életben van-e, vagyis képes-e elfogadni a kéréseket és válaszolni.
  • Felkészültség: Ellenőrzi, hogy a mikroszolgáltatás függőségei (adatbázis, üzenetsor-szolgáltatások stb.) készen állnak-e, hogy a mikroszolgáltatás elvégezhesse a feladatát.

Diagnosztikák és naplók eseménystreamjeinek használata

A naplók információkat nyújtanak az alkalmazások vagy szolgáltatások működéséről, beleértve a kivételeket, a figyelmeztetéseket és az egyszerű tájékoztató üzeneteket. Általában minden napló szöveges formátumban van, eseményenként egy sorral, bár a kivételek gyakran több sorban is megjelenítik a verem nyomkövetését.

A monolitikus kiszolgálóalapú alkalmazásokban naplókat írhat egy lemezen lévő fájlba (egy naplófájlba), majd bármilyen eszközzel elemezheti. Mivel az alkalmazás végrehajtása rögzített kiszolgálóra vagy virtuális gépre korlátozódik, általában nem túl összetett az események folyamatának elemzéséhez. Az elosztott alkalmazásokban azonban, ahol egy vezénylőfürt számos csomópontja több csomóponton fut, kihívást jelent az elosztott események korrelációja.

A mikroszolgáltatás-alapú alkalmazások nem próbálják meg önállóan tárolni az események vagy naplófájlok kimeneti adatfolyamát, és nem is próbálják kezelni az események központi helyre történő átirányítását. Transzparensnek kell lennie, ami azt jelenti, hogy minden folyamatnak csak egy szabványos kimenetre kell írnia az eseményfolyamát, amelyet az alatta lévő végrehajtási környezet infrastruktúrája gyűjt, ahol fut. Ilyen eseménystream-útválasztók például a Microsoft.Diagnostic.EventFlow, amely több forrásból gyűjti össze az eseménystreameket, és közzéteszi őket a kimeneti rendszereken. Ezek lehetnek egyszerű szabványos kimenetek fejlesztési környezetekhez vagy felhőrendszerekhez, például az Azure Monitorhoz és az Azure Diagnosticshoz. Vannak olyan jó külső naplóelemzési platformok és eszközök is, amelyek valós időben is kereshetnek, riasztásokat, jelentéseket és monitorozhatnak naplókat, például a Splunkot.

Az állapot- és diagnosztikai adatokat kezelő vezénylők

Mikroszolgáltatás-alapú alkalmazás létrehozásakor foglalkoznia kell az összetettséggel. Természetesen egyetlen mikroszolgáltatást egyszerű kezelni, de több tucat vagy több száz típus és több ezer mikroszolgáltatás-példány összetett probléma. Nem csupán a mikroszolgáltatás-architektúra kiépítéséről van szó– a stabil és összetartó rendszer kialakításához magas rendelkezésre állásra, kezelhetőségre, rugalmasságra, állapotra és diagnosztika szükséges.

Diagram of clusters supplying a support platform for microservices.

4–22. ábra. A mikroszolgáltatási platform alapvető fontosságú az alkalmazások állapotkezeléséhez

A 4–22. ábrán látható összetett problémákat saját maga nehezen tudja megoldani. A fejlesztői csapatoknak az üzleti problémák megoldására és az egyéni alkalmazások mikroszolgáltatás-alapú megközelítésekkel történő létrehozására kell összpontosítaniuk. Nem szabad összetett infrastruktúra-problémák megoldására összpontosítaniuk; ha igen, akkor a mikroszolgáltatás-alapú alkalmazások költsége hatalmas lenne. Ezért vannak mikroszolgáltatás-orientált platformok, amelyeket vezénylőknek vagy mikroszolgáltatási fürtöknek neveznek, amelyek megpróbálják megoldani a szolgáltatás létrehozásának és futtatásának, valamint az infrastruktúra-erőforrások hatékony felhasználásának nehéz problémáit. Ez a megközelítés csökkenti a mikroszolgáltatás-megközelítést használó alkalmazások létrehozásának összetettségét.

A különböző vezénylők hasonlónak tűnhetnek, de az általuk kínált diagnosztikák és állapotellenőrzések jellemzőkben és fejlettségben különböznek, néha az operációsrendszer-platformtól függően, amint azt a következő szakaszban ismertetjük.

További erőforrások

Előzőkövetkező