Mikroszolgáltatás-architektúrastílus

Azure

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.

Előnyök

• Agilitás. Mivel a mikroszolgáltatások egymástól függetlenül vannak üzembe helyezve, könnyebben kezelhetők a hibajavítások és a funkciókiadások. 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. Sok hagyományos alkalmazásban, ha az alkalmazás egyik részében hiba található, az blokkolhatja 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 kicsinek kell lenniük ahhoz, hogy egyetlen szolgáltatáscsoport felépítse, tesztelje és üzembe helyezze azt. 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.

• méretezhető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.

Kihívások

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ási alkalmazások több mozgó részből állnak, mint az egyenértékű monolitikus alkalmazás. Minden szolgáltatás egyszerűbb, de a teljes rendszer ö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áshatárok átszervezése nehéz 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 létrehozásának decentralizált megközelítése előnyökkel jár, de problémákhoz is vezethet. Előfordulhat, hogy olyan sok különböző nyelv és keretrendszer lesz a végén, hogy az alkalmazás nehezen tartható fenn. Hasznos lehet néhány projektszintű szabványt létrehozni anélkül, hogy túlságosan korlátozná a csapatok rugalmasságát. 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. Sok apró, részletes szolgáltatás használata több szolgáltatásközi 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. Minden mikroszolgáltatás felelős a saját adatmegőrzéséért. Ennek eredményeképpen több szolgáltatás adatkonzisztenciája kihívást jelenthet. A különböző szolgáltatások különböző időpontokban, különböző technológiákkal és potenciálisan különböző sikerességi szintekkel megőrzik az adatokat. Ha több mikroszolgáltatás is részt vesz az új vagy módosított dátum megőrzésében, nem valószínű, hogy a teljes adatmódosítás ACID-tranzakciónak tekinthető. Ehelyett a technika jobban igazodik a BASE-hez (alapvetően elérhető, soft state és végül konzisztens). Törekedj a végül következetesség elérésére, ahol lehetséges.

• Felügyelet. Ahhoz, hogy sikeresen használhassa a mikroszolgáltatásokat, fejlett DevOps-kultúra szükséges. A szolgáltatások közötti korrelált naplózás kihívást jelenthet. A naplózásnak általában több szolgáltatáshívást kell korrelálnia egyetlen felhasználói művelethez.

• verziózás. A szolgáltatás frissítései nem szakítják meg az attól 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 nagy mértékben elosztott rendszerek. Gondosan értékelje ki, hogy a csapat rendelkezik-e a sikerhez szükséges készségekkel és tapasztalattal.

Ajánlott eljárások

• Modellszolgáltatások az üzleti tartomány körül.

• Decentralizált mindent. Az egyes csapatok felelősek a szolgáltatások tervezéséért és kiépítéséért. Kerülje a kód vagy adatséma megosztását.

• Az adattárolásnak privátnak kell lennie az adatokat birtokelő szolgáltatás számára. Minden szolgáltatáshoz és adattípushoz használja a legjobb tárterületet.

• A szolgáltatások jól megtervezett API-kon keresztül kommunikálnak. Kerülje a megvalósítás részleteinek kiszivárgását. Az API-knak a tartományt kell modelleznie, nem pedig a szolgáltatás belső implementációját.

• Kerülje a szolgáltatások közötti összekapcsolást. Az összekapcsolás okai közé tartoznak a megosztott adatbázis-sémák és a merev kommunikációs protokollok.

• Ki kell kapcsolnia az átjáróra az olyan átfogó problémákat, mint a hitelesítés és az SSL-lezárás.

• Tartsa távol a tartományt az átjárótól. Az átjárónak az üzleti szabályok vagy a tartománylogika ismerete nélkül kell kezelnie és irányítania az ügyfélkéréseket. Ellenkező esetben az átjáró függőséggá válik, és összekapcsolást okozhat a szolgáltatások között.

• A szolgáltatásoknak laza összekapcsolásnak és magas funkcionális kohéziónak kell rendelkezniük. A valószínűleg együtt változó függvényeket együtt kell csomagolni és üzembe helyezni. Ha külön szolgáltatásokban találhatók, ezek a szolgáltatások szorosan össze vannak állítva, mivel az egyik szolgáltatás módosítása szükségessé teszi a másik szolgáltatás frissítését. A két szolgáltatás közötti túlcsevegés a szoros összekapcsolás és az alacsony kohézió tünete lehet.

• A hibák elkülönítése. A szolgáltatáson belüli hibák kaszkádolásának megakadályozása rugalmassági stratégiák használatával. Lásd a rugalmassági mintákat és a megbízható alkalmazások tervezését.

Következő lépések

A mikroszolgáltatás-architektúra Azure-beli kiépítésével kapcsolatos részletes útmutatásért lásd: Mikroszolgáltatások tervezése, létrehozása és üzemeltetése az Azure-ban.

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.

Előnyök

• Agilitás. Mivel a mikroszolgáltatások egymástól függetlenül vannak üzembe helyezve, könnyebben kezelhetők a hibajavítások és a funkciókiadások. 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. Sok hagyományos alkalmazásban, ha az alkalmazás egyik részében hiba található, az blokkolhatja 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 kicsinek kell lenniük ahhoz, hogy egyetlen szolgáltatáscsoport felépítse, tesztelje és üzembe helyezze azt. 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.

• méretezhető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.

Kihívások

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ási alkalmazások több mozgó részből állnak, mint az egyenértékű monolitikus alkalmazás. Minden szolgáltatás egyszerűbb, de a teljes rendszer ö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áshatárok átszervezése nehéz 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 létrehozásának decentralizált megközelítése előnyökkel jár, de problémákhoz is vezethet. Előfordulhat, hogy olyan sok különböző nyelv és keretrendszer lesz a végén, hogy az alkalmazás nehezen tartható fenn. Hasznos lehet néhány projektszintű szabványt létrehozni anélkül, hogy túlságosan korlátozná a csapatok rugalmasságát. 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. Sok apró, részletes szolgáltatás használata több szolgáltatásközi 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. Minden mikroszolgáltatás felelős a saját adatmegőrzéséért. Ennek eredményeképpen több szolgáltatás adatkonzisztenciája kihívást jelenthet. A különböző szolgáltatások különböző időpontokban, különböző technológiákkal és potenciálisan különböző sikerességi szintekkel megőrzik az adatokat. Ha több mikroszolgáltatás is részt vesz az új vagy módosított dátum megőrzésében, nem valószínű, hogy a teljes adatmódosítás ACID-tranzakciónak tekinthető. Ehelyett a technika jobban igazodik a BASE-hez (alapvetően elérhető, soft state és végül konzisztens). Törekedj a végül következetesség elérésére, ahol lehetséges.

• Felügyelet. Ahhoz, hogy sikeresen használhassa a mikroszolgáltatásokat, fejlett DevOps-kultúra szükséges. A szolgáltatások közötti korrelált naplózás kihívást jelenthet. A naplózásnak általában több szolgáltatáshívást kell korrelálnia egyetlen felhasználói művelethez.

• verziózás. A szolgáltatás frissítései nem szakítják meg az attól 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 nagy mértékben elosztott rendszerek. Gondosan értékelje ki, hogy a csapat rendelkezik-e a sikerhez szükséges készségekkel és tapasztalattal.

Ajánlott eljárások

• Modellszolgáltatások az üzleti tartomány körül.

• Decentralizált mindent. Az egyes csapatok felelősek a szolgáltatások tervezéséért és kiépítéséért. Kerülje a kód vagy adatséma megosztását.

• Az adattárolásnak privátnak kell lennie az adatokat birtokelő szolgáltatás számára. Minden szolgáltatáshoz és adattípushoz használja a legjobb tárterületet.

• A szolgáltatások jól megtervezett API-kon keresztül kommunikálnak. Kerülje a megvalósítás részleteinek kiszivárgását. Az API-knak a tartományt kell modelleznie, nem pedig a szolgáltatás belső implementációját.

• Kerülje a szolgáltatások közötti összekapcsolást. Az összekapcsolás okai közé tartoznak a megosztott adatbázis-sémák és a merev kommunikációs protokollok.

• Ki kell kapcsolnia az átjáróra az olyan átfogó problémákat, mint a hitelesítés és az SSL-lezárás.

• Tartsa távol a tartományt az átjárótól. Az átjárónak az üzleti szabályok vagy a tartománylogika ismerete nélkül kell kezelnie és irányítania az ügyfélkéréseket. Ellenkező esetben az átjáró függőséggá válik, és összekapcsolást okozhat a szolgáltatások között.

• A szolgáltatásoknak laza összekapcsolásnak és magas funkcionális kohéziónak kell rendelkezniük. A valószínűleg együtt változó függvényeket együtt kell csomagolni és üzembe helyezni. Ha külön szolgáltatásokban találhatók, ezek a szolgáltatások szorosan össze vannak állítva, mivel az egyik szolgáltatás módosítása szükségessé teszi a másik szolgáltatás frissítését. A két szolgáltatás közötti túlcsevegés a szoros összekapcsolás és az alacsony kohézió tünete lehet.

• A hibák elkülönítése. A szolgáltatáson belüli hibák kaszkádolásának megakadályozása rugalmassági stratégiák használatával. Lásd a rugalmassági mintákat és a megbízható alkalmazások tervezését.

Következő lépések

A mikroszolgáltatás-architektúra Azure-beli kiépítésével kapcsolatos részletes útmutatásért lásd: Mikroszolgáltatások tervezése, létrehozása és üzemeltetése az Azure-ban.