Monolitikus és mikroszolgáltatás-alapú architektúrák
A Fabrikam integrálta az új drónszolgáltatást a meglévő alkalmazásba. Tisztában vannak azzal, hogy ez a megoldás nem jó hosszú távú terv az alkalmazáshoz. A meglévő rendszer monolitikus architektúrájú, de mit is jelent ez pontosan?
Mi az a monolitikus architektúra?
Monolitikus az az architektúra, amelyben egy alkalmazás összetevői egyetlen egységen belül helyezkednek el. Ez az egység általában az alkalmazás egyetlen futó példányára korlátozódik. A hagyományos alkalmazások gyakran webes felületből, szolgáltatási rétegből és adatrétegből állnak. Monolitikus architektúrában ezek a rétegek az alkalmazás egy példányában vannak kombinálva.
A monolitikus architektúra gyakran megfelelő megoldás kisebb alkalmazásokhoz, az alkalmazás növekedésével azonban egyre nehezebben kezelhető. Egy eredetileg kis alkalmazás gyorsan összetett rendszerré nőhet, amelyen nehéz skálázni, nehéz üzembe helyezni, és nehéz rá újításokat építeni.
Az összes szolgáltatás egyetlen egységen belül található. Ez a megoldás az üzleti és a későbbi rendszerterhelések növekedésével egyre nagyobb kihívásokat jelent majd. Ilyenek többek között a következők:
- A szolgáltatásokat nehéz külön skálázni.
- A kódbázis növekedésével egyre bonyolultabb a fejlesztés és az üzembe helyezés lebonyolítása, ezáltal lassabb a kiadás és az új funkciók megvalósítása.
- Az architektúra egyetlen technológiai veremhez van kötve, amely korlátozza az új platformok és SDK-k innovációját.
- Az adatséma-frissítések egyre bonyolultabbá válnak.
Ezek a nehézségek más architektúrák, például a mikroszolgáltatás-architektúra felhasználásával orvosolhatók.
Mi az a mikroszolgáltatás-architektúra?
A mikroszolgáltatás-architektúrák kicsi, önálló és lazán kapcsolódó szolgáltatásokból állnak. Minden szolgáltatás külön helyezhető üzembe és skálázható.
A mikroszolgáltatások általában elég kis méretűek ahhoz, hogy fejlesztők egy kis csoportja alkalmas legyen a megírásukra és fenntartásukra. Mivel a szolgáltatások egymástól függetlenül üzembe helyezhetők, egy csapat a meglévő szolgáltatást a teljes alkalmazás újraépítése és ismételt üzembe helyezése nélkül frissítheti.
Általában minden szolgáltatás a saját adataiért felel. Adatstruktúrája el van különítve, ezért a séma frissítései és módosításai nem függnek a többi szolgáltatástól. Az adatok iránti kérelmek jellemzően API-kon keresztül vannak kezelve, így jól definiált és konzisztens hozzáférési modellt biztosítanak. A belső megvalósítási részletek rejtve vannak a többi szolgáltatás felhasználói elől.
Mivel minden szolgáltatás független, különböző technológiai eszközkészleteket, keretrendszereket és szoftverfejlesztői készleteket hasznosíthatnak. Gyakran előfordul, hogy a szolgáltatások a szolgáltatásközi kommunikáció REST-hívásaira támaszkodnak, és a távoli eljáráshívások (RPC-k) vagy más egyéni kommunikációs módszerek helyett jól definiált API-kat használnak.
A mikroszolgáltatás-architektúrák technológiafüggetlenek, de az implementációjukhoz gyakran használnak tárolókat vagy kiszolgáló nélküli technológiákat. Gyakran folyamatos üzembe helyezés és folyamatos integráció (CI/CD) használatával fokozzák a fejlesztési tevékenységek gyorsaságát és minőségét.
A mikroszolgáltatás-architektúrák előnyei
Miért lehet érdemes mikroszolgáltatás-architektúrát választani? A mikroszolgáltatás-architektúrák számos elsődleges előnnyel járnak:
- Rugalmasság
- Kis kód, kis csapatok
- Technológiák vegyítése
- Tartósság
- Méretezhetőség
- Az adatok elkülönítése
Rugalmasság
Mivel a mikroszolgáltatások egymástól függetlenül üzemelnek, a hibajavítások és a funkciók kiadása egyszerűbben felügyelhető. A szolgáltatásokat a teljes alkalmazás ismételt üzembe helyezése nélkül frissítheti, illetve visszavonhat egy frissítést, ha valami probléma merül fel. Számos hagyományos alkalmazásra jellemző, hogy ha az alkalmazás egy részében hiba található, az megakadályozhatja a teljes kiadási folyamatot. Ennek eredményeképpen előfordulhat, hogy az új funkciók egy hibajavítás integrálására, tesztelésére és közzétételére várnak.
Kis kód, kis csapatok
A mikroszolgáltatásoknak elég kis méretűnek kell lenniük ahhoz, hogy egyetlen termékfejlesztő-csapat képes legyen elkészíteni, tesztelni és üzembe helyezni azokat. A kis kódbázisok könnyebben átláthatóak. Nagyméretű monolitikus alkalmazásokban a kódfüggőségek általában egyre bonyolultabbá válnak. Ha új funkciót szeretnénk hozzáadni, ahhoz számos helyen hozzá kell nyúlni a kódhoz. A mikroszolgáltatás-architektúra minimálisra csökkenti a függőségeket azáltal, hogy nem oszt meg kódokat vagy adattárakat. Ezzel az új funkciók hozzáadása is egyszerűbben elvégezhető.
A kis csapatméret elősegíti a nagyobb fokú rugalmasságot. A „kétpizzás szabály” szerint egy csapatnak elég kicsinek kell lennie ahhoz, hogy két pizzával jóllakjon mindenki. Természetesen ez nem egy pontos metrika, és a csapat étvágyától is függ! A lényeg azonban az, hogy a nagy csoportok általában kevésbé hatékonyak, mivel a kommunikáció lassabb, a vezetési költségek magasabbak és a rugalmasság csökken.
Technológiák vegyítése
A csapatok kiválaszthatják a szolgáltatásukhoz legmegfelelőbb technológiát. Szükség szerint a technológiai stackek kombinációját is használhatják. Így minden csapat a többitől függetlenül fejlesztheti a szolgáltatást támogató technológiákat. A szolgáltatások ennek a függetlenségnek köszönhetően hasznosíthatnak például eltérő fejlesztési nyelveket, felhőszolgáltatásokat és szoftverfejlesztői készleteket. A Teams kiválaszthatja a legjobb lehetőségeket a szolgáltatáshoz, és minimalizálhatja a szolgáltatás felhasználóira gyakorolt külső hatásokat.
Tartósság
Ha egy adott mikroszolgáltatás elérhetetlenné válik, az nem zavarja meg a teljes alkalmazást, amíg a felsőbb rétegbeli mikroszolgáltatások a hibák megfelelő kezelésére vannak kialakítva (például kapcsolatcsoporttörés implementálásával). A felhasználók vagy a szolgáltatásfelhasználók számára nyújtott előnyök mindig hasznos élményt nyújtanak az alkalmazás számára.
Méretezhetőség
A mikroszolgáltatási architektúra lehetővé teszi, hogy az összes mikroszolgáltatást egymástól függetlenül skálázhassa. Így horizontálisan felskálázhatja a több erőforrást igénylő alrendszereket anélkül, hogy a teljes alkalmazást skáláznia kellene. Ez a megoldás javítja az alkalmazás általános teljesítményét. Emellett segít a költségek csökkentésében is. A teljes alkalmazás méretezése helyett több erőforrást is hozzáadhat csak azokhoz a szolgáltatásokhoz, amelyeknek szüksége van rájuk.
Az adatok elkülönítése
A mikroszolgáltatást alkalmazó architektúrával javul az adatséma-frissítések végrehajtásának képessége, mivel azok csak egyetlen mikroszolgáltatást érintenek. A monolitikus alkalmazásokban a séma frissítései is problémát jelenthetnek. Előfordulhat, hogy az alkalmazás különböző részei ugyanazokat az adatokat érintik, így a séma bármilyen módosítása kockázatos lehet. A mikroszolgáltatás-architektúrával frissítheti a sémát, de érintetlenül tarthatja az API-felületét. A szolgáltatás felhasználói a mögöttes adatarchitektúrától függetlenül ugyanazt a felhasználói élményt kapják.
A mikroszolgáltatás-architektúrák használatával járó esetleges nehézségek
A mikroszolgáltatás-architektúrák számos előnnyel járnak, de ez sem jelent mindenre megoldást. A mikroszolgáltatás-architektúráknak is megvannak a saját problémái:
- Összetettség
- Fejlesztés és tesztelés
- Irányítás hiánya
- Hálózati torlódás és késés
- Adatintegritás
- Menedzsment
- Verziókezelés
- Képzettség
Összetettség
A mikroszolgáltatás-alkalmazások több mozgó részből állnak, mint az egyenértékű monolitikus alkalmazások. Az egyes szolgáltatások egyszerűbbek, de a rendszer egésze összetettebb. A szolgáltatás-felderítési, -vezénylési és -automatizálási eszközökkel együtt a teljes alkalmazásban esetleg több darabot kell kezelni.
Fejlesztés és tesztelés
Egy más függő szolgáltatásokra épülő kis méretű szolgáltatás más megközelítést kíván, mint egy hagyományos monolitikus vagy rétegzett alkalmazás megírása. A meglévő eszközöket nem mindig a szolgáltatásfüggőségekkel való együttműködésre tervezték. A szolgáltatás határain túlnyúló újrabontás bonyolult lehet. A szolgáltatásfüggőségek tesztelése is kihívást jelent, különösen akkor, ha az alkalmazás gyorsan fejlődik.
Irányítás hiánya
A mikroszolgáltatások építésének decentralizált megközelítése rendelkezik előnyökkel, de problémákhoz is vezethet. Előfordulhat, hogy végül olyan sok különböző nyelv és keretrendszer lesz jelen, hogy nehézkessé válik az alkalmazás karbantartása. Hasznos lehet néhány projektszintű szabvány bevezetése, a csapat rugalmasságának túlzott korlátozása nélkül. Az egységes szabványok szükséglete vonatkozik az egész rendszert érintő funkciókra, például a naplózásra és a metrikákra is.
Hálózati torlódás és késés
A sok kis részletes szolgáltatás használata több szolgáltatások közötti kommunikációt eredményezhet. Ha a szolgáltatási függőségek lánca túl hosszú lesz, például az A szolgáltatás B hívása, amely C-t hív meg, a hálózati hívások további késése problémát okozhat. Gondosan tervezze meg az API-kat. Kerülje a túlságosan forgalmas API-kat, gondoljon a szerializálási formátumokra, és keressen helyet az aszinkron kommunikáció használatához.
Adatintegritás
Minden egyes mikroszolgáltatás a saját adatai megőrzéséért felelős. Ennek eredményeként az adatkonzisztencia problémát jelenthet. Ahol lehetséges, támogassa a végső konzisztenciát. Bekövetkezhet az adatok duplikálódása és az adatarchitektúra túlzott kiterjedése. Ebben a helyzetben a szolgáltatások és adatok duplikációja magasabb tárolási költségekkel és adatplatform-szolgáltatási költségekkel járhat.
Menedzsment
Ahhoz, hogy sikeresen használhassa a mikroszolgáltatásokat, fejlett DevOps-kultúra szükséges. A szolgáltatások korrelált naplózása kihívást jelenthet. A naplózásnak általában több szolgáltatás-hívást kell korrelálnia egyetlen felhasználói művelethez.
Verziókezelés
Egy szolgáltatás frissítéseinek tilos megszüntetnie a tőle függő szolgáltatásokat. Egy adott időpontban több szolgáltatás is frissülhet. Körültekintő tervezés nélkül problémák merülhetnek fel a visszamenőleges vagy a jövőbeli kompatibilitással kapcsolatban. Az új API-verziókat késve alkalmazó szolgáltatások miatt a régebbi API-k több erőforrást és karbantartást igényelhetnek.
Képzettség
A mikroszolgáltatások több helyre elosztott rendszerek. Az elosztott rendszerek megfelelő fejlesztése, felügyelete és karbantartása sokszor másféle szaktudást igényel. Gondosan mérlegelje, hogy a csapat rendelkezik-e a sikerességhez szükséges szakértelemmel és tapasztalattal. Biztosítsa a csapatok képzettségének kialakításához szükséges időt és tervezést.
Mikor érdemes mikroszolgáltatás-architektúrát választani?
Mindezt a háttérinformációt figyelembe véve milyen helyzetekben alkalmazható legjobban a mikroszolgáltatás-architektúra?
- Kiadások gyors megjelenését igénylő, nagy méretű alkalmazások.
- Összetett alkalmazások, amelyeknek nagy mértékben skálázhatónak kell lenniük.
- Sok tartománnyal vagy sok altartománnyal rendelkező alkalmazások.
- Kis fejlesztői csapatokból álló vállalatok.