A 60-as és 70-es években monolitikus építészet A korlátozott számítási erőforrások miatt az összes funkcionalitást egyetlen, összefüggő egységben kellett egyesíteni.
Ez egészen a '90-es évek végéig és a 2000-es évekig tartott, amikor a monolitikus struktúra kezdett túlságosan korlátozottá válni az alkalmazások egyre növekvő méretéhez és összetettségéhez, különösen az internet és az elosztott rendszerek térnyerésével.
Ez több moduláris megközelítés kifejlesztéséhez vezetett, mint pl szolgáltatásorientált architektúrák (SOA) és később, mikroszolgáltatási architektúra (MSA), amely végül a 2010-es évek elején vált kiemelkedővé.
Ez azonban csupán egy rövid magyarázata a mikroszolgáltatások alapfogalmának és használatának. Tehát beszéljük meg, hogyan váltották fel a mikroszolgáltatások a monolitikus architektúrát, hogyan működnek a mikroszolgáltatások, és néhány példát a mikroszolgáltatásokra. Ezt követően megvitatjuk a mikroszolgáltatások telepítésének legfontosabb szempontjait, és azt, hogy mit kell tenni, ha mikroszolgáltatásokat szeretne telepíteni.
Mik azok a mikroszolgáltatások? Hogyan működnek?
Ahogy korábban említettem, a mikroszolgáltatások megoldásként jelentek meg az alkalmazások összetettségének és méretének növelésére, lehetővé téve a vállalatok számára, hogy a funkciókat önállóan telepíthető szolgáltatásokra bontsák.
A „mikroszolgáltatások” kifejezést olyan iparági szakértők népszerűsítették, mint Martin Fowler és James Lewis, akik 2014-ben hivatalosan is bevezették egy blogbejegyzésben. Munkájuk meghatározta a kulcsfontosságú elveket és jellemzőket, beleértve az önállóan telepíthető szolgáltatások szükségességét, a decentralizált adatkezelést és a technológiai agnoszticizmust.
Azóta a mikroszolgáltatások általános építészeti választássá váltak, amelyet a fejlesztések is támogatnak konténerezési technológiák, mint a Docker, hangszerelési eszközök, például a Kubernetes és kiszolgáló nélküli számítási platformok. De hogyan működnek a mikroszolgáltatások?
Hogyan működnek a mikroszolgáltatások?
A mikroszolgáltatási architektúra lényegében a nagy alkalmazásokat kisebb, különálló szolgáltatásokra bontja, amelyek mindegyike egy adott üzleti képességért felel. Ezek a szolgáltatások hálózaton keresztül kommunikálnak egymással, gyakran REST API-kon, gRPC-n vagy üzenetközvetítőkön (például RabbitMQ vagy Apache Kafka) keresztül.
Martin Fowler és James Lewis meghatározása szerint a mikroszolgáltatások mindegyike négy kulcsfontosságú jellemzővel rendelkezik, amelyek a következők:
- Egyedülálló felelősség: Minden mikroszolgáltatást úgy terveztek, hogy egy adott feladatot vagy funkciót hajtson végre, lehetővé téve a specializációt és a bonyolultság csökkentését.
- Függetlenség: A mikroszolgáltatások egymástól függetlenül fejleszthetők, telepíthetők és méretezhetők, ami rugalmasságot és rugalmasságot biztosít.
- Decentralizált adatkezelés: A mikroszolgáltatások gyakran saját adatbázissal rendelkeznek, így nincs szükség egyetlen, központi adatbázisra.
- Technológiai agnoszticizmus: A csapatok kiválaszthatják a legjobb technológiát az egyes szolgáltatásokhoz anélkül, hogy más szolgáltatások választása kötné őket.
Ez a megközelítés ellentétben áll a hagyományos monolitikus architektúrával, amelyben az összes alkalmazáskomponens szorosan egyetlen, összefüggő egységbe van integrálva.
A mikroszolgáltatások bevezetésének fő szakaszai
Míg a mikroszolgáltatás-architektúra számtalan előnnyel jár, például nagy skálázhatóságot, rugalmasságot, hatékonyságot, hibaleválasztást stb., a mikroszolgáltatások hatékony üzembe helyezésének ismerete és alapos tervezés szükséges ahhoz, hogy sikeres legyen.
Ezért elengedhetetlen egy sikeres mikroszolgáltatás-architektúrához, hogy átfogó képet kapjunk a kulcsfontosságú koncepciókról, szakaszokról és a mikroszolgáltatások bevált gyakorlatairól a mikroszolgáltatások bevezetésében. Tehát vizsgáljuk meg a mikroszolgáltatások bevezetésének kulcsfontosságú szakaszait, és az egyes szakaszok tartalmát.
Mikroszolgáltatások bevezetésének tervezése és előkészítése
Minden jó dolog tervezést és türelmet igényel, a mikroszolgáltatások sikeres üzembe helyezéséhez pedig minden bizonnyal sok tervezésre és türelemre van szükség. Ezért fontos, hogy kövesse a mikroszolgáltatások bevált gyakorlatait, és megtervezze és előkészítse mindazt, amire a mikroszolgáltatások üzembe helyezésekor szüksége van.
Mint korábban említettem, a mikroszolgáltatások egyik kulcsfontosságú alapelve és jellemzője a Egységes felelősség elve. Ha hű marad ehhez az elvhez, és gondoskodik arról, hogy minden mikroszolgáltatás egy funkcióra és képességre összpontosítson, és egy adott funkcióért és képességért feleljen, lehetővé teszi csapata számára a szolgáltatások önálló fejlesztését, telepítését és méretezését.
Továbbá ennek az elvnek egy alkategóriája a laza tengelykapcsoló tervezési elve. Ez azt jelenti, hogy minden szolgáltatás egymástól függetlenül működhet a kommunikációban, és minimális mértékben függ más szolgáltatásoktól. Ez viszont lehetővé teszi, hogy az egyik szolgáltatás módosításai vagy frissítései ne befolyásolják a többi szolgáltatást, lehetővé téve a független mikroszolgáltatások méretezését.
Ez csökkenti a lépcsőzetes meghibásodások kockázatát, amikor a rendszer egyik részének problémája vagy meghibásodása láncreakciót vált ki, ami az egész rendszer meghibásodásához vezet, és az egész szolgáltatást leállítja.
Az egyik fontos mikroszolgáltatási gyakorlat az, hogy a mikroszolgáltatások telepítésekor minden szolgáltatáshoz külön adattárolást kell biztosítani a laza csatolás tervezési elvének kiterjesztéseként, mivel ez megakadályozza az ütközéseket és lehetővé teszi a szolgáltatás jobb méretezhetőségét.
Ezenkívül szükség lesz aszinkron mikroszolgáltatások kommunikációs mintáira, például üzenetközvetítőkre, hogy minden szolgáltatás közvetlen függőségek nélkül tudjon kommunikálni.
A rejtvény utolsó darabja a folyamatos integráció és a folyamatos szállítás (CI/CD) folyamatok megvalósítása a mikroszolgáltatásokhoz. Ezek a folyamatok lehetővé teszik a csapatok számára, hogy új funkciókat vagy javításokat telepítsenek CI/CD eszközök mint a Jenkins és a GitLab, lehetővé téve a szervezetek számára a rendszer stabilitásának fenntartását, miközben gyakran új képességeket adnak ki.
Most, hogy átfogó elképzelése 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
A mikroszolgáltatások üzembe helyezésekor az üzembe helyezési stratégia kiválasztása a szolgáltatás funkciójától, a forgalomtól, az infrastruktúra beállításától, a csapat szakértelmétől és a költségmegfontolásoktól függ. Általában azonban a mikroszolgáltatások telepítési stratégiái a következők:
- Szolgáltatáspéldány tárolónként: Ebben a megközelítésben minden mikroszolgáltatás a saját tárolójában fut, jobb elkülönítést kínálva, mint a gazdagépmodellenkénti több példány. A konténerek megkönnyítik a méretezést és javítják az erőforrások elosztását.
- Szolgáltatáspéldány virtuális gépenként: Minden szolgáltatás külön virtuális gépen (VM) fut, ami még a konténereknél is nagyobb elszigeteltséget biztosít. Bár ez javítja a biztonságot és a stabilitást, általában több rezsivel jár.
- Fázisos megjelenések: Kezdetben telepítse a mikroszolgáltatási verziókat a felhasználók egy kis csoportjára, és tesztelje a stabilitásukat a teljes bevezetés előtt. Ez a megközelítés minimálisra csökkenti a hatást, ha problémák merülnek fel, és lehetővé teszi a gyors visszaállítást a rendszer integritásának megőrzése érdekében.
- Kék-zöld telepítés: Ez a módszer két azonos éles környezetet használ, az egyik környezet élő forgalmat szolgál ki, míg a másik a következő kiadás tesztelésére szolgál. A kék-zöld üzembe helyezés egyszerű visszaállítást és leállás nélküli frissítést tesz lehetővé, mivel a forgalom zökkenőmentesen átkapcsolható a két környezet között.
- Szakaszos megjelenések: Ez a stratégia magában foglalja a frissítések fokozatos bevezetését a különböző felhasználói szegmensekre vagy környezetekre. Gyakran a belső környezetekkel kezdődik, mielőtt elérné a termelést, korlátozva a lehetséges problémák robbanási sugarát, és lehetővé téve a csapatok számára, hogy szakaszosan kezeljék a problémákat.
- Szerver nélküli telepítés: Ez a megközelítés olyan kiszolgáló nélküli platformokat használ, mint az AWS Fargate és a Google Cloud Run, amelyek automatizálják az infrastruktúra kezelését azáltal, hogy kezelik a méretezést és az erőforrások kiosztását. A kiszolgáló nélküli telepítéssel nincs szükség az alapul szolgáló kiszolgálók kezelésére, lehetővé téve, hogy magukra a mikroszolgáltatásokra összpontosítson.
Miután kiválasztotta a fenti mikroszolgáltatások egyikét a mikroszolgáltatások üzembe helyezéséhez, szüksége lesz egy mikroszolgáltatások hangszerelési eszközére.
Mikroszolgáltatások hangszerelése
Miután kiválasztotta az egyiket a számos mikroszolgáltatás telepítési stratégiája közül, szüksége lesz egy karmesterre a mikroszolgáltatások hangszereléséhez. Microservice hangszerelési eszközök, mint pl Kubernetes, segít automatizálni a mikroszolgáltatások telepítését, a mikroszolgáltatások méretezését, a mikroszolgáltatások figyelését és a konténeres mikroszolgáltatások kezelését.
Az Airbnb például a Kubernetes rendszert használja, lehetővé téve mérnökei számára, hogy manuális felügyelet nélkül több száz változtatást hajtsanak végre mikroszolgáltatásaikon. A mikroszolgáltatások hangszerelési eszközeinek, például a Kubernetesnek egyik fontos jellemzője a beépített terheléselosztás.
A hozzáértő terheléselosztási funkció segít a bejövő forgalom elosztásában a mikroszolgáltatások több példánya között. Ez megakadályozza, hogy az egyes példányok szűk keresztmetszetté váljanak, és javítja a rendszer azon képességét, hogy kezelje a megugrott keresletet.
A Kubernetes öngyógyító képességei révén jelentős szerepet játszik a mikroszolgáltatások kezelésében, ahol a meghibásodott tárolók automatikusan cserére és újraindításra kerülnek. A New York Times kihasználja ezt a funkciót, hogy fenntartsa mikroszolgáltatásait anélkül, hogy befolyásolná a felhasználói élményt és leállásokat.
Ezenkívül a Kubernetes a konfigurációk és titkok, például adatbázis-hitelesítő adatok vagy API-kulcsok révén javítja a mikroszolgáltatások biztonságát a ConfigMaps és Secrets segítségével. Ez különösen fontos az olyan vállalatok és szolgáltatások esetében, mint az Uber, amelyek érzékeny ügyfél- és felhasználói adatokkal foglalkoznak.
Végül a mikroszolgáltatások hangszerelési eszközei, mint például a Kubernetes, különösen előnyösek az olyan mikroszolgáltatási stratégiákban, amelyek folyamatos frissítéseket és visszaállításokat foglalnak magukban, például szakaszos kiadásokat. A folyamatos frissítések lehetővé teszik az új mikroszolgáltatás-verziók szolgáltatásmegszakítások nélküli üzembe helyezését a régi verzió egyes példányainak futásban tartásával.
Miután beállította a mikroszolgáltatások hangszerelési eszközét, létre kell hoznia és automatizálnia kell CI/CD csővezetékek mikroszolgáltatások telepítéséhez.
CI/CD-folyamatok a mikroszolgáltatások telepítéséhez
Amint arról korábban beszéltünk, a folyamatos integráció és a folyamatos szállítás folyamatai a mikroszolgáltatásokhoz fontos szempontok a mikroszolgáltatások telepítésében. A CI/CD-folyamatokban lévő CD-folyamatok felelősek a kódmódosítások automatikus üzembe helyezéséért a termelésben, amint átmennek a CI/CD-folyamat tesztelési és integrációs szakaszán.
Ezután a CI/CD-folyamat 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 szakaszon, a szolgáltatás egy mikroszolgáltatások hangszerelési eszközére, például egy Kubernetes-fürtre kerül telepítésre.
Ezenkívül a tesztelési és integrációs szakaszokat a CI/CD folyamatok automatikusan elvégzik, mivel az egységtesztek, az integrációs tesztek és a végpontok közötti tesztek beépülnek a folyamatba.
Ez lehetővé teszi a csapatok számára, hogy minden szakaszban érvényesítsék a frissítéseket, miközben megőrzik a rendszer stabilitását. Ráadásul, ha bármilyen probléma adódik a kódmódosításokkal, a különféle tesztelések ellenére az automatizált visszagörgetések visszaállhatnak a korábbi stabil verzióra.
Végül a CI/CD folyamatok megvalósítása a mikroszolgáltatásokhoz a mikroszolgáltatások bevált gyakorlatai szerint segíti a szervezeteket a gyorsabb fejlődés elérésében, a kézi hibák csökkentésében és a magas minőségi szabványok fenntartásában.
Sok vállalat, például a Spotify, az Expedia, az iRobot, a Lufthansa, a Pandora stb., CI/CD-folyamatokat használ mikroszolgáltatásokhoz olyan CI/CD-eszközökön keresztül, mint a CircleCI, az AWS CodePipeline és a GitLab, hogy automatizálják a telepítési folyamatokat, biztosítsák az egységes kódminőséget és gyorsan biztosítsák az új funkciókat a rendszer stabilitásának megőrzése mellett.
Mikroszolgáltatások kommunikációs mintái
A mikroszolgáltatások egymással való kommunikációja teljes mértékben függ a funkciótól, az általános architektúrától, a kívánt méretezhetőségtől és a mikroszolgáltatások megbízhatóságától. Általában a mikroszolgáltatások két fő kommunikációs mintáját alkalmazzák: szinkron és aszinkron mikroszolgáltatások kommunikációs mintái.
A szinkron mikroszolgáltatások kommunikációs mintáiban a szolgáltatások valós időben működnek együtt, ami azt jelenti, hogy a szolgáltatás kérést küld, és válaszra vár, mielőtt folytatná. A leggyakrabban használt szinkron mikroszolgáltatások kommunikációs mintái REST (Representational State Transfer) API-k, gRPC (Google Remote Procedure Call), és GraphQL.
Jellemzően az ilyen típusú mikroszolgáltatások kommunikációs mintáit olyan iparágak és vállalatok használják, amelyek jellemzően valós idejű adatfeldolgozást és azonnali válaszokat igényelnek. Az olyan iparágak, mint a pénzügy, az egészségügy és az e-kereskedelem, gyakran használnak szinkron kommunikációs mintákat annak biztosítására, hogy a tranzakciók, az adatok visszakeresése vagy az interakciók azonnal megtörténjenek, és így biztosítva a zökkenőmentes és rugalmas felhasználói élményt.
Mindazonáltal, bár a szinkron mikroszolgáltatások kommunikációs mintái olyan előnyöket kínálnak, mint a valós idejű válaszadás és az egyszerűség, bizonyos hátrányaik is vannak, mint például a szoros csatolás, az alacsony skálázhatóság nagy terhelés mellett, a lassú válaszidő és a nagy késleltetés nagy forgalmú esetekben.
Másrészt az aszinkron mikroszolgáltatások kommunikációs mintái jellemzően jobban megfelelnek a mikroszolgáltatásoknak, mivel a korábban tárgyalt Loose Coupling elven alapulnak.
Az ilyen típusú mikroszolgáltatások kommunikációs mintája szétválasztja a szolgáltatásokat azáltal, hogy lehetővé teszi számukra, hogy üzeneteket küldjenek és fogadjanak egy brókeren keresztül, mint például a Kafka vagy a RabbitMQ. A pufferként működő várólista üzenetek küldésével a szolgáltatások egymástól függetlenül kommunikálnak, ahelyett, hogy választ várnának, ahogyan azt szinkron kommunikációs mintákban tennék. Ez a puffer lehetővé teszi más szolgáltatások számára, hogy saját ütemükben dolgozzák fel az üzeneteket, így a küldő folytathatja munkáját anélkül, hogy a címzettre várna.
Az aszinkron mikroszolgáltatások kommunikációs mintája nemcsak szétválasztott struktúrát kínál a mikroszolgáltatások telepítéséhez, hanem ugyanazt a valós idejű választ is kínálja, mint a szinkron mikroszolgáltatások kommunikációs mintái.
Ez az aszinkron eseményvezérelt mikroszolgáltatások kommunikációs mintáinak eseményvezérelt architektúrájának köszönhető, mivel a szolgáltatások események kibocsátásával kommunikálnak, amikor egy adott művelet megtörténik. Más szolgáltatások előfizethetnek ezekre az eseményekre, és ennek megfelelően reagálhatnak. Ez rendkívül érzékeny rendszereket tesz lehetővé, amelyek valós időben reagálnak a változásokra, anélkül, hogy a szolgáltatások között közvetlen kapcsolat lenne.
Ráadásul aszinkronban Közzététel-Feliratkozás (Pub/Sub) a mikroszolgáltatások kommunikációs mintáit, a szolgáltatások (kiadók) üzeneteket küldenek egy témának, és más szolgáltatások (előfizetők) figyelik a témát, hogy frissítéseket kapjanak. Ez a modell több előfizetőt támogat, és egyszerre több szolgáltatásnak is sugároz üzeneteket.
Végül, hasonlóan az eseményvezérelt mintákhoz, aszinkron koreográfia alapú saga a mikroszolgáltatások kommunikációs mintái az eseményeket is felhasználják az egymással való kommunikációra; azonban ebben a mintában egy bizonyos sorrend van érvényben, ami azt jelenti, hogy az események kiváltják a következő lépést és egy adott szolgáltatás aktiválását.
A különbség itt az, hogy az eseményvezérelt mintákban nincs bizonyos sorrend vagy munkafolyamat, és több szolgáltatás is reagálhat egy eseményre, nem pedig az adott folyamatra és sorrendre a koreográfia alapú saga mintában.
Az Ön által használt aszinkron mikroszolgáltatások kommunikációs mintája a feladattól és a mikroszolgáltatások általános funkciójától függ. Az olyan üzenetsorokat, mint a RabbitMQ és az Amazon SQS, általában a feladatok ütemezésére, a munkaterhelés elosztására és az e-kereskedelemre használják a rendelésfeldolgozási és értesítési rendszerekben.
Az eseményvezérelt üzenetközvetítők, mint például az Apache Kafka és az AWS EventBridge, általában nagyszabású eseményfolyamok valós idejű feldolgozására és mikroszolgáltatások közötti esemény-útválasztásra használatosak olyan területeken, mint a pénzügyi szolgáltatások és az AWS-környezetek.
Ami a Publish-Subscribe (Pub/Sub) üzenetközvetítőket illeti, mint például a Google Cloud Pub/Sub és a Redis Streams, ezeket az üzenetközvetítőket általában skálázható üzenetküldésre használják elosztott rendszerek között valós idejű elemzéshez és eseményfeldolgozáshoz, valamint valós idejű értesítésekhez és csevegőalkalmazásokhoz.
Végül a koreográfián alapuló saga üzenetközvetítőket főként e-kereskedelmi rendelések feldolgozására, utazási foglalási rendszerekre használják, és olyan esetekben, amikor összetett, többlépcsős tranzakciókat kell koordinálni több szolgáltatás között központi irányítás nélkül.
Microservice Service Discovery
Miután felállította és megvalósította az igényeinek megfelelő kommunikációs mintát, először is biztosítania kell, hogy szolgáltatásai megtalálják egymást. Mint korábban említettem, a mikroszolgáltatások hangszerelési eszközei, mint például a Kubernetes, fontos szerepet játszanak a mikroszolgáltatás-szolgáltatás felfedezésében.
Ez a Kubernetes DNS által biztosított beépített szolgáltatásfelderítésen keresztül történik, amely dinamikusan frissíti az IP-címeket és a DNS-rekordokat a szolgáltatások méretezésével vagy a fürtön belüli hely megváltoztatásával.
A mikroszolgáltatások szolgáltatás-felderítésének ezt a módszerét kiszolgálóoldali felderítésnek nevezik, mivel az útválasztási felelősség egy terheléselosztóra van delegálva, amely ezután lekérdezi a rendszerleíró adatbázist, és a forgalmat a megfelelő példányhoz irányítja.
Másrészt a mikroszolgáltatás-felderítéshez rendelkezésre áll az ügyféloldali felderítési módszer is, ahol a szolgáltatás vagy API-átjáró lekérdez egy szolgáltatásnyilvántartást, például a Consul-t vagy az Eurekát, hogy megtalálja az elérhető példányokat.
A rendszer követelményeitől és méretétől függ, hogy melyik szolgáltatáskeresési módszer a legmegfelelőbb a mikroszolgáltatások telepítéséhez.
Az ügyféloldali mikroszolgáltatás-felderítéssel az ügyfél teljes mértékben szabályozhatja, hogy melyik példánysal kommunikál. Ez nemcsak több testreszabást tesz lehetővé, hanem csökkenti a bonyolultságot is, mivel nincs szükség központosított felderítési szolgáltatásra.
Például a Netflix mikroszolgáltatások telepítése ügyféloldali mikroszolgáltatás-felderítést használ az Eurekával és a Ribbonnal a terheléselosztáshoz, lehetővé téve az ügyfél számára a legjobb példány kiválasztását olyan kritériumok alapján, mint a várakozási idő és a szerverterhelés.
A kiszolgálóoldali mikroszolgáltatás-felderítés azonban alkalmasabb nagyobb környezetekben, mivel a központosított szolgáltatáskeresés javíthatja a hatékonyságot, és lehetővé teszi a konzisztens terheléselosztást az elosztott rendszeren.
A szerveroldali mikroszolgáltatás-felderítési megoldások, mint például a Kubernetes, az AWS Elastic Load Balancing és az API-átjárók (Kong, NGINX stb.) segítik a forgalom hatékony irányítását és a magas rendelkezésre állás fenntartását, és olyan cégek használják őket, mint az Airbnb, Pinterest, Expedia, Lyft stb.
Microservice Security
Míg a monolitikus építészet többnyire rosszabb, mint az MSA, az egyik szempont, ahol a monolitikus építészet előnye volt, a biztonság volt. Mivel a mikroszolgáltatások a laza csatolás elvén épülnek, és a természetben terjesztettek, egyedi, általános biztonsági intézkedés nem valósítható meg.
Mivel minden szolgáltatást egymástól függetlenül kell védeni, további biztosítékokra van szükség, mivel a mikroszolgáltatásokban sokkal nagyobb a támadási felület. Ebből a célból olyan szabványokat használnak, mint az OAuth2 és a JSON Web Tokens (JWT), ahogy azt sejteni lehetett, a hitelesítéshez és az engedélyezéshez.
Ezenkívül egy API-átjárót gyakran alkalmaznak a mikroszolgáltatások biztonságának kezelésére is, mivel a belépési ponton érvényesíti a hitelesítést és az engedélyezést. Ráadásul az átjáró API-k sebességkorlátozást, naplózást és megfigyelést is megvalósíthatnak, amelyek további mikroszolgáltatási biztonságot nyújtanak.
Míg ezek biztosítják a fő belépési pontot, több mikroszolgáltatási biztonsági intézkedésre van szükség a szolgálatok közötti kommunikáció lefedéséhez.
Itt lépnek életbe a szolgáltatáshálók, amelyek egy hálózati mikroszolgáltatás-biztonsági réteget adnak, és titkosítják a szolgáltatások közötti forgalmat, és kikényszerítik az olyan irányelveket, mint a kölcsönös TLS. Ezek a szerverhálók alapvetően átfogó, végpontok közötti titkosítást hoznak létre, amely jelentősen javítja a mikroszolgáltatások biztonságát.
Microservice Scaling
Az MSA egyik legnagyobb előnye, és éppen ezért a monolitikus architektúra helyettesítésére fejlesztették ki, a nagy skálázhatósága. A mikroszolgáltatások méretezésének általában két módja van: függőleges és vízszintes.
Alapvetően a függőleges mikroszolgáltatás-skálázás (nagyítás) több erőforrást, például CPU-t vagy memóriát ad egy meglévő példányhoz. Alternatív megoldásként a vízszintes mikroszolgáltatási méretezés (kiskálázás) elosztja a terhelést és növeli a kapacitást.
A megvalósítás szempontjából a függőleges mikroszolgáltatási skálázás a kettő közül a könnyebbik, mivel mindössze egyetlen példányt kell módosítania egy nagyobb kiszolgálóra való frissítéssel, a memória vagy a feldolgozási teljesítmény növelésével egy felhőpéldányban, vagy több tárhely hozzáadásával.
Ezt a fajta skálázást általában olyan esetekben használják, amikor a RAM vagy a CPU teljesítményének növelése javíthatja a lekérdezések teljesítményét és az adatfeldolgozást, például a memórián belüli gyorsítótárazásért felelős szolgáltatásokat.
Ennek ellenére, bár a függőleges mikroszolgáltatás-skálázás egyszerűbb és azonnali teljesítménynövekedést kínál, vannak hátrányai is. A függőleges skálázást a szerver hardverkapacitása korlátozza, ezért valamikor át kell váltania a vízszintes skálázásra a függőleges méretezés folytatásához.
Ezenkívül a függőleges méretezés magas költségekkel jár, mivel a hardver és a nagyobb példányok általában magas árcédulával járnak. Végül, ha a felnagyított példány meghibásodik, a szolgáltatás teljesen leáll, mivel nincsenek további példányok a terhelés kezelésére.
A vízszintes mikroszolgáltatás-méretezéshez egyetlen példány erőforrásának frissítése helyett a szolgáltatás új példányait kell üzembe helyeznie. Bár ezek a példányok egymástól függetlenül működnek, továbbra is ugyanazt a szolgáltatást és ugyanannak a munkaterhelésnek a részeit kezelik.
A függőleges skálázással ellentétben a vízszintes mikroszolgáltatási skálázás korlátlan, ami azt jelenti, hogy tetszőleges számú példányt adhat hozzá a növekvő munkaterhelések és a forgalmi kiugrások kezelésére, így nagyobb méretezhetőséget biztosít.
Sőt, mivel több példányod van, ha az egyik elromlik, nem teszed az összes tojást egy kosárba, mivel más példányok folytathatják a kérések kezelését. Végül, a vízszintes méretezés hosszú távon sokkal költséghatékonyabb, mivel több kisebb és olcsóbb példányt is használhat megbízhatóbb, erősebb teljesítmény eléréséhez.
Ennek ellenére a vízszintes méretezéshez és több példány hozzáadásához több terheléselosztóra, mikroszolgáltatás-felderítési mechanizmusra és mikroszolgáltatás-hangosítási eszközre van szükség, ami sokkal összetettebbé teszi a mikroszolgáltatások architektúráját.
A vízszintes méretezés alkalmasabb olyan esetekre, mint például webszolgáltatások és alkalmazások, például e-kereskedelem vagy közösségi média platformok, amelyek gyakran ingadozó forgalommal és nagy mennyiségű kéréssel fordulnak elő.
Ennek ellenére valójában nem a vagy egyikről van szó, mivel mindkét típusú skálázást támogatják a mikroszolgáltatások, és sok esetben szükség van rájuk. Általában a kisebb szervezetek vertikális skálázást használnak, mivel sokkal egyszerűbb a megvalósítása és kezelése, de idővel és az alkalmazás növekedésével a vízszintes skálázást vezetik be a nagy igények kezelésére.
Végül a felhőplatformok olyan automatikus skálázási szolgáltatásokat kínálnak, amelyek a valós idejű kereslet alapján automatikusan hozzáadnak vagy eltávolítanak példányokat, ami jelentősen segíti a szervezeteket a vertikális és vízszintes méretezés egyensúlyában.
Microservice Monitoring
Ebben a szakaszban nagyjából elkészült a mikroszolgáltatások bevezetésével; csak meg kell győződni arról, hogy folyamatosan és megbízhatóan működik. Ez az, ahol a mikroszolgáltatás-felügyeleti eszközök például Prométheusz és Grafana lépj be.
Ezek az eszközök valós idejű betekintést nyújtanak a szolgáltatási metrikákba, így a csapatok nyomon követhetik az erőforrás-használatot, a várakozási időt és a hibaarányt. Ezenkívül ezek az eszközök elosztott nyomkövetést is kínálnak (Jaeger, Zipkin stb.), amely segít a szolgáltatások közötti kérések áramlásának megjelenítésében, és rendkívül előnyös lehet a problémák diagnosztizálásában.
Végül, mivel a meghibásodások a mikroszolgáltatások elosztott kialakítása miatt a szolgáltatások között lépcsőzetessé válhatnak, a naplóösszesítés kritikus gyakorlat a mikroszolgáltatás-felügyeletben. A naplók központosított platformba történő összevonásával és valós idejű riasztások beállításával mindig két lépéssel a problémák előtt járhat, és proaktívan reagálhat rájuk, mielőtt azok érintenék a felhasználókat.
Végső gondolatok
Noha a mikroszolgáltatások világa minden bizonnyal nehéz körüljárni, a mikroszolgáltatások bevezetésének alapjainak és kulcsfontosságú szakaszainak megértése sokkal könnyebbé teheti az egész folyamatot. Ráadásul az évek múlásával egyre több eszköz áll az Ön rendelkezésére, lényegesen több funkcióval, így a mikroszolgáltatások telepítése minden eddiginél egyszerűbbé válik.
GYIK
Milyen telepítési stratégiákat használnak általában a mikroszolgáltatásokhoz?
Noha számos különböző stratégia létezik a mikroszolgáltatások üzembe helyezésére, a leggyakrabban használt telepítési stratégiák közé tartoznak a tárolónkénti szolgáltatáspéldányok, a szakaszos kiadások, a kék-zöld üzembe helyezés és a kiszolgáló nélküli központi 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 a Kubernetes a mikroszolgáltatások megszervezésében?
A mikroszolgáltatások a mikroszolgáltatások irányítási eszközeitől függenek, például a Kubernetesen, hogy automatizálják a telepítést, a méretezhetőséget és a konténeres szolgáltatások kezelését, terheléselosztási, automatikus skálázási és öngyógyító képességeket biztosítva a rugalmas és hatékony mikroszolgáltatások biztosítása érdekében.
Hogyan biztosíthatom a biztonságot mikroszolgáltatási környezetben?
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élyezését, a szolgálatok közötti kommunikáció titkosítását, valamint API-átjárók és szolgáltatáshálók, például az Istio megvalósítását a központosított biztonságkezelés érdekében.
