Az 1960-as és 1970-es években monolitikus architektúra kedveltek az alkalmazások fejlesztéséhez a korlátozott számítási erőforrások miatt, amelyek az összes funkcionalitást egyetlen, koherens egységbe szükségessé tették.
Ez addig tartott, amíg a késő 1990-es és 2000-es évek nem érkeztek meg, amikor a monolitikus szerkezet túl korlátolódni kezdett az alkalmazások folyamatosan növekvő mérete és összetettsége miatt, különösen az internet és az elosztott rendszerek felemelkedésével.
Ez modulárisabb megközelítések fejlesztéséhez vezetett, például szolgáltatás-orientált architektúrák (SOA) és, később, mikro szolgáltatások architektúra (MSA), amely a 2010-es évek elején vált dominánssá.
Ez csupán egy rövid bevezetés a mikroszolgáltatások alapfogalmaihoz és használatához. Beszéljünk arról, hogyan váltottak fel a mikroszolgáltatások az egymonolit architektúrát, hogyan működnek, és néhány konkrét példát nézünk meg. Utána kitérünk a mikroszolgáltatások telepítésének fő szempontjaira és arra, mit kell tenni, ha mikroszolgáltatásokat szeretnél telepíteni.
Mik azok a mikroszolgáltatások? Hogyan működnek?
Mint már említettem, a mikroszolgáltatások válaszként jelentek meg a növekvő alkalmazásbonyolultság és méret kezelésére. Lehetővé tették a vállalatok számára, hogy a funkciókat függetlenül telepíthető szolgáltatásokra bontják.
A "mikroszolgáltatások" kifejezést olyan ipari szakértők, mint Martin Fowler és James Lewis terjesztették el. 2014-ben egy blogbejegyzésben formálisan bevezették és definiálták az alapelveket és jellemzőket, beleértve a függetlenül telepíthető szolgáltatásokat, a decentralizált adatkezelést és a technológiai semlegességet.
Azóta a mikroszolgáltatások főáramú építészeti megoldássá váltak, támogatva az containerizációs technológiák, mint a Docker, az olyan oresztrációs eszközök mint az Kubernetes és a szerver nélküli számítási platformok fejlődésével. De hogyan működnek a mikroszolgáltatások?
Hogyan működnek a mikroszolgáltatások?
A mikroszolgáltatások architektúra magja egy nagy alkalmazást kisebb, elkülönült szolgáltatásokra bont, amelyek közül mindegyik egy adott üzleti funkcióért felelős. Ezek a szolgáltatások hálózaton keresztül kommunikálnak egymással, gyakran REST APIs, gRPC vagy üzenetközvetítők, például az RabbitMQ vagy az Apache Kafka segítségével.
Martin Fowler és James Lewis meghatározása szerint a mikroszolgáltatásoknak négy fő jellemzője van:
- Egyetlen felelősség: Minden mikroszolgáltatás egy adott feladatra vagy funkcióra van tervezve, ami lehetővé teszi a specializációt és csökkenti a bonyolultságot.
- Függetlenség: A mikroszolgáltatások egymástól függetlenül fejleszthetők, telepíthetők és skálázhatók, ami rugalmasságot és rugalmasságot biztosít.
- Decentralizált adatkezelés: A mikroszolgáltatások gyakran saját adatbázissal rendelkeznek, ami kiküszöböli az egyetlen központi adatbázis szükségességét.
- Technológiai semlegesség: A csapatok szabadon választhatják az egyes szolgáltatásokhoz legmegfelelőbb technológiát, nem kötve a többi szolgáltatás választásaihoz.
Ez a megközelítés ellentétben áll a hagyományos egymonolit architektúrával, amelyben minden alkalmazáskomponens szorosan integrálódik egyetlen, koherens egységbe.
Mikroszolgáltatások telepítésének fő szakaszai
Bár a mikroszolgáltatások architektúrája számos előnnyel jár, például nagy skálázhatóság, rugalmasság, hatékonyság, hiba-elszigetelés, stb., megköveteli, hogy tudj a mikroszolgáltatások hatékony telepítéséről, és jó mennyiségű tervezésre van szükség ahhoz, hogy sikeres legyen.
Ezért nélkülözhetetlen, hogy átfogó ismereted legyen a mikroszolgáltatások telepítésének kulcsfogalmairól, szakaszairól és bevált gyakorlatairól, hogy sikeres mikroszolgáltatások architektúrát érj el. Hadd vizsgáljuk meg a mikroszolgáltatások telepítésének fő szakaszait és azt, mit jelent mindegyik.
A mikroszolgáltatások telepítésének megtervezése és előkészítése
Minden jó dolog tervezést és türelmet igényel. A mikroszolgáltatások sikeres telepítéséhez mindenképpen szükséged lesz jó tervezésre és türelemre. Ezért fontos, hogy követsd a mikroszolgáltatások bevált gyakorlatait, és alaposan megtervezz és előkészíts mindent, amit a telepítéshez szükségelsz.
Mint már említettem, a mikroszolgáltatások egyik kulcselve és jellemzője a Egyetlen Felelősség Elve. Ha hűséges vagy ehhez az elvhez, és biztosítod, hogy minden mikroszolgáltatás egy-egy funkcióra és képességre összpontosítson, a csapatod függetlenül fejlesztheti, telepítheti és skálázhatja a szolgáltatásokat.
Ezen felül ennek az elvnek az alcategóriája a lazán csatolt tervezési elv. Ez azt jelenti, hogy minden szolgáltatás függetlenül működhet kommunikáció szempontjából, és minimálisan függ más szolgáltatásoktól. Viszont ez lehetővé teszi, hogy az egyik szolgáltatás módosításai vagy frissítései ne érinthessék a többi szolgáltatást, lehetővé téve a mikroszolgáltatások független skálázását.
Ez csökkenti a kaszkádos meghibásodások kockázatát, ahol egy probléma vagy hiba a rendszer egyik részében láncreak ciót okoz, amely az egész rendszert meghibásodottá teszi és a teljes szolgáltatást leállítja.
Egy fontos mikroszolgáltatás-gyakorlat a dedikált adattárolás az egyes szolgáltatások számára a mikroszolgáltatások telepítésekor, a szabad csatolás tervének kiterjesztéseként, mivel ez megakadályozza az ütközéseket és jobb szolgáltatás-skálázhatóságot tesz lehetővé.
Ezen túl szükséged lesz aszinkron mikroszolgáltatások kommunikációs mintákra, mint az üzenetközvetítők, hogy biztosítsd, hogy minden szolgáltatás közvetlen függőségek nélkül kommunikáljon.
A kirakós utolsó darabja a mikroszolgáltatások Continuous Integration és Continuous Delivery (CI/CD) folyamatainak megvalósítása. Ezek a folyamatok lehetővé teszik a csapatoknak, hogy új funkciókat vagy javításokat helyezzenek üzembe a CI/CD eszközök mint az Jenkins és az GitLab, lehetővé téve a szervezeteknek, hogy megőrizzék a rendszer stabilitását, miközben gyakran bocsájtanak ki új képességeket.
Most, hogy átfogó képed van a mikroszolgáltatások telepítéséhez szükséges tervezésről és előkészítésről, beszéljünk a mikroszolgáltatások telepítési stratégiáiról.
Mikroszolgáltatások Telepítési Stratégiái
Mikroszolgáltatások telepítésekor az alkalmazott stratégia a szolgáltatás funkciójától, a forgalomtól, az infrastruktúra konfigurációjától, a csapat tapasztalataitól és a költségvetéstől függ. A legelterjedtebb mikroszolgáltatás-telepítési stratégiák a következők:
- Szolgáltatáspéldány Tárolóként: Ebben a megközelítésben minden mikroszolgáltatás a saját tárolójában fut, ami jobb elkülönítést biztosít, mint a több példány egy hoszt megközelítés. A tárolók könnyű skálázást és jobb erőforrás-elosztást tesznek lehetővé.
- Szolgáltatáspéldány virtuális gépenként: Minden szolgáltatás egy külön virtuális gépen (VM) fut, ami még nagyobb elkülönítést nyújt, mint a tárolók. Ez javítja a biztonságot és a stabilitást, de jellemzően nagyobb terhelést okoz.
- Fázisosan induló kiadások: Kezdetben a mikroszolgáltatás új verzióit egy kisebb felhasználói csoportnak telepítik, és tesztelják a stabilitásukat, mielőtt teljes körű indításra kerülne sor. Ez a megközelítés minimalizálja a hatást, ha problémák merülnek fel, és gyors visszaállítást tesz lehetővé a rendszer integritásának megóvásához.
- Kék-Zöld Telepítés: Ez a módszer két azonos termelési környezetet használ, ahol az egyik környezet az élő forgalmat szolgálja, a másik pedig a következő verzió tesztelésére használható. A kék-zöld telepítés könnyű visszaállítást és leállás nélküli frissítéseket tesz lehetővé, mivel a forgalom zökkenőmentesen váltható a két környezet között.
- Szakaszos Kiadások: Ez a stratégia fokozatosan vezeti be a frissítéseket különböző felhasználói szegmenseknek vagy környezeteknek. Általában belső környezetből indul, majd érkezik az éles rendszerre, így korlátozza a potenciális problémák hatókörét, és lehetővé teszi a csapatnak a problémák fokozatos kezelését.
- Kiszolgálómentes telepítés: Ez a megközelítés kiszolgáló nélküli platformokat használ, mint az AWS Fargate és az Google Cloud Run, amelyek automatizálják az infrastruktúra-kezelést a skálázás és az erőforrás-elosztás kezelésével. A kiszolgáló nélküli telepítésnél nem kell kezelni az alapul szolgáló szervereket, így az alkalmazottaknak csak a mikroszolgáltatásokra kell koncentrálniuk.
Miután kiválasztottad az egyik fenti mikroszolgáltatás-telepítési stratégiát, szükséged lesz egy mikroszolgáltatás-vezénylési eszközre.
Mikroszolgáltatások Orkestrációja
A telepítési stratégia kiválasztása után szükséged lesz egy mikroszolgáltatás-vezénylő megoldásra. Az olyan mikroszolgáltatás-vezénylési eszközök, mint az Kubernetes, automatizálják a mikroszolgáltatások telepítését, skálázását, monitorozását és a tárolóban futó mikroszolgáltatások kezelését.
Az Airbnb például az Kubernetes-t használja, amely lehetővé teszi mérnökeinek, hogy több száz változtatást telepítsenek mikroszolgáltatásaikba automatikus felügyelet nélkül. Az olyan mikroszolgáltatás-vezénylési eszközök egyik fontos jellemzője az Kubernetes beépített terheléselosztása.
Az egyensúlyozott terheléselosztás segít az érkező forgalmat a mikroszolgáltatás több példánya között elosztani. Ez megakadályozza, hogy egyetlen példány szűk keresztmetszetté váljon, és javítja a rendszer képességét a forgalmi csúcsok kezelésében.
Az Kubernetes jelentős szerepet játszik a mikroszolgáltatások kezelésében az öngyógyulási képességei révén, ahol a sikertelen tárolók automatikusan helyettesítésre és újraindításra kerülnek. A New York Times kihasználja ezt a funkciót mikroszolgáltatásainak karbantartására anélkül, hogy ez befolyásolná a felhasználói élményt vagy leállásokat okozna.
Ezen kívül az Kubernetes javítja a mikroszolgáltatások biztonságát is azáltal, hogy konfigurációkat és titkokat, például adatbázis-hitelesítési adatokat vagy API kulcsokat kezel a ConfigMaps és Secrets segítségével. Ez különösen fontos az olyan vállalatok és szolgáltatások számára, mint az Uber, amelyek érzékeny ügyfél- és felhasználói információkat kezelnek.
Végül az olyan mikroszolgáltatás-vezénylési eszközök, mint az Kubernetes, különösen előnyösek azoknál a mikroszolgáltatás-stratégiáknál, amelyek fokozatos frissítéseket és visszaállításokat tartalmaznak, mint a szakaszos kiadások. A fokozatos frissítések lehetővé teszik az új mikroszolgáltatás-verziók telepítését szolgáltatás-megszakítás nélkül azáltal, hogy a régi verzió néhány példánya továbbra is fut.
Miután beállítottad a mikroszolgáltatás-vezénylő eszközt, szükséged lesz felépíteni és automatizálni a CI/CD folyamatok mikroszolgáltatások telepítéséhez.
CI/CD Pipelines a mikroszolgáltatások telepítéséhez
Amint korábban már tárgyaltuk, a Continuous Integration és Continuous Delivery pipeline-ok a mikroszolgáltatások fontos aspektusai az mikroszolgáltatások telepítésében. A CI/CD pipeline-okban lévő CD pipeline-ok felelősek a kódváltozások automatikus üzembe helyezéséért az éles környezetbe, amint azok átmennek a CI/CD pipeline tesztelési és integrációs szakaszain.
Ezt követően a CI/CD pipeline-ok CD része lép működésbe, így amikor a kódmódosítások átmennek a tesztelési és integrációs fázisokon, a szolgáltatás egy mikroszolgáltatás-orkestrációs eszközre, például egy Kubernetes clusterre kerül telepítésre.
Továbbá a tesztelési és integrációs szakaszok mindegyike automatikusan a CI/CD pipelines által történik, mivel az egység tesztek, integrációs tesztek és end-to-end tesztek beépítésre kerülnek a pipeline-ba.
Ez lehetővé teszi, hogy a csapatok minden szakaszban validálják a frissítéseket a rendszer stabilitásának megőrzése mellett. Ráadásul ha a kód módosításaival kapcsolatban problémák merülnek fel, az automatikus visszaállítások visszaálítják az előző stabil verziót.
Végül a CI/CD pipelines mikroszolgáltatások számára történő megvalósítása a mikroszolgáltatások bevált gyakorlatai szerint segít a szervezeteknek a gyorsabb fejlesztés elérésében, a manuális hibák csökkentésében és a magas minőségi szabványok fenntartásában.
Sok vállalat, mint például a Spotify, Expedia, iRobot, Lufthansa, Pandora és mások, CI/CD pipeline-okat használ a mikroszolgáltatások számára olyan CI/CD eszközökön keresztül, mint a CircleCI, AWS CodePipeline és GitLab, hogy automatizálja a telepítési folyamatokat, biztosítsa a konzisztens kódminőséget, és gyorsan szállítson új funkciókat, miközben fenntartja a rendszer stabilitását.
Mikroszolgáltatások Kommunikációs Mintái
A mikroszolgáltatások közötti kommunikáció teljes mértékben a funkciótól, az általános architektúrától, a kívánt skálázhatóságtól és a mikroszolgáltatások megbízhatóságától függ. Általában két fő típusú mikroszolgáltatás-kommunikációs minta használatos: szinkron és aszinkron mikroszolgáltatások közötti kommunikációs minták.
A szinkron mikroszolgáltatás-kommunikációs mintákban a szolgáltatások valós időben kommunikálnak, ami azt jelenti, hogy egy szolgáltatás küld egy kérést és vár a választra, mielőtt továbbmenne. A leggyakrabban használt szinkron mikroszolgáltatás-kommunikációs minták a REST (Representational State Transfer) API-k, gRPC (Google Távoli Eljáráshívás), és GraphQL.
Ezt a fajta mikroszolgáltatás-kommunikációs mintákat olyan iparágak és vállalatok használják, amelyek valós idejű adatfeldolgozást és azonnali válaszadást igényelnek. Az olyan iparágak, mint a pénzügyek, az egészségügy és az e-kereskedelem gyakran szinkron kommunikációs mintákat használnak, hogy biztosítsák a tranzakciók, adatlekérdezések és interakciók azonnali végbemenetelét, ezzel fenntartva a sima és reszponzív felhasználói élményt.
Azt viszont megjegyezhetjük, hogy bár a szinkron mikroszolgáltatás-kommunikációs minták előnyöket nyújtanak, mint a valós idejű válaszok és az egyszerűség, bizonyos hátrányaik is vannak, például a szoros csatolás által okozott szűk keresztmetszetek, alacsony skálázhatóság nagy terhelés alatt, lassú válaszidők és magas latenicia nagy forgalom esetén.
A szinkron kommunikációval szemben az aszinkron mikroszolgáltatás-kommunikációs minták általában jobban megfelelnek a mikroszolgáltatások számára, mivel a korábbi felsorolt Laza csatolás elvén alapulnak.
Ez a fajta mikroszolgáltatás-kommunikációs minta szétválasztja a szolgáltatásokat azáltal, hogy lehetővé teszi számukra az üzenetek küldését és fogadását egy közvetítőn keresztül, mint a Kafka vagy az RabbitMQ. Azáltal, hogy üzeneteket küldenek egy pufferként működő sorba, a szolgáltatások egymástól függetlenül kommunikálnak ahelyett, hogy várnának a választra, ahogy ezt a szinkron kommunikációban tennék. Ez a puffer lehetővé teszi, hogy más szolgáltatások a saját tempójukban feldolgozzák az üzeneteket, így a küldő folytathatja munkáját anélkül, hogy a fogadóra várnának.
Az aszinkron mikroszolgáltatás-kommunikációs minta nemcsak a mikroszolgáltatások telepítéséhez nyújt szétválasztott szerkezetet, hanem ugyanolyan valós idejű válaszadást nyújt, mint a szinkron mikroszolgáltatás-kommunikációs minták.
Ez az aszinkron eseményvezérelt mikroszolgáltatás-kommunikációs minták eseményvezérelt architektúrájának köszönhető, mivel a szolgáltatások az eseményeket bocsátanak ki, amikor egy adott cselekmény bekövetkezik. Más szolgáltatások feliratkozhatnak ezekre az eseményekre és ennek megfelelően reagálhatnak. Ez nagyon reszponzív rendszereket tesz lehetővé, amelyek valós időben reagálnak a változásokra a szolgáltatások közötti közvetlen csatolás nélkül.
Továbbá, az aszinkron Közzététel-Feliratkozás (Pub/Sub) A mikroszolgáltatások kommunikációs mintázatában a szolgáltatások (közzétevők) üzeneteket küldenek egy témakörre, és más szolgáltatások (feliratkozók) figyelik ezt a témakört a frissítések fogadásához. Ez a modell több feliratkozót támogat, és egyszerre több szolgáltatásba sugározza az üzeneteket.
Végül, az eseményvezérelt mintákhoz hasonlóan, az aszinkron koreográfiaalapú saga A mikroszolgáltatások kommunikációs mintázatai eseményeket is használnak a kommunikációhoz; azonban ebben a mintázatban egy meghatározott sorrend érvényes, ami azt jelenti, hogy az események kiváltják a következő lépést és egy adott szolgáltatás aktiválódik.
A különbség az, hogy az eseményvezérelt mintázatokban nincs meghatározott sorrend vagy munkafolyamat, és több szolgáltatás is reagálhat egy eseményre, nem pedig a koreográfia-alapú saga mintázat specifikus folyamata és sorrendje szerint.
Hogy milyen aszinkron mikroszolgáltatás-kommunikációs mintázatot használsz, attól függ a feladat és a mikroszolgáltatások általános funkciója. Az üzenetsorok, mint az Amazon SQS, jellemzően feladatütemezéshez, terheléselosztáshoz és e-kereskedelemhez használatosak rendelések feldolgozásához és értesítési rendszerekhez.
Az eseményvezérelt üzenetközvetítők, mint a Kafka és az EventBridge, jellemzően nagy mennyiségű eseményfolyamok valós idejű feldolgozásához és eseményirányításához használatosak a mikroszolgáltatások között olyan területeken, mint a pénzügyi szolgáltatások és hasonló környezetek.
Ami a Publish-Subscribe (Pub/Sub) üzenettovábbítókat illeti, mint a Google Cloud Pub/Sub és a Redis Streams, ezeket az üzenettovábbítókat általában skálázható üzenetküldésre használják az elosztott rendszerek között valós idejű analitikához és eseménybetöltéshez, valamint valós idejű értesítésekhez és csevegőalkalmazásokhoz.
Végül a koreográfia-alapú saga üzenetközvetítők főként e-kereskedelmi rendelésfelszolgáltatáshoz, utazásfoglalási rendszerekhez és olyan esetekhöz használatosak, ahol összetett, többlépéses tranzakciókra van szükség a koordináció több szolgáltatás között központi vezérlés nélkül.
Mikroszolgáltatás Szolgáltatásfelderítés
Miután beállítottad és implementáltad az igényeidnek megfelelő kommunikációs mintázatot, biztosítanod kell, hogy a szolgáltatások elsősorban meg tudják találni egymást. Ahogy már említettem, a mikroszolgáltatások orkesztráló eszközei fontos szerepet játszanak a mikroszolgáltatások felderítésében.
Ezt a beépített szolgáltatásfelderítésen keresztül valósítják meg, amely dinamikusan frissíti az IP-címeket és rekordokat, ahogy a szolgáltatások méretezkednek vagy helyet változtatnak a fürtben.
A mikroszolgáltatások felderítésének ezt a módszerét szerver oldali felderítésnek nevezik, mivel az útválasztási felelősség egy terheléselosztóra van delegálva, amely ekkor lekérdezi a regisztert és a forgalmat a megfelelő példányhoz irányítja.
Másfelől azonban van az ügyfél oldali felderítési módszer is a mikroszolgáltatások felderítéséhez, ahol a szolgáltatás vagy az API-átjáró egy szolgáltatásregisztert, például a Consultot vagy az Eurekát kérdezi le az elérhető példányok megtalálásához.
Hogy melyik felderítési módszer a legjobb a mikroszolgáltatások telepítéséhez, attól függ a rendszer igényeitől és skáláitól.
Az ügyfél oldali mikroszolgáltatás-felderítés esetén az ügyfél teljes kontrollt gyakorol azon, hogy melyik példánnyal kommunikál. Ez nemcsak több testreszabást tesz lehetővé, hanem csökkenti az összetettséget is, mivel nincs szükség központi felderítési szolgáltatásra.
Például a Netflix mikroszolgáltatás-telepítése ügyfél oldali mikroszolgáltatás-felderítést használ az Eureka és a Ribbon terheléselosztóval, amely lehetővé teszi az ügyfélnek, hogy a legjobb példányt válassza a késleltetés és szervermegterhelés alapján.
A szerver oldali mikroszolgáltatás-felderítés azonban jobban alkalmas nagyobb környezetekre, mivel egy központi szolgáltatásfelderítés javíthatja a hatékonyságot és lehetővé teszi az egységes terheléselosztást egy elosztott rendszerben.
A szerver oldali mikroszolgáltatás-felderítési megoldások, mint az Elastic Load Balancing és az API-átjárók (Kong stb.), hatékonyan irányítják a forgalmat, fenntartják a magas rendelkezésre állást, és olyan cégek használják őket, mint az Airbnb, a Pinterest, az Expedia és a Lyft.
Mikroszolgáltatás Biztonság
Bár a monolitikus architektúra általában rosszabb, mint az MSA, egyik aspektusban a monolitikus architektúrának volt előnye: a biztonság. Mivel a mikroszolgáltatások a Loose Coupling elven épülnek és elosztott jellegűek, egyetlen, általános biztonsági intézkedés nem implementálható.
Mivel minden szolgáltatást egymástól függetlenül kell védelemmel ellátni, további biztonsági intézkedések szükségesek, mivel a támadási felület sokkal nagyobb a mikroszolgáltatások esetében. Erre a célra az olyan szabványok, mint az OAuth 2.0 és a JWT-k (JSON Web Tokens) gyakran használatosak a hitelesítéshez és az engedélyezéshez.
Ezenkívül az API-átjáró is gyakran alkalmazott a biztonság kezelésére a mikroszolgáltatások között, mivel az hitelesítést és engedélyezést érvényesít a belépési pontban. Az API-átjárók ráadásul implementálhatnak sebességkorlátozást, naplózást és monitorozást is, amelyek további biztonsági rétegeket biztosítanak.
Bár ezek a fő belépési pontot védelemmel ellátják, további mikroszolgáltatás-biztonsági intézkedésekre van szükség a szolgáltatások közötti kommunikáció lefedéséhez.
Ebben az esetben a service meshek kerülnek képbe, mivel hozzáadnak egy hálózati biztonsági réteget a mikroszolgáltatásokhoz, titkosítják a szolgáltatások közötti forgalmat, és olyan házirendeket érvényesítenek, mint a kölcsönös TLS. Ezek a service meshek alapvetően végpontok közötti titkosítás átfogó rendszerét állítják be, amely jelentősen javítja a mikroszolgáltatások biztonságát.
Mikroszolgáltatás Méretezés
Az MSA egyik legnagyobb előnye, és az oka annak, hogy a monolitikus architektúrát helyettesítendő fejlesztették ki, annak magas skalázhatósága. A mikroszolgáltatások skalázása általában kétféleképpen történhet: vertikálisan és horizontálisan.
A vertikális mikroszolgáltatás-skalázás (vertikális skálázás) alapvetően több erőforrás, például CPU vagy memória hozzáadása egy meglévő példányhoz. Alternatívaként a horizontális mikroszolgáltatás-skalázás (horizontális skálázás) elosztja a terhelést és megnöveli a kapacitást.
A megvalósítás szempontjából a vertikális mikroszolgáltatás-skalázás az egyszerűbb a kettő közül, mivel csak módosítanod kell egy példányt egy nagyobb szerverre való frissítéssel, a memória vagy feldolgozási teljesítmény növelésével egy felhőpéldányban, vagy további tárolóhely hozzáadásával.
Ez a skalázási típus jellemzően olyan esetekben használatos, amikor a CPU- vagy memóriateljesítmény növelése javíthatja a lekérdezések teljesítményét és az adatfeldolgozást, például az olyan szolgáltatások esetében, amelyek a memóriában történő gyorsítótárazásért felelnek.
Ennek ellenére, bár a vertikális mikroszolgáltatás-skalázás egyszerűbb és azonnali teljesítménynövekedést biztosít, hátrányai is vannak. A vertikális skalázást korlátozza a szerver hardver-kapacitása, így egy ponton át kell váltanod a horizontális skalázásra, hogy folytathass a fejlesztésben.
Továbbá a vertikális skálázás magas költségeket igényel, mivel a hardver és a nagyobb instanciák általában drágák. Végül, ha a felskalázott instancia meghibásodik, a szolgáltatás teljesen leáll, mert nincs további instancia a terhelés kezelésére.
A horizontális mikroszolgáltatás-skálázásnál ahelyett, hogy egyetlen instancia erőforrásait növelnéd, új instanciákat helyezel üzembe. Bár ezek az instanciák függetlenül működnek, ugyanazt a szolgáltatást és a terhelés ugyanazon részeit kezelik.
A vertikális skálázástól eltérően a horizontális mikroszolgáltatás-skálázás korlátlan, vagyis tetszőleges számú instanciát adhatsz hozzá a növekvő terhelések és forgalom-csúcsok kezelésére, ami nagyobb méretezhetőséget biztosít.
Sőt, mivel több instanciád van, ha az egyik meghibásodik, nem teszed azt kockára, hogy egy helyből függesz, mivel más instanciák továbbra is kezelhetik a kéréseket. Végül a horizontális skálázás hosszú távon sokkal költséghatékonyabb, mivel több kisebb és olcsóbb instanciát használhatsz egy megbízhatóbb, erősebb teljesítmény kialakításához.
Azt viszont el kell mondani, hogy a horizontális skálázás és további instanciák hozzáadása több terheléselosztót, mikroszolgáltatás-felfedezési mechanizmusokat és mikroszolgáltatás-vezénylési eszközöket igényel, ami sokkal összetettebb mikroszolgáltatás-architektúrát eredményez.
A horizontális skálázás jobban alkalmas olyan felhasználási esetekre, mint a webes szolgáltatások és alkalmazások, például az e-kereskedelmi vagy közösségi médiás platformok, amelyek gyakran változó forgalommal és nagy mennyiségű kérésekkel szembesülnek.
Ennek ellenére nem igazán választás az egyik vagy a másik között, mivel mindkét skálázási típus támogatott a mikroszolgáltatásokban és sok esetben szükséges. Jellemzően a kisebb szervezetek vertikális skálázást használnak, mivel sokkal egyszerűbb megvalósítani és kezelni, de az idő múlásával és az alkalmazás növekedésével a horizontális skálázást vezetik be a nagy terhelés kezelésére.
Végül a felhőplatformok auto-skálázási szolgáltatásokat kínálnak, amelyek automatikusan hozzáadnak vagy eltávolítanak instanciákat a valós igények alapján, ami jelentősen segít a szervezeteknek a vertikális és horizontális skálázás egyensúlyozásában.
Mikroszolgáltatás monitorozás
Ezen a ponton gyakorlatilag kész vagy a mikroszolgáltatás-telepítéseddel; már csak az maradt, hogy biztosítsd a konzisztens és megbízható működést. Ennek a mikroszolgáltatás-monitorozási eszközökhöz, például a Prometheus és Grafana lépjen be.
Ezek az eszközök valós idejű betekintést nyújtanak a szolgáltatás metrikáiba, így a csapatok nyomon követhetik az erőforrás-felhasználást, a késleltetést és a hibaarányokat. Ezenkívül ezek az eszközök elosztott nyomkövetést is kínálnak (Jaeger, Zipkin stb.), amely segít megjeleníteni a kérések áramlását a szolgáltatások között, és hatalmas mértékben hasznos lehet a problémák diagnosztizálásához.
Végül, mivel a hibák a mikroszolgáltatások elosztott tervezése miatt terjedhetnek a szolgáltatások között, a naplók központosítása kritikus gyakorlat a mikroszolgáltatás-monitorozásban. A naplók egy központosított platformra való összevonásával és valós idejű riasztások beállításával mindig megelőzheted a problémákat, és proaktívan reagálhatsz rájuk, mielőtt a felhasználókat érintenék.
Végső gondolatok
Bár a mikroszolgáltatások világa biztosan nehezen érthető, a mikroszolgáltatás-telepítés alapelvei és kulcsfázisainak megértése sokkal könnyebbé teheti a folyamatot. Sőt, az évek múlásával egyre több, lényegesen több funkcióval rendelkező eszköz áll az életed céljára, ami a mikroszolgáltatás-telepítést egyszerűbbé teszi, mint valaha.
Gyakran Ismételt Kérdések
Milyen telepítési stratégiákat használnak gyakran a mikroszolgáltatások esetében?
Bár a mikroszolgáltatás-telepítésnek számos különböző stratégiája van, a leggyakrabban használt telepítési stratégiák közé tartoznak a szolgáltatáspéldányok containerekben, a fokozatos kiadások, a kék-zöld telepítés és a szerver nélküli telepítés, amelyek mindegyike különböző szintű elkülönítést, rugalmasságot és méretezhetőséget kínál.
Milyen szerepet játszik az Kubernetes a mikroszolgáltatások vezénylésében?
A mikroszolgáltatások olyan mikroszolgáltatás-vezénylési eszközöktől függenek, mint az Kubernetes, hogy automatizálják a containerizált szolgáltatások telepítését, skálázását és kezelését, és biztosítanak terheléselosztást, auto-skálázást és öngyógyítási képességeket a rugalmas és hatékony mikroszolgáltatások biztosítása érdekében.
Hogyan biztosíthatom a biztonságot egy mikroszolgáltatás-környezetben?
Az elosztott jellegük miatt a mikroszolgáltatások bonyolultabbak a biztonság szempontjából, mint a monolitikus architektúra. A mikroszolgáltatások biztonsága magában foglalja a kérések hitelesítését és engedélyeztetését, a szolgáltatások közötti kommunikáció titkosítását, valamint az API átjárók és az olyan szolgáltatáshálók, mint az Istio megvalósítását a központosított biztonságkezeléshez.
