A mikroszolgáltatási architektúra kisebb, autonóm szolgáltatások gyűjteményéből áll. Minden szolgáltatás önálló, és egyetlen üzleti képességet kell implementálnia egy határos környezetben. A határolt környezet egy természetes osztás egy vállalaton belül, és explicit határt biztosít, amelyen belül egy tartománymodell létezik.
Mik azok a mikroszolgáltatások?
A mikroszolgáltatások kicsik, függetlenek és lazán összekapcsoltak. Fejlesztők egy kis csoportja alkalmas az egyes szolgáltatások megírására és fenntartására.
Minden szolgáltatás egy külön kódbázis, amelyet egy kis fejlesztői csapat felügyelhet.
A szolgáltatások egymástól függetlenül is ü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.
A szolgáltatások a saját adataik vagy külső állapotuk fenntartásáért felelősek. Ez eltér a hagyományos modelltől, ahol egy külön adatréteg kezeli az adatmegőrzést.
A szolgáltatások jól meghatározott API-k használatával kommunikálnak egymással. Az egyes szolgáltatások belső megvalósítási részletei rejtve vannak a többi szolgáltatás elől.
Támogatja a poliglot programozást. A szolgáltatásoknak például nem kell ugyanazt a technológiai vermet, kódtárat vagy keretrendszert megosztaniuk.
A szolgáltatások mellett általában néhány egyéb összetevő is megjelenik a mikroszolgáltatási architektúrákban:
Felügyelet/vezénylés. Ez az összetevő felelős például a szolgáltatások csomópontra helyezéséért, a hibák azonosításáért, a szolgáltatások újraegyensúlyozásáért a csomópontokon stb. Ez az összetevő általában nem egyéni, hanem használatra kész technológia, mint a Kubernetes.
API-átjáró. Az API-átjáró az ügyfelek belépési pontja. A szolgáltatások közvetlen meghívása helyett az ügyfelek az API-átjárót hívják meg, amely továbbítja a hívást a háttérben található megfelelő szolgáltatásnak.
Az API-átjáró használatának előnyei a következők:
Elválasztja az ügyfeleket a szolgáltatásoktól. A szolgáltatások az összes ügyfél frissítése nélkül elláthatók verziószámmal vagy újratervezhetők.
A szolgáltatások használhatnak nem webbarát üzenetküldési protokollokat (például AMQP).
Az API-átjáró egyéb, az egész rendszert érintő funkciókat is végrehajthat, például hitelesítést, naplózást, SSL-lezárást és terheléselosztást.
Beépített szabályzatok, például szabályozás, gyorsítótárazás, átalakítás vagy érvényesítés.
Juttatások
Agilitás. 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. Előfordulhat, hogy az új funkciók várakoznak arra, hogy egy hibajavítás integrálva, tesztelve és közzétéve legyen.
Kis méretű, célzott 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 csapatméret elősegíti a nagyobb fokú rugalmasságot. 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.
Kis kódbázis. Monolitikus alkalmazásokban az idő múlásával a kódfüggőségek elszabadulnak. Egy új funkció hozzáadásához sok helyen meg kell érinteni a kódot. Mivel nem osztoznak a kódon vagy adattárakon, a mikroszolgáltatási architektúrák minimalizálják a függőségeket, így az új funkciók hozzáadása egyszerűbben elvégezhető.
Technológiák vegyítése. A csapatok kiválaszthatják a szolgáltatásukhoz legmegfelelőbb technológiát, illetve szükség szerint ezek elegyét.
Hibaelkülönítés. Ha egy adott mikroszolgáltatás elérhetetlenné válik, az nem fogja megzavarni az egész alkalmazást, amíg a felsőbb rétegbeli mikroszolgáltatások a hibák megfelelő kezelésére vannak kialakítva. Implementálhatja például az áramkör-megszakító mintát, vagy megtervezheti a megoldást, hogy a mikroszolgáltatások aszinkron üzenetkezelési minták használatával kommunikáljanak egymással.
Skálázhatóság. A szolgáltatások egymástól függetlenül skálázhatók, í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. Az olyan vezénylők, mint a Kubernetes, nagyobb sűrűségű szolgáltatásokat csomagolhat egyetlen gazdagépre, ami lehetővé teszi az erőforrások hatékonyabb kihasználását.
Adatelkülönítés. A sémafrissítések végrehajtása sokkal egyszerűbb, mivel csak egyetlen mikroszolgáltatást érintenek. Monolitikus alkalmazásokban a sémafrissítések nagy kihívást jelenthetnek, mivel az alkalmazás különböző részei ugyanazokat az adatokat érinthetik, így a séma bármilyen módosítása kockázatos lehet.
Problémák
A mikroszolgáltatások előnyei azonban következményekkel is járnak. Íme néhány probléma, amelyet érdemes mérlegelni a mikroszolgáltatási architektúra bevezetése előtt.
Ö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.
Fejlesztés és tesztelés. A más függő szolgáltatásokra támaszkodó kis szolgáltatások írása más megközelítést igényel, mint egy hagyományos monolitikus vagy rétegzett alkalmazás í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. Ez különösen az egész rendszert érintő funkciókra vonatkozik (például a naplózásra).
Hálózati torlódás és késleltetés. A sok kis részletes szolgáltatás használata több szolgáltatások közötti kommunikációt eredményezhet. Emellett ha a szolgáltatásfüggőségek láncolata túl hosszú (A szolgáltatás meghívja a B-t, amely meghívja a C-t, stb.), a további késleltetés problémává válhat. Gondosan kell megterveznie az API-kat. Kerülje a túlságosan csevegéses API-kat, gondolja át a szerializációs formátumokat, és keressen olyan helyeket, ahol aszinkron kommunikációs mintákat, például üzenetsor-alapú terhelésszintezést használhat.
Adatintegritás. Az egyes mikroszolgáltatások a saját adataik megőrzéséért felelősek. Ennek eredményeként az adatkonzisztencia problémát jelenthet. Ahol lehetséges, támogassa a végső konzisztenciát.
Felügyelet. 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ószámozás. Egy szolgáltatás frissítéseinek tilos megszüntetnie a tőle függő szolgáltatásokat. Bármikor frissülhet akár több szolgáltatás is, ezért 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.
Képzettség. A mikroszolgáltatások több helyre elosztott rendszerek. Gondosan mérlegelje, hogy a csapat rendelkezik-e a sikerességhez szükséges szakértelemmel és tapasztalattal.
Ajánlott eljárások
Modellezze a szolgáltatásokat az üzleti tartomány köré.
Decentralizáljon mindent. Az egyes csapatok felelősek a szolgáltatások megtervezéséért és építéséért. Kerülje a kódok és adatsémák megosztását.
Az adattárolót csak az adatokat birtokló szolgáltatás érhesse el. Használja a legjobb tárolót minden szolgáltatáshoz és adattípushoz.
A szolgáltatások gondosan megtervezett API-kon keresztül kommunikálnak. Kerülje a megvalósítási részletek kiszivárgását. Az API-knak a tartományt kell modellezniük, nem a szolgáltatás belső megvalósítását.
Kerülje a szolgáltatások összekapcsolását. Az összekapcsolás okai például a megosztott adatbázissémák és a merev kommunikációs protokollok.
Szervezze ki az egész rendszert érintő funkciókat, például a hitelesítést vagy SSL-lezárást az átjáróhoz.
A tartományra vonatkozó ismereteket tartsa az átjárón kívül. Az átjárónak az üzleti szabályok és a tartományi logika ismerete nélkül kell kezelnie és irányítania az ügyfélkérelmeket. Ellenkező esetben az átjáró függőségé válik és a szolgáltatások összekapcsolását okozhatja.
A szolgáltatásoknak laza összekapcsolással és magas működési kohézióval kell rendelkezniük. A várhatóan együtt módosuló funkciókat egy csomagba kell rendezni, és együtt kell üzembe helyezni. Ha ezek külön szolgáltatásokban találhatók, a szolgáltatások végül szorosan össze lesznek kapcsolva, mert az egyik szolgáltatás módosítása a másik szolgáltatás frissítését igényli. A két szolgáltatás közötti, túl forgalmas kommunikáció a szoros összekapcsolás és az alacsony kohézió jele lehet.
Különítse el a hibákat. Használjon rugalmassági stratégiákat, hogy megelőzze a szolgáltatásban fellépő hibák halmozódását. Lásd a rugalmassági mintákat és a megbízható alkalmazások tervezését.
Következő lépések
A mikroszolgáltatási architektúrák Azure-ban való létrehozásáról részletes útmutatót a Mikroszolgáltatások tervezése, létrehozása és működtetése az Azure-ban című szakaszban talál.