2016. július 06.

A mikroszervizek kialakításánál a tervezők megoldást próbáltak találni az összetett alkalmazások fejlesztésekor jelentkező szervezési problémákra, melyek az egyes komponensek fejlesztési ciklusainak összekapcsolódásából adódnak, és a szoftverfejlesztők munkáját nagyban megnehezítik.

 

Egy monolitikus szolgáltatás orientált architektúra esetén minden kis változtatás a teljes alkalmazás újrafordítását jelentheti. Mivel a fejlesztés jellemzően sok kis változtatás sorozatából áll, az újrafordítás nagyon gyakori, ami ha elhúzódik az a fejlesztők nem hatékony munkájához, frusztrációjához vezet. Ennél még komolyabb probléma, hogy az összefüggések miatt a fejlesztőknek a változtatásokat egymással koordináltan kell végrehajtaniuk. Minél összetettebb az alkalmazás, és minél többen dolgoznak rajta, annál nehezebb és a hibákra is érzékenyebb ez a feladat.

 

A mikroszerviz architektúra, a monolitikus megközelítéssel ellentétben, lehetővé teszi minden egyes mikroszerviznek egy egyedi folyamat futtatását és a saját adatbázisának menedzselését. Ez a fejlesztő csapatoknak lehetőséget biztosít az alkalmazás decentralizált tervezésére, valamint lehetővé teszi a komponensek egymástól független menedzselését.

 

Mivel a mikroszervizek meglehetősen széles és összetett területét fedik le az informatikának, úgy döntöttünk készítünk egy cikket a látogatóinknak, hogy elmagyarázzunk néhány általános fogalmat és tippet az ilyen rendszerekről.

 

Mikroszervíz architektúra

 

A mikroszervízek inkább fogalamak, mint használt technológiák gyűjteménye. Nem más, mint egy szoftver design ajánlás lazán összekapcsolt, könnyen változtatható és skálázható szolgáltatás architektúrák készítésére.

 

A monolitikus szolgáltatások hátrányai általában:

 

• meredek tanulási görbét kell a fejlesztőknek bejárniuk
• egyszerre az egész szoftverrel és környezettel kell foglalkozni
• nagyon nagy kódbázisok bonyolult ütközéseinek megoldása a feladat
• egy hatalmas szoftverben a hibák terjedése több modulra is kihathat
• rendkívül nehéz az egyes részek új üzleti igényeknek vagy új technológiáknak megfelelő megváltoztatása, újraírása (refactoring)

 

A szoftvernek a mikroszerviz elvek mentén kisebb részekre való feldarabolása több szempontból előnyös lehet:

 

• az egyes komponensek fejlesztését 2-3 fős független csapatokhoz lehet rendelni, akik tudásukat el tudják mélyíteni az adott területen és felelősséget tudnak így vállalni az adott komponens teljes életciklusára
• könnyebben érthető kódok, mivel a kódbázis sokkal kisebb
• sokkal kevesebb merge konfliktus mivel kevesebb ember dolgozik ugyanazon a kódon
• a leghatékonyabb technológiákat lehet alkalmazni a komponens feladataira
• a hardware erőforrásokat az adott feladatokhoz lehet külön-külön optimalizálni
• lazán csatolt, nyelvfüggetlen interfészek a komponensek között

 

A következő ábrán összehasonlítva áttekinthetőek a mikroszerviz megközelítés valamint a hagyományos monolit megközelítés közötti lényegesebb különbségek:

 

 

 

 

Kapcsolódó fogalmak

 

Felhő szolgáltatók

 

Egy megosztott szoftver futtatása elosztott környezetet követel meg, amely hagyományosan sok drága hardver megvásárlását, összeszerelését vonja maga után. Továbbá ezen eszközök tárolásához fizikai helyre van szükség, ügyelni kell arra, hogy elegendő energia és hálózati kapacitás álljon rendelkezésre, biztosítani kell a légkondicionálást, a visszaállítási és helyreállítási terveket kell készíteni és követni, valamint munkaerőt kell alkalmazni ezek kezeléséhez.

 

Ha szeretnénk a hardver erőforrásokat optimálisan használni, el fogjuk érni azt a pontot, amikor a virtualizáción kezdünk el gondolkodni, és be fogjuk látni, hogy az infrastruktúra kezeléséhez szükség van egy rendszerre, amely gyakran még több IT munkatársat igényel, mint korábban.

 

Az informatikai üzemeltetés legtöbb nehézségének elkerülésére a megoldása az, hogy az infrastruktúrát át kell helyezni egy harmadik fél által szolgáltatott felhőbe. Így nem kell aggódni többé a hardverhiány, a hardver meghibásodások, valamint az adat visszaállítás miatt. Minden ami ehhez szükséges, csupán csak pár kattintásra van.

 

 

Klaszterezés (Clustering)

 

A klaszterezés a mikroszervizek alfája és omegája, egy olyan architekturális koncepció amely képes kiszolgálni a nagy terhelést magas rendelkezésre állás mellett.

 

Ez elérhető több szerver hozzáadásával – klaszterek készítésével. Egy jól megtervezett klaszter alap funkciói a következőket biztosítják:

 

• hibatűrés: ha egy szerver kiesik valamilyen meghibásodás következtében, a teljes szolgáltatás nem állhat le
• terheléselosztás: , úgy osztja el a kéréseket, hogy minden szerver azonos mértékben legyen leterhelve. Lehetővé teszi nagy terhelés esetén további szerverek bekapcsolását a klaszterbe, vagy éppen leállítását, mikor nincs rá szükség.
• állapotfelmérés: rendszeresen ellenőrzést végez, hogy meghatározza a megfelelően működő szervereket és szolgáltatásokat, annak érdekében, hogy kijavítsa magát, ha egy csomópont kiesik.

 

 

Docker

          

Ha valaki szeretne tengerentúlra szállíttatni valamit, az áru az út nagy részét egy konténerben fogja megtenni. Szállítással foglalkozó vállalatok csinálják ezt, mert a konténerek szabványosak, így könnyen kezelhetőek. Minden teherhajó konténerek szállítására készült és minden kikötő rendelkezik konténerek mozgatására alkalmas darukkal.

 

Ezt a koncepciót lehet alkalmazni a szoftverekre is, a Docker használatával. A Docker egy megoldás, hogy az elkülönített szoftver környezetek létrehozása és elindítása kevésbé erőforrás igényes és hatékonyabb legyen azáltal, hogy azokat konténerekbe tesszük. Ezek a konténerek – mint amit a teherszállító hajók szállítanak – ugyanúgy néznek ki kívülről, így ugyanúgy tudjuk kezelni őket anélkül hogy tudnánk mi van benne. Könnyedén tudjuk mozgatni ezeket a konténereket különböző szervereken, és futtatni őket bárhol anélkül, hogy ismernénk a konténerek belsejében futó szoftverek összefüggéseit.

 

Docker konténerek használata a klaszterezési szolgáltatást sokkal könnyebbé teszik, mivel nem kell egyenként feltelepíteni minden szükséges szoftver komponenst minden egyes szerverre a klaszteren belül. Az egyetlen feltétel, hogy az elkészült szoftver Docker konténerekben futtathatóra kell készíteni, ezért a klaszter skálázása nagyon egyszerű. Ha egy szolgáltatás lehal a konténeren belül, akkor egyszerűen kicserélhető egy újra, így a klaszter automatikusan meg tudja „gyógyítani” magát.

 

 

Konklúzió

 

A fenti technológiákat azért szedtük csokorba, mert ezek mind összefüggenek egymással.

 

• felhő szolgáltatók lehetővé teszik, hogy a hardver erőforrásokat optimálisan használjuk
• Klaszterezés lehetővé teszi, hogy a hibatűrő szolgáltatások képesek kiszolgálni a nagy terhelést magas rendelkezésre állással
• a Docker szükségtelenné teszi, minden egyes szükséges szoftver komponens minden egyes csomópontra való feltelepítését, így a klaszterezési szolgáltatás sokkal egyszerűbb
• a mikroszervizek decentralizált megközelítést biztosítanak a szoftver készítéshez, valamint lehetővé teszi az egyes szolgáltatások önálló kezelését.

 

Miután az összes fent említett technológiát kombináljuk, az eredmény egy hibatűrő, skálázható és könnyen kezelhető vállalati szolgáltatás lesz.

 

A következő ábrával azt szemléltjük, hogy a felhő szolgáltatók, klaszterek és Docker konténerek hogyan kapcsolódnak egymáshoz: