Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
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. A sikeres mikroszolgáltatás-architektúra létrehozásához alapvető szemléletváltásra van szükség. Ez túlmutat azon, hogy az alkalmazásokat kisebb szolgáltatásokba bontsa. Át kell gondolnia a rendszerek tervezésének, üzembe helyezésének és üzemeltetésének módját is.
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 kis, független és lazán összekapcsolt összetevők, amelyeket egyetlen kis fejlesztői csapat írhat és tart fenn. Minden szolgáltatás külön kódbázisként van kezelve, amely lehetővé teszi, hogy egy kis csapat hatékonyan kezelje azt. Mivel a szolgáltatások egymástól függetlenül telepíthetők, a csapatok a teljes alkalmazás újraépítése vagy ismételt üzembe helyezése nélkül frissíthetik a meglévő szolgáltatásokat. A központi adatréteggel rendelkező hagyományos modellekkel ellentétben a mikroszolgáltatások felelősek saját adataik vagy külső állapotuk megőrzéséért. Jól definiált API-kon keresztül kommunikálnak, amelyek elrejtik a belső implementációkat más szolgáltatások elől. Ez az architektúra támogatja a többplatformos programozást is, ami azt jelenti, hogy a szolgáltatásoknak nem kell ugyanazt a technológiai vermet, kódtárat vagy keretrendszert megosztaniuk.
Összetevők
A szolgáltatásokon kívül más összetevők is megjelennek egy tipikus mikroszolgáltatás-architektúrában:
Felügyelet vagy vezénylés: Ez a felügyeleti összetevő kezeli a mikroszolgáltatások vezénylését. Szolgáltatásokat ütemez és helyez üzembe a csomópontokon, észleli a hibákat, helyreállítja a hibákat, és lehetővé teszi az igény szerinti automatikus skálázást. Ezt a funkciót általában egy olyan tárolóvezénylési platform biztosítja, mint a Kubernetes. Natív felhőkörnyezetekben az olyan megoldások, mint az Azure Container Apps, felügyelt vezénylést és beépített skálázást biztosítanak. Ezek az eszközök csökkentik az üzembe helyezés összetettségét és a működési többletterhelést.
API-átjáró: Az API-átjáró az ügyfelek belépési pontjaként szolgál. Az ügyfelek a szolgáltatások közvetlen hívása helyett kéréseket küldenek az API-átjárónak. Az átjáró továbbítja ezeket a kéréseket a megfelelő háttérszolgáltatásoknak. Emellett kezeli az olyan horizontális szempontokat is, mint a hitelesítés, a naplózás és a terheléselosztás. A natív felhőbeli mikroszolgáltatás-architektúrákban az olyan egyszerűsített szolgáltatás-proxyk, mint az Envoy és az Nginx, támogatják a belső szolgáltatásközi kommunikációt. Az ilyen típusú belső forgalom, más néven kelet-nyugati forgalom fejlett útválasztást és forgalomvezérlést tesz lehetővé.
Üzenetorientált köztes szoftver: Az olyan üzenetkezelési platformok, mint az Apache Kafka és az Azure Service Bus, lehetővé teszik az aszinkron kommunikációt a mikroszolgáltatásokban a laza összekapcsolás és a magas skálázhatóság támogatásával. Ezek alkotják az eseményvezérelt architektúrák alapjait. Ez a megközelítés lehetővé teszi, hogy a szolgáltatások valós időben reagáljanak az eseményekre, és aszinkron üzenetküldésen keresztül kommunikáljanak.
Megfigyelhetőség: A hatékony megfigyelhetőségi stratégia segít a csapatoknak a rendszer megbízhatóságának fenntartásában és a problémák gyors megoldásában. A központosított naplózás összehozza a naplókat a könnyebb diagnosztikához. A valós idejű monitorozás alkalmazásteljesítmény-monitorozási ügynökökkel és olyan keretrendszerekkel, mint az OpenTelemetria, betekintést nyújt a rendszer állapotába és teljesítményébe. Az elosztott nyomkövetés nyomon követi a kéréseket a szolgáltatáshatárok között. Segít a csapatoknak a szűk keresztmetszetek megtalálásában és a teljesítmény javításában.
Adatkezelés: A jól megtervezett adatbázisarchitektúra támogatja az önállóságot és a méretezhetőséget. A mikroszolgáltatások gyakran többplatformos adatmegőrzést használnak különböző adatbázistípusok, például az SQL vagy a NoSQL kiválasztásával az egyes szolgáltatások egyedi igényei alapján. Ez a megközelítés igazodik a tartományalapú tervezéshez (DDD) és a határolt környezet elképzeléséhez. Minden szolgáltatás a saját adataival és sémájával rendelkezik. Ez a tulajdonjog csökkenti a szolgáltatásközi függőségeket, és lehetővé teszi, hogy a szolgáltatások egymástól függetlenül fejlődjenek. Ez a decentralizált modell javítja a rugalmasságot, a teljesítményt és a rendszer rugalmasságát.
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 teljes alkalmazás ismételt üzembe helyezése nélkül frissíthet egy szolgáltatást, és visszaállíthatja a frissítést, ha valami hiba történik. Sok hagyományos alkalmazásban, ha hibát talál az alkalmazás egyik részében, az blokkolhatja a teljes kiadási folyamatot. Például egy hiba lelassíthatja az új funkciók bevezetését, ha hibajavítást kell integrálnia, tesztelnie és közzétennie.
Kicsi, koncentrált 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 csapatok általában kevésbé hatékonyak, mert a kommunikáció lassabb, a felügyeleti többletterhelés nő, és az agilitás csökken.
Kis kódbázis: Monolitikus alkalmazásokban a kódfüggőségek gyakran idővel keverednek. Egy új funkció hozzáadásához a kódbázis számos részén szükség lehet módosításokra. A mikroszolgáltatás-architektúra elkerüli ezt a problémát azáltal, hogy nem osztja meg a kódot vagy az adattárakat. Ez a megközelítés minimalizálja a függőségeket, és megkönnyíti az új funkciók bevezetését.
Technológiák keveréke: A csapatok különböző technológiai veremeket használhatnak, hogy kiválaszthassák az általuk nyújtott szolgáltatáshoz legjobban illő technológiát.
Hibaelkülönítés: 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. 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. Ez a módszer lehetővé teszi az olyan alrendszerek horizontális felskálázását, amelyek több erőforrást igényelnek a teljes alkalmazás horizontális felskálázása nélkül. A Kuberneteshez hasonló vezénylővel nagyobb szolgáltatási sűrűséget adhat hozzá egyetlen gazdagéphez, ami hatékonyabb erőforrás-használatot tesz lehetővé.
Adatelkülönítés: A séma frissítése egyszerűbb a mikroszolgáltatás-architektúrában, mert csak egy mikroszolgáltatást érint. Ezzel szemben a monolitikus alkalmazások bonyolíthatják a sémamódosításokat, mivel több összetevő gyakran ugyanazokkal az adatokkal kommunikál. Ez a megosztott hozzáférés potenciálisan kockázatossá teszi a módosításokat.
Kihívások
A mikroszolgáltatások előnyei kompromisszumokkal járnak. A mikroszolgáltatás-architektúra létrehozása előtt vegye figyelembe az alábbi kihívásokat:
Bonyolultsá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. Győződjön meg arról, hogy az alkalmazás tervezésekor figyelembe veszi az olyan kihívásokat, mint a szolgáltatásfelderítés, az adatkonzisztencia, a tranzakciókezelés és a szolgáltatásközi kommunikáció.
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ök nem mindig vannak tervezve a szolgáltatásfüggőségekkel való kompatibilitásra. 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ákat is okozhat. 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 a módszer különösen a többirányú funkciókra, például a naplózásra vonatkozik.
Hálózati torlódás és késés: Sok apró, részletes szolgáltatás használata több szolgáltatásközi kommunikációt eredményezhet. Továbbá, ha a szolgáltatásfüggőségek lánca túl hosszú lesz (az A szolgáltatás B-t hív, amely C-t hív...), a további késés problémát okozhat. Gondosan kell megterveznie az API-kat. Kerülje a túlzottan beszédes API-kat, gondolja át a szerializációs formátumokat, és keressen olyan helyeket, ahol aszinkron kommunikációs mintákat használhat, például a Queue-Based Terhelés simítási mintáját.
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 adatok megőrzésében, nem valószínű, hogy a teljes adatváltozás atomi, konzisztens, izolált és tartós (ACID) tranzakciónak tekinthető. Ehelyett a technika jobban igazodik az alapvetően elérhető, lágy állapotú, végső konzisztenciájú (BASE) modellhez. Törekedj a végül következetesség elérésére, ahol lehetséges.
Menedzsment: A sikeres mikroszolgáltatás-architektúra érett DevOps-kultúrát igényel. 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ószámozá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épességkészlet: 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. A DDD használatával azonosíthatja a kötött környezeteket, és egyértelmű szolgáltatáshatárokat határozhat meg. Kerülje a túlságosan részletes szolgáltatások létrehozását, amelyek növelhetik az összetettség és a teljesítmény csökkenését.
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.
Szabványosítsa a technológiai lehetőségeket a használt nyelvek és keretrendszerek számának korlátozásával. Platformszintű szabványok létrehozása naplózásra, monitorozásra és üzembe helyezésre.
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.
A biztonság növelése a kölcsönös Transport Layer Security (mTLS) használatával a szolgáltatásközi titkosításhoz. Szerepköralapú hozzáférés-vezérlés implementálása és API-átjárók használata a szabályzatok kikényszerítéséhez.
Kiszervezés keresztvágási problémák, például a hitelesítés és a Secure Sockets Layer leállítása az átjáróhoz. A Szolgáltatáshálók és a Dapr-keretrendszerek is segíthetnek az olyan gyakori keresztvágási problémáknál, mint az mTLS-hitelesítés és a rugalmasság.
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 a másik szolgáltatás frissítését igényli. A két szolgáltatás közötti túlzottan beszédes kommunikáció a szoros összekapcsolás és az alacsony kohézió tünete lehet.
A tesztelés és az üzembe helyezés automatizálásához használjon folyamatos integrációs és folyamatos üzembehelyezési (CI/CD) folyamatokat. A szolgáltatások önálló üzembe helyezése és a bevezetés állapotának monitorozása.
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. További információ: Rugalmassági minták és Megbízható alkalmazások tervezése.
A chaos engineering használatával tesztelheti a mikroszolgáltatás-architektúra rugalmasságát és függőségeit. Értékelje ki és javítsa, hogyan kezeli a rendszer a részleges hibákat.
Központosított naplózás, elosztott nyomkövetés (OpenTelemetria) és metrikák gyűjteményének implementálása a megfigyelhetőség biztosítása érdekében.
Antiminták a mikroszolgáltatásokhoz
Mikroszolgáltatások tervezésekor és megvalósításakor gyakran előfordulnak olyan buktatók, amelyek alááshatják ennek az architekturális stílusnak az előnyeit. Ezeknek az antipatterneknek a felismerése segít a csapatoknak elkerülni a költséges hibákat, és rugalmasabb, karbantarthatóbb rendszereket létrehozni. Kerülje a következő antipatterneket:
Ha a mikroszolgáltatásokat az üzleti tartomány alapos ismerete nélkül valósítja meg, az rosszul igazított szolgáltatáshatárokat eredményez, és aláássa a kívánt előnyöket.
A múltbeli vagy jövőbeli eseményektől függő események tervezése sérti az atomi és az önálló üzenetküldés elvét. Ez a függőség kényszeríti a fogyasztókat a várakozásra, és csökkenti a rendszer megbízhatóságát.
Az adatbázis-entitások eseményekként való használata belső szolgáltatásadatokat tesz elérhetővé, és gyakran nem adja meg a megfelelő üzleti szándékot, ami szorosan összekapcsolt és nem egyértelmű integrációhoz vezet.
Az adatduplikációk elkerülése minden áron antiminta. A minták, például a materializált nézetek használata a helyi példányok fenntartásához javítja a szolgáltatás önállóságát, és csökkenti a szolgáltatásközi függőségeket.
Az általános események használata kényszeríti a felhasználókat az üzenetek értelmezésére és szűrésére. Ez a megközelítés szükségtelen összetettséget eredményez, és csökkenti az eseményvezérelt kommunikáció egyértelműségét.
A közös kódtárak vagy függőségek mikroszolgáltatások közötti megosztása szoros kapcsolatot hoz létre, ami kockázatossá és széles körben elterjedté teszi a módosításokat, és ellentétes az önálló szolgáltatások elvével.
A mikroszolgáltatások fogyasztóknak való közvetlen felfedése szoros összekapcsolási, méretezhetőségi problémákat és biztonsági kockázatokat eredményez. Az API-átjárók használata tiszta, kezelhető és biztonságos belépési pontot biztosít.
A konfigurációs értékek mikroszolgáltatásokon belüli megőrzése szorosan összekapcsolja őket egy adott környezettel, ami megnehezíti az üzembe helyezést. A konfiguráció külsővé tétele azonban elősegíti a rugalmasságot és a környezet hordozhatóságát.
Az olyan biztonsági logika beágyazása, mint a jogkivonat-ellenőrzés közvetlenül a mikroszolgáltatásokban bonyolítja a kódjukat és a karbantartásukat. A biztonság dedikált összetevőkre való kiszervezésével a szolgáltatások összpontosítottabbak és áttekinthetőbbek lesznek.
A közös mikroszolgáltatási feladatok absztrahálásának elmulasztása ismétlődő, hibalehetőséggel járó kódot eredményez, és korlátozza a rugalmasságot. Alternatív megoldásként az olyan absztrakciós keretrendszerek használata, mint a Dapr, leegyszerűsíti a fejlesztést azáltal, hogy leválasztja az üzleti logikát az infrastruktúra problémáiról.
Mikroszolgáltatás-architektúra létrehozása
Az alábbi cikkek egy mikroszolgáltatási architektúra tervezésének, felépítésének és üzemeltetésének strukturált megközelítését ismertetik.
Használjon tartományelemzést: A mikroszolgáltatások tervezésekor előforduló gyakori buktatók elkerülése érdekében használja a tartományelemzést a mikroszolgáltatások határainak meghatározásához. Hajtsa végre a következő lépéseket:
- 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 decentralizált és agilis megközelítést igényelnek az alkalmazások tervezéséhez és létrehozásához. További információ: Mikroszolgáltatás-architektúra tervezése.
Működés éles környezetben: Mivel a mikroszolgáltatás-architektúrák elosztottak, az üzembe helyezéshez és a monitorozáshoz robusztus műveleteket kell végeznie.