A mikroszolgáltatás egy népszerű architekturális stílus a rugalmas, hatékonyan méretezhető, függetlenül üzembe helyezhető és gyorsan fejleszthető alkalmazások létrehozásához. De a sikeres mikroszolgáltatási architektúrához új megközelítés szükséges az alkalmazások tervezésekor és létrehozásakor.
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.
A mikroszolgáltatási architektúrák létrehozásának folyamata
Az itt felsorolt cikkek a mikroszolgáltatási architektúrák tervezésének, létrehozásának és működtetésének strukturált megközelítését ismertetik.
Tartományelemzés. A mikroszolgáltatások tervezésekor a gyakori buktatók elkerülése érdekében határozza meg a mikroszolgáltatás határait tartományelemzés segítségével. Tegye a következők egyikét:
- Mikroszolgáltatások modellezése tartományelemzéssel.
- Mikroszolgáltatások tervezése taktikai DDD használatával.
- A mikroszolgáltatások határainak azonosítása.
A szolgáltatások megtervezése. A mikroszolgáltatások esetében új megközelítés szükséges az alkalmazások tervezéséhez és létrehozásához. További információkért lásd: Mikroszolgáltatási architektúra tervezése.
Működtetés éles környezetben. Mivel a mikroszolgáltatási architektúrák elosztott rendszerűek, az üzembe helyezésükhöz és a monitorozásukhoz hatékony műveletekre van szükség.
- CI/CD a mikroszolgáltatási architektúrákhoz
- CI/CD-folyamat létrehozása a mikroszolgáltatásokhoz Kubernetesen
- Az Azure Kubernetes Service-en (AKS-en) futó mikroszolgáltatások monitorozása