Főoldal

"Mérnököt a mérnöktől"

A Schönherz Bázis összeköti az állást kereső és állást kínáló mérnököket.

CV küldés

Küldj önéletrajzot! Gyorsan, egyszerűen.
Megjegyzésbe írd be a pozíció nevét.
CV küldés

Iratkozz fel hírlevelünkre!

Hírek

Monolitikus vs Microservice architektúra
Monolitikus vs Microservice architektúra

Napjainkban sok figyelmet fordítanak a microservice architektúrára. Szinte minden informatikai vállalatnál sok vita, beszélgetés folyik róla. A microservice architektúrára könnyen megérthető, ha összehasonlítjuk a hagyományos, monolitikus architektúrával.

Szinte minden vállalati alkalmazásnak hasonló típusú, réteges architektúrája van:

  • Bemutatás, megjelenítés: A felhasználói felületet foglalja magába.
  • Üzleti logika: Az alkalmazás belső üzleti logikája.
  • Adatbázis-hozzáférés: Szinte minden alkalmazásnak elengedhetetlen a hozzáférés valamilyen adatbázishoz, legyen az SQL vagy akár NoSQL alapokon.
  • Alkalmazásintegráció: Gyakran előfordul, hogy az alkalmazásnak integrációra van szüksége más alkalmazásokkal. Ezt általában webes szolgáltatáshívások (SOAP vagy REST) vagy üzenetküldés útján érik el.


Annak ellenére, hogy az alkalmazások világos, logikailag moduláris felépítésűek, a legtöbb alkalmazás mégis monolitként van összeállítva, telepítve és működtetve. Ez a megoldás is természetesen rendelkezik néhány előnnyel.



A monolitikus architektúra előnyei

A fejlesztése nagyon egyszerű.

A tesztelés is rendkívül könnyű. Az alkalmazás elindításával máris elérhető az end to end, vagyis végpontból végpontba való tesztelés. A tesztmenedzsment automatizálását Selenium segítségével is elvégezhetjük.

A monolitikus alkalmazás használata egyszerű: csak le kell másolni a becsomagolt alkalmazást a szerverről.

A skálázhatóság is könnyen megoldható. Csak egy új példányt kell kérnünk a monolitikus alkalmazásból, és kérjük a terheléselosztót, hogy terjessze az új példányt is. Azonban, ahogy a monolitikus alkalmazás mérete nő, a skálázhatóság egyre komolyabb kérdéssé válik.

A monolitikus architektúra évtizedekig sikeresen működött. Valójában a legtöbb sikeres és nagy alkalmazást is eredetileg egy monolitként fejlesztették ki és telepítették fel. A nagyvállalatok számos nagyvállalati megoldást még mindig monolitként alkalmaznak. De a változó piaccal és az új technológiák kialakulásával paradigmaváltás történt az informatikai iparág működésében. Vannak komoly problémák a monolitikus architektúrával, amelyekkel a legtöbb vállalat egyre komolyabban foglalkozik napjainkban.



A monolitikus architektúra hátrányai

  • Rugalmasság: A monolitikus szerkezet nem rugalmas. Nem használhatunk különböző technológiákat rajta keresztül. A technológiai keret a kezdeteknél eldől és mindvégig csak erre a meghatározott keretre lehet hagyatkozni. Ahogy az architektúra fejlődik, érettebbé válik, úgy válik egyre nehezebbé a technológiai keret fejlesztése is, arról nem is beszélve, hogy így közel lehetetlen egy új technológiát beépíteni.
  • Megbízhatóság: A megoldás egyszerűen nem megbízható. Ha egy szolgáltatás leáll, az egész alkalmazás működésében is kiesést okoz.
    Fejlesztési sebesség: A fejlesztés valóban lassú a monolitikus architektúra esetén. Kihívást jelent az új csapattagok számára, hogy megértsék és módosítsák egy nagy monolitikus alkalmazás kódját. A kód minősége pedig idővel csökken. A kódbázis növekvő méretével az IDE túlterhelt és lassabb lesz. Minél nagyobb az alkalmazás, annál hosszabb ideig tart az elindítása. Mindezek a tényezők óriási hatást gyakorolnak a fejlesztők hatékonyságára.
    Komplex alkalmazások építése: Nehéz komplex alkalmazást létrehozni a technológiákkal kapcsolatos korlátozások miatt.
  • Skálázhatóság: A monolitikus alkalmazásokat egyre nehezebb lesz skálázni, a méretük függvényében. . Új példányokat hozhatunk létre a monolitból, és megkérhetjük a terheléselosztót, hogy terjessze a forgalmat az új példányokra, de a monolitikus architektúra nem tud növekvő terhelés mellett skálázni. Az alkalmazáspéldány minden egyes példánya hozzáfér az összes adathoz, ezáltal kevésbé hatékony a gyorsítótár, növekszik a memóriafelhasználás és az I / O forgalom. A különböző alkalmazás összetevőknek is eltérő erőforrásigényük van - az egyik lehet CPU-intenzív, míg a másik memória intenzív. A monolitikus architektúrával nem tudjuk függetleníteni az egyes összetevőket.
  • Folyamatos telepítés: A folyamatos telepítés rendkívül nehéz. A nagy monolitikus alkalmazások valójában akadályt jelentenek a gyakori telepítésekhez. Az egyik összetevő frissítéséhez át kell állítanunk az egész alkalmazást.


A monolitikus alkalmazások fenti hátrányai miatt a microservice architektúra egyre népszerűbb napról napra. Tehát mi is a microservice alapú architektúra?

Röviden, a microservice architektúra egy olyan alkalmazás fejleszti megközelítés, ami egyetlen alkalmazás fejlesztését javasolja, mint kis szolgáltatások egy csomagja, ahol minden szolgáltatás a saját folyamataiban fut, működik, és könnyű mechanizmusokkal kommunikálnak egymással, rendszerint webes szolgáltatások vagy üzenetküldés útján. Ezek a szolgáltatások üzleti funkciók köré épülnek, és teljesen automatizált telepítési gépekkel önállóan telepíthetők. Ezeknek a szolgáltatásoknak a központosított menedzselése minimális, különböző programozási nyelveken lehet őket kifejleszteni, és különböző adattárolási technológiákat alkalmaznak. A microservice architektúra olyan kicsi, önállóan telepíthető egységekből áll, amelyek felhőalapúak.


Hogyan válaszol a microservice architekrúra a monolitikus architektúra hátrányaira?

  • Rugalmasság: a microservice architektúra meglehetősen rugalmas. Különböző mikro-szolgáltatásokat lehet kifejleszteni a különböző technológiákban. Mivel a mikroszolgáltatás kisebb, a kódbázis is kisebb, ezért közebb az újabb technológiai frissítések véghezvitele. Emellett fokozatosan az újabb technológiákat is alkalmazhatjuk bennük nehézségek nélkül.
  • Megbízhatóság: A microservice architektúra nagyon megbízhatónak bizonyul.  Ha egy funkció leáll, a teljes alkalmazás nem áll meg. Megoldhatjuk a problémát a megfelelő mikro szolgáltatásban és azonnal újra használatba állíthatjuk.
  • Fejlesztési sebesség: A fejlesztés nagyon gyors a microservice architektúrában. Mivel a kód mennyisége sokkal kevesebb, egy csapat új tagjai számára sem nehéz megérteni és módosítani a kódot. A kezdetektől fogva hatékonyak lesznek. A kód minősége jól fenntartható. Az IDE sokkal gyorsabb. A mikro-szolgáltatás sokkal kevesebb időt vesz igénybe az induláshoz. Mindezek a tényezők jelentősen növelik a fejlesztők hatékonyságát.
  • Komplex alkalmazások építése: Microservice architektúrával könnyű összetett alkalmazásokat készíteni. Ha az alkalmazás jellemzőit megfelelően elemezzük, akkor független alkotóelemekre bonthatjuk őket, amelyek egymástól függetlenül telepíthetők. Ezután még a független alkotóelemeket is tovább lehet bontani kis önálló feladatokra, amelyek függetlenül telepíthetők. A microservice architektúrára határainak meghatározása elég nagy kihívást jelenthet. Ez valójában egy evolúciós folyamat, de miután döntöttünk egy bizonyos microservice architektúra mellett, könnyű fejleszteni, mivel nincsenek korlátozások a technológiákban.


Mint korábban említettem, a microservice architektúrára könnyen érthető, ha összehasonlítjuk a hagyományos monolitikus architektúrával, de a microservice előtt is már létezett egy hasonló architektúra, ami a szolgáltatásorientált architektúra. (SOA = Service-Oriented Architecture). A SOA már két évtizede létezik. Ha már dolgoztak a SOA-val és ismerik a fogalmakat, meglehetősen zavaros lehet a SOA és microservice architektúrára közötti különbségek megértése. Valójában a kettő sokkal gyakoribb, mint a különbségek. 


(Forrás


***

Ha Te is kreatív, kihívásokkal teli mérnök állást keresel minõségi munkáltatónál, jó helyen jársz, mert a Schönherz Bázis épp azért jött létre, hogy Neked segítsen.
Gyere, nézz szét aktuális állásaink között!