- A mikroszolgáltatások a szolgáltatások, az adatok, a rugalmasság és a szerződések gondos megtervezését igénylik ahhoz, hogy éles környezetben is működőképesek legyenek.
- A Kubernetes/OpenShift, a CI/CD és a GitOps lehetővé teszi a nagyméretű telepítések, skálázás és üzemeltetés automatizálását.
- A platform pillérei a zéró bizalom biztonsága, a robusztus konfigurációkezelés és az OpenTelemetry általi megfigyelhetőség.
- A termékfejlesztő csapat szervezése és az elosztott irányítás ugyanolyan fontos, mint a választott technológia.
Egy mikroszolgáltatás-architektúra valós környezetben való alkalmazása nem csupán egy monolit kisebb darabokra bontását jelenti; magában foglalja az infrastruktúra, a csapatok, a folyamatok, az adatok, a biztonság és a műveletek újragondolását . Amikor a rendszer az elméleti környezetből egy éles klaszterbe kerül, problémák merülnek fel a szolgáltatások felderítésével, a csapatok közötti szerződésekkel, a konfigurációs és fejlesztési infrastruktúrával (CI/CD), a megfigyelhetőséggel, a rugalmassággal és a skálázhatósággal kapcsolatban. Ha ezeket nem kezelik megfelelően, a mikroszolgáltatások elosztott káoszba torkollhatnak.
A jó hír az, hogy ma már rengeteg felhalmozott tapasztalattal rendelkezünk olyan szervezetektől, mint a Netflix, az Amazon, a Google és más nagyvállalatok, amelyek több száz mikroszolgáltatást üzemeltetnek éles környezetben . Ezekre a tanulságokra, valamint a Kubernetes és az OpenShift használatával végzett vállalati környezetekben alkalmazott legjobb gyakorlatokra építve egy nagyon robusztus megközelítést dolgozhatunk ki a mikroszolgáltatások nagy léptékű tervezésére, telepítésére és üzemeltetésére anélkül, hogy elveszítenénk az irányítást.
Miért érdemes mikroszolgáltatásokat üzembe helyezni éles környezetben (és mikor nem éri meg)
Egy jól megtervezett mikroszolgáltatás-architektúra lehetővé teszi, hogy kis, autonóm és többfunkciós csapatokkal dolgozzon , amelyek átveszik a teljes körű szolgáltatás felelősségét. Minden csapat egy jól meghatározott kontextusban működik, gyakran telepíthet, és teljes felelősséget vállal a szolgáltatásáért, csökkentve a fejlesztési ciklusidőt és felgyorsítva az új funkciók szállítását.
Egy másik fontos előny a szolgáltatásonkénti független skálázás . Nem kell túlméretezni a teljes alkalmazást, ha csak a katalógus, a pénztár vagy a nyilvános API forgalmi csúcsokat tapasztal. Minden mikroszolgáltatást vízszintesen vagy függőlegesen beállíthat a terhelési mintájának megfelelően, pontosan mérheti az egyes funkciók költségét, és fenntarthatja a rendelkezésre állást akkor is, ha egy adott területen megnő a fogyasztás.
Ezen szolgáltatások csomagolásának és telepítésének módja folyamatos, alacsony kockázatú megvalósítást tesz lehetővé . Az egyes mikroszolgáltatások különálló kiadása sokkal egyszerűbbé teszi az új ötletek tesztelését és a problémás verziók visszaállítását: a canary telepítések, a kék/zöld visszagörgetések és az automatizált visszagörgetések csökkentik a hibák költségeit, és teret biztosítanak a kísérletezésnek.
Technológiai szempontból a mikroszolgáltatások elősegítik a nyelvek, keretrendszerek és adatbázisok kiválasztásának szabadságát az egyes szolgáltatásokhoz. Nem minden igény fér bele ugyanabba a technológiai verembe: lehetnek üzleti szolgáltatásaink .NET-ben vagy Java-ban, adatfeldolgozás Scala/Sparkban, specializált szolgáltatások Pythonban vagy F#-ban, vagy mesterséges intelligencia mikroszolgáltatásaink R-ben. Ez a szabályozott diverzitás lehetővé teszi, hogy minden esetben a megfelelő eszközt használjuk anélkül, hogy a teljes alkalmazást globális technológiai váltásra kényszerítenénk.
Továbbá a rendszer apró, jól definiált darabokra bontása megkönnyíti a funkciók építőelemekként való újrafelhasználását . Egy kezdetben egy nagyobb funkcionalitás részeként létrehozott mikroszolgáltatás később a rendszer más részeinek függőségeként újrafelhasználható a logika átírása nélkül. És mivel a szolgáltatások elszigeteltek, az egyikük meghibásodása általában részleges rendszerromlást eredményez, nem pedig teljes rendszerleállást, feltéve, hogy a rugalmasságot kezdettől fogva tervezték.
Építészeti és szolgáltatástervezés
Ahhoz, hogy a mikroszolgáltatások jól működjenek éles környezetben, elengedhetetlen a szolgáltatáshatárok és felelősségi körök gondos megtervezése . A gyakorlatban ez általában a meglévő monoliton belüli durva részletességű szolgáltatások azonosításával kezdődik: ezek nagy funkcionális területek vagy üzleti tartományok (pl. megrendelések, katalógus, felhasználók, számlázás), amelyek már rendelkeznek némi logikai elkülönítéssel.
Ezekkel a nagy építőelemekkel kezdve a folyamat magában foglalja a terv finomítását, hogy olyan aprólékos mikroszolgáltatásokat kapjunk, amelyek egy koherens adathalmazon működnek , saját modellel rendelkeznek, és pontosan tudják, mit kell más szolgáltatásokból olvasniuk vagy oda írniuk. Ez a folyamat jellemzően a tartományvezérelt tervezési (DDD) koncepciókra és a korlátozott kontextusokra támaszkodik, megakadályozva, hogy egy mikroszolgáltatás „mini monolittá” váljon.
Az ezeket a szolgáltatásokat elérhetővé tevő API-knak jól definiált és stabil szerződésekkel kell rendelkezniük . Ez szigorú dokumentációt (REST OpenAPI-val, gRPC .proto fájlokkal stb.), explicit verziókezelést, a visszafelé kompatibilitás lehetőség szerinti fenntartását, valamint a szerződések érvényesítésének automatizálását jelenti a hibás változások éles környezetben való észlelése érdekében.
Több tucat vagy több száz szolgáltatást tartalmazó környezetekben kulcsfontosságú a rugalmassági minták beépítése a tervezési szakasztól kezdve, hogy a rendszer felkészült legyen a részleges hibákra . Az olyan minták, mint az áramkör-megszakítók, az újrapróbálkozások visszatartással, a jól meghatározott időtúllépések, a válaszfalak és az ellennyomás segítenek megakadályozni, hogy egy szolgáltatás meghibásodása a többit is leállítsa. A ChaosMonkey vagy a Gremlinhez hasonló káoszmérnöki eszközök hasznosak a platform szimulált kiesések esetén való viselkedésének gyakorlati teszteléséhez.
Sok összetett rendszer viszonylag egyszerű CRUD szolgáltatásokat kombinál kifinomultabbakkal, amelyek a változó üzleti szabályokat kezelik. Nem minden mikroszolgáltatás igényel összetett belső architektúrát : némelyik lehet egyszerű HTTP-vezérlő alapvető adathozzáféréssel, míg mások, például a rendelési vagy számlázási szolgáltatások, fejlettebb mintákat (DDD, CQRS, domain események stb.) tudnak kihasználni.
Éles infrastruktúra: felhő, konténerek és Kubernetes/OpenShift
A valós tapasztalatok azt mutatják, hogy a mikroszolgáltatások sokkal jobban teljesítenek, ha felhőalapú infrastruktúrán, konténerekkel és vezényléssel telepítik őket , mint elszigetelt virtuális gépeken. Az olyan platformok, mint a Kubernetes és az OpenShift, biztosítják a szükséges primitíveket a szolgáltatások konténerként történő csomagolásához, skálázásához, frissítéséhez, terheléselosztásához és a magas rendelkezésre állás kezeléséhez.
Általában minden mikroszolgáltatás egy konténerképbe van csomagolva, amely egy vállalati alapképen (például OpenJDK 21 Java szolgáltatásokhoz) alapul, és amelyet az infrastrukturális csapat kezel. Ezt az alapképet naprakészen tartják a biztonsági javításokkal, és amikor új verzió jelenik meg, a fejlesztőcsapatok felelősek a szolgáltatások újjáépítéséért és újbóli telepítéséért a megfelelő környezetekben.
A Kubernetes/OpenShiftben az alapvető telepítési egység a pod, amely egy vagy több konténert foglal magában . Egy mikroszolgáltatás jellemzően egy pod típusnak felel meg, és olyan erőforrások használatával telepíthető, mint a Deployments (állapot nélküli szolgáltatások esetén) vagy a StatefulSets (ha van társított állapot). Kezdettől fogva meghatároznak egy minimális replikaszámot környezetenként, hogy a tesztelési, az üzem előtti és az éles környezetek a kritikusságuknak megfelelő rendelkezésre állási szinttel rendelkezzenek.
Az automatikus skálázás a HorizontalPodAutoscaler (HPA) használatával valósul meg , amely a replikák számát olyan mérőszámok alapján állítja be, mint a CPU, a memória vagy más egyéni mérőszámok. A platformnak a pod affinitásgátló szabályait is konfigurálnia kell, hogy ugyanazon szolgáltatás replikáit különböző csomópontok között terjesszék el, megakadályozva, hogy egyetlen csomópont meghibásodása leállítsa az összes példányt.
A vertikális méretezést illetően a resources.requests és a resources.limits függvények segítségével definiálható a pod által felhasználható CPU- és memóriatartomány. Például minimum 100 MB CPU-t és 256 MB memóriát lehet lefoglalni, és legfeljebb 500 MB-ot, illetve 2 GB-ot engedélyezni egy Java szolgáltatás számára, a JVM-et (Xms, Xmx, Xss) pedig úgy kell beállítani, hogy a konténer erőforrásait a lehető legjobban kihasználja.
Állapotkezelés: állapot nélküli és állapotalapú mikroszolgáltatások
A legtöbb üzleti mikroszolgáltatás állapot nélküli szolgáltatásként van kialakítva . Ez azt jelenti, hogy a pod nem tárol olyan információkat, amelyeknek túl kell élniük az újraindítást; az állapot külső adatbázisokban, üzenetsorokban vagy más tárolókban marad. Ez a megközelítés lehetővé teszi a dinamikus horizontális skálázást és a súrlódásmentes telepítéseket, mivel bármely replika képes kezelni bármilyen kérést.
Vannak azonban olyan forgatókönyvek, amikor nincs más alternatíva, mint az állandó kötetek által támogatott állapotalapú mikroszolgáltatások . Ez a helyzet áll fenn egyes adatbázisok, elosztott fájlrendszerek vagy olyan komponensek esetében, amelyek helyi adatok karbantartását igénylik. Ezeket a podokat jellemzően StatefulSets-ekkel telepítik, PersistentVolumeClaims segítségével kapcsolják a PersistentVolumes-hez, és vertikálisan, nem pedig vízszintesen skálázódnak.
Amikor egy mikroszolgáltatásnak állandó tárhelyre van szüksége, a rendszer egy PersistentVolumeClaim (PVC) igénylést kér a méretével, hozzáférési módjával és tervezett felhasználásával , amelyet az operatív csapat a platformszabályzatoknak megfelelően kiépít. Erre a PVC-re hivatkoznak a telepítési jegyzékfájlban, és a podra csatolják, hogy a szolgáltatás állandóan olvashasson és írhasson adatokat.
Bár az állapotalapú modellek bizonyos esetekben szükségesek lehetnek, az általános ajánlás az, hogy a lehető legtöbb szolgáltatást állapotmentesen tartsuk . Ez leegyszerűsíti a telepítést, a skálázást, a rugalmasságot és a katasztrófa utáni helyreállítást, valamint csökkenti a működési bonyolultságot a sok mikroszolgáltatást tartalmazó környezetekben.
Adatdecentralizáció és szolgáltatásszuverenitás
A hagyományos infrastruktúrákban gyakori az adatbázisok és a tárolók központosítása a hatékonyság maximalizálása érdekében. A mikroszolgáltatások esetében ez a megközelítés ütközik a csapatok autonómiájával és a szétválasztással . Ha sok szolgáltatás ugyanazt a relációs sémát használja, bármilyen strukturális változás blokkolhatja több csapat működését, és akaratlanul is megzavarhatja a kompatibilitást.
Ezért az ajánlott gyakorlat az, hogy minden mikroszolgáltatás saját adatmodellel és adatbázissal rendelkezzen , bár fejlesztői környezetben ez az adatbázis konténerként fut a fürtön belül az üzembe helyezés egyszerűsítése érdekében. Éles környezetben jellemzően felhőalapú példányokat vagy más nagy rendelkezésre állású adatbázis-kiszolgálókat használnak, mindig egyértelmű tulajdonjogi határokat fenntartva.
Ez nem jelenti azt, hogy nincs adatintegráció; azt jelenti, hogy a szolgáltatások közötti konzisztenciát eseményekkel és aszinkron üzenetküldéssel kezelik , és ahol az ésszerű, elfogadják a végső konzisztenciát. Gyakori, hogy eseménybuszokat (RabbitMQ, Azure Service Bus, Kafka stb.) használnak az állapotváltozások mikroszolgáltatások közötti terjesztésére, csökkentve az egyetlen adatbázistól való erős függőségeket.
A felhőplatform megkönnyíti a csapatok számára az optimális adatbázistípus kiválasztását minden egyes szolgáltatáshoz (relációs, dokumentum, kulcs-érték, idősoros stb.) anélkül, hogy egyetlen technológiát kellene alkalmazni. A lényeg az, hogy a tervezés figyelembe vegye a sémák és struktúrák migrálásának lehetőségét más szolgáltatásokkal kötött szerződések felbontása nélkül, és hogy az adatdöntések az egyes mikroszolgáltatások tartományhatáraival összhangban szülessenek.
Megosztott irányítás, csapatok és szervezet
A mikroszolgáltatásokra való áttérés a szervezet megváltoztatása nélkül gondokkal jár. A hálózatok, rendszerek, adatbázisok, fejlesztés és üzemeltetés klasszikus funkcionális silói helyett a termékcsapatokon alapuló struktúrát javasolják, amely egyesíti a fejlesztés, a minőségbiztosítás, a DevOps és adott esetben az üzleti vagy adatelemzők profiljait.
Minden csapat egy vagy több mikroszolgáltatásért felelős ugyanazon a funkcionális tartományon belül, mind a fejlesztést, mind az üzemeltetést kezelve (te építed, te futtatod) . Ez azt jelenti, hogy a csapat kezeli a CI/CD folyamatait, együttműködik az infrastruktúrával az adott igények kielégítése érdekében, és részt vesz a monitorozásban és az incidensekre való reagálásban. Az infrastruktúra és a felhőplatform a közös és szabványosított szolgáltatások nyújtására összpontosít.
Annak érdekében, hogy ez az elosztott irányítás ne fusson anarchiába, kulcsfontosságú a könnyűsúlyú szabványok és a megosztott katalógusok meghatározása : jóváhagyott alaplemezképek, telepítési minták, névterek és szolgáltatások elnevezési konvenciói, API-irányelvek, Dockerfile és Kustomize sablonok stb. Ezek az irányelvek „védőkorlátként” szolgálnak, amelyek a csapatokat orientálják anélkül, hogy akadályoznák a döntéshozatali képességüket.
Sok vállalati környezetben minden projekthez vagy tartományhoz külön névtereket használnak , környezetenként (fejlesztés, előkészítés, éles környezet) legalább egyet. Egy nagy projekt a mikroszolgáltatásait több névtérben is eloszthatja, feltéve, hogy a belső kommunikáció megfelelően van konfigurálva és a biztonsági szabályokat betartják.
CI/CD, automatizálás és a GitOps modell
Amikor egy architektúra több tucat vagy több száz mikroszolgáltatást tartalmaz, a működőképességük fenntartásának egyetlen módja a teljes körű automatizálásba való jelentős befektetés . Ez magában foglalja a konzisztens CI/CD-folyamatokat, a deklaratív telepítési definíciókat, az automatizált tesztelést és az automatikus visszagörgetési mechanizmusokat.
Egy tipikus folyamatos integrációs és szállítási folyamat kezeli a kód fordítását, a tesztek futtatását, a minőség elemzését olyan eszközökkel, mint a SonarQube , a konténerkép felépítését a vállalati Dockerfile-ból, és a telepítési manifesztek frissítését. Innen egy rendszer, mint az ArgoCD vagy hasonló, GitOps megközelítéssel alkalmazza a módosításokat a klaszterre.
Minden mikroszolgáltatás-tárház jellemzően tartalmaz egy szabványosított Dockerfile-t, egy folyamatkonfigurációs fájlt (pl. ci.json) , minőségelemzési tulajdonságokat és egy telepítési könyvtárat, amely Kubernetes definíciókat (Kustomize vagy Helm) tartalmaz, környezetek szerint elkülönítve. A tárház webhookjai olyan események esetén indítják el a folyamatot, mint a címkeküldések vagy az egyesítési kérelmek.
A GitOps minta a Git repository-t határozza meg az infrastruktúra és a telepítések információforrásaként . A telepítések, szolgáltatások, konfigurációs térképek, PVC-k, SealedSecrets és egyéb erőforrások manifesztjei itt vannak verziózva, és speciális eszközök kezelik a klaszter állapotának szinkronizálását a Gitben definiáltakkal. Ez nyomon követhetőséget, pull request felülvizsgálatokat és egyszerű visszagörgetési lehetőségeket biztosít.
Beállítások, titkok és biztonság
Egy kiforrott mikroszolgáltatás-platformban a konfigurációkezelés a nem érzékeny paraméterek esetén ConfigMap-ekre, a bizalmas információk esetén pedig Secrets-re támaszkodik . Minden mikroszolgáltatásnak jellemzően saját környezetspecifikus ConfigMap-je van, amely olyan tulajdonságokat tárol, mint a függő szolgáltatások URL-címei, a funkcionalitásjelzők és a hangolási paraméterek.
A titkos adatokat (hitelesítő adatok, kulcsok, tokenek, tanúsítványok) szigorú biztonsági szabályzatok szerint kezeljük . Kevésbé kritikus környezetekben elfogadható lehet, ha azokat a fejlesztőcsapat által kezelt egyszerű szöveges formátumban tároljuk, de az üzem előtti és az éles környezetekben ajánlott titkosítani őket olyan eszközökkel, mint a Sealed Secrets vagy speciális felhőalapú külső kezelők.
Amikor egy titkos kulcsot több szolgáltatás között kell megosztani (például OTEL Collector hitelesítő adatok vagy egy közös kulcstár ), az névtérenként egy konfigurációs adattárban központosítható. A névteret megosztó projektek összehangoltan frissítik azt szükség szerint, így fenntartva az irányítást afelett, hogy ki olvashatja vagy módosíthatja ezeket az erőforrásokat.
A kommunikációs biztonság tekintetében a zéró bizalom domináns minta : semmi sem vesz magától értetődőnek pusztán azért, mert a forgalom "belső". A szolgáltatások közötti összes hívást, legyen az belső vagy külső, hitelesíteni és engedélyezni kell, ideális esetben mTLS, JWT tokenek vagy más azzal egyenértékű mechanizmusok használatával. A mikroszolgáltatások nem delegálják vakon a biztonságot az API-kezelőre vagy a hálózatra; ők is elvégzik a saját ellenőrzéseiket.
Kommunikáció a mikroszolgáltatások, API-k és üzenetküldés között
Egy kiforrott mikroszolgáltatás-architektúrában a kommunikációs réteg több esetre oszlik. Az ügyfelektől (böngészők, mobilalkalmazások, harmadik felek) a háttérrendszer felé irányuló forgalomhoz egy API-kezelő által irányított, közzétett API-kat használnak . Ezek az API-k jellemzően RESTful (gyakran OpenAPI-t használó) vagy bizonyos esetekben gRPC, amely egy átjárón keresztül érhető el.
Az azonos névtérben, vagy akár ugyanazon a projekten belül több névtérben található mikroszolgáltatások közötti hívásokat jellemzően belső Kubernetes szolgáltatások kezelik belső DNS-sel . Ezek a hívások megkerülik a nyilvános API-kezelőt, de betartják a biztonsági, hitelesítési és engedélyezési szabályzatokat. Ilyen esetekben használható egy szolgáltatásháló vagy belső átjárók, amelyek közös szabályzatokat érvényesítenek.
Amikor a mikroszolgáltatások különböző funkcionális tartományokhoz vagy projektekhez tartoznak , a kommunikáció szervezeti szinten „nyilvánosnak” tekinthető. Ezekben az esetekben bevett gyakorlat egy API-kezelő vagy egy interoperabilitási busz használata, ahol a szerződések, kvóták, biztonság, verziókövetés és naplózás kezelhető, megakadályozva a független klaszterek vagy névterek közötti közvetlen csatolást.
A régi vagy külső rendszerekkel való integráció tekintetében, amelyek nem mindig biztosítanak modern API-kat, gyakori, hogy specifikus csatlakozókra támaszkodnak egy interoperabilitási buszon keresztül . Így a mikroszolgáltatások közös nyelvet beszélnek (például események vagy belső REST API-k), és a csatlakozó kezeli a régi rendszerbe és onnan történő fordítást, mindig fokozott biztonsággal.
A szinkron kommunikáció mellett az aszinkron üzenetküldés kulcsszerepet játszik . A folyamatok szétválasztására, a túlfeszültségek elnyelésére, az üzleti események szolgáltatások közötti terjesztésére és a rugalmasság javítására szolgál. Minden eseményhez jellemzően jól meghatározott és verziózott sémák tartoznak, nyomon követési mechanizmusokkal, amelyek megakadályozzák a termelők és a fogyasztók közötti összeomlásokat a fejlődésük során.
Megfigyelhetőség, OTEL gyűjtő és működés
Egy számos mikroszolgáltatásból álló rendszerben szinte lehetetlen problémákat diagnosztizálni jó megfigyelhetőség nélkül. Ezért a metrikák, a központosított naplózás és az elosztott nyomkövetések már a tervezési szakasztól kezdve integrálva vannak , lehetővé téve a szolgáltatás- és platformszintű események megértését.
A rendszer központi eleme az OpenTelemetry Collector (OTEL Collector) , amely a névtérben vagy központilag telepítve van, hogy metrikákat, naplókat és nyomkövetéseket gyűjtsön az összes komponensről. A mikroszolgáltatásoknak csak azt kell tudniuk, hogy a telemetriájukat a Collectornak kell elküldeniük; a Collector ezután továbbítja azt a megfigyelhetőségi rendszereknek (Prometheus, Grafana, Jaeger, Elastic stb.) anélkül, hogy a szolgáltatásnak ismernie kellene a részleteket.
Az infrastruktúra réteg esetében csomópont-szintű gyűjtők és exportálók gyűjtik a CPU-, memória-, lemez-, hálózati és naplómetrikákat a podokból, majd elküldik azokat a Prometheusnak, illetve az Elasticsearchnek. Az olyan eszközök, mint a Grafana és a Kibana, vizualizálják ezeket az információkat, irányítópultokat hoznak létre, valamint riasztásokat definiálnak intelligens küszöbértékekkel és kapcsolódó runbookokkal.
Amikor egy projektnek nagyon specifikus metrikáinak vagy nyomkövetéseinek feldolgozására van szüksége, telepítheti az OTEL Collector saját példányát a névterében, feltéve, hogy rendelkezik működési jóváhagyással és az éles karbantartási modell egyértelmű.
Tesztelési stratégia, szerződések és helyi fejlesztési tapasztalatok
Egy elosztott mikroszolgáltatás-architektúra tesztelése kifinomultabb tesztelési stratégiát igényel, mint egy monolit tesztelése. Az egységtesztek továbbra is elengedhetetlenek, de a szerződéses tesztek (API-khoz és eseményekhez), a szolgáltatások közötti integrációs tesztek és a teljes folyamatokat bejáró, végponttól végpontig tartó tesztek egyre fontosabbá válnak.
A kompatibilitási problémák megelőzése érdekében olyan technikákat alkalmaznak, mint a fogyasztó-orientált szerződéstesztelés , ahol az ügyfelek meghatározzák az API-elvárásokat, a szolgáltatók pedig teljesítik azokat. Minden szerződésmódosítás automatikus tesztelésen megy keresztül a CI-folyamatokon belül, megakadályozva az ismert fogyasztókat sértő telepítéseket.
Amikor a szolgáltatások száma meghaladja a százat, a teljes rendszer helyi replikálása gyakorlatilag kivitelezhetetlenné válik. Ezért a fejlesztés a függő szolgáltatások szimulációira vagy távoli környezetekbe való alagútépítésre támaszkodik . A fejlesztők jellemzően csak a mikroszolgáltatások egy részét indítják el, a többit pedig ál-, hamisítvány- vagy szimulátorprogramokkal lepik meg, vagy bizonyos hívásokat átirányítanak egy megosztott integrációs környezetbe.
A teljes körű tesztelés egyre inkább a funkcióágakból létrehozott rövid távú környezetekre vagy „előnézetekre” támaszkodik , amelyek egy elszigetelt környezetet hoznak létre az adott funkcióhoz kapcsolódó szolgáltatásokkal. Ez minimalizálja a csapatok közötti súrlódást, csökkenti az „az én gépemen működik” hatást, és még a drágább környezetek, például az előkészítés elérése előtt észleli az integrációs problémákat.
Mikroszolgáltatások telepítési mintái éles környezetben
A Kubernetes-en túl számos olyan mikroszolgáltatás-telepítési minta létezik éles környezetben, amelyeket érdemes ismerni, mivel ezek az elszigeteltség, a költségek és az érettség különböző forgatókönyveit kezelik . Az egyik legrégebbi minta a több szolgáltatáspéldány hosztonként, ahol egyetlen fizikai vagy virtuális hoszt több különböző szolgáltatáspéldányt futtat, jellemzően egy megosztott alkalmazáskiszolgálón.
A virtuális gépenkénti szolgáltatáspéldány- mintában minden szolgáltatás virtuálisgép-rendszerképként van csomagolva (például egy EC2 AMI), és a saját példányán fut. Ez erős elszigeteltséget biztosít magasabb erőforrás-fogyasztás és lassabb indítási idők árán. Az olyan eszközök, mint a Packer vagy a felhőszolgáltató-specifikus megoldások megkönnyítik az éles üzemre kész virtuálisgép-rendszerképek létrehozását.
A legelterjedtebb minta napjainkban a konténerenkénti szolgáltatáspéldány , ahol minden mikroszolgáltatás konténerképként épül fel, és egy orchestratoron (Kubernetes, OpenShift stb.) van telepítve. A konténerek könnyebbek, mint a virtuális gépek, nagyon gyorsan elindulnak, és lehetővé teszik, hogy mindent becsomagoljunk, ami a szolgáltatáshoz szükséges, leegyszerűsítve a telepítéseket és lehetővé téve az automatikus skálázást.
Végül a szerver nélküli megközelítések, mint például az AWS Lambda , népszerűségre tettek szert. Ezek olyan függvényeket tartalmaznak, amelyek HTTP-kérésekre vagy más szolgáltatások (S3, DynamoDB, várólisták stb.) eseményeire válaszolnak, és a felhasználók csak azért fizetnek, amit használnak. Ez a minta különösen jól alkalmazható nagyon kis mikroszolgáltatásokhoz vagy rövid életű eseményvezérelt feladatokhoz, bár további szempontokat vezet be a megfigyelhetőséggel, a hidegindítással és a végrehajtási korlátokkal kapcsolatban.
A gyakorlatban sok szervezet hibrid ökoszisztémával rendelkezik: a rendszer magja konténereken és orkestrátorokon fut, míg bizonyos kiegészítő komponensek szerver nélküli függvényekként vagy specializált virtuális gépekként vannak megvalósítva, mindig egyértelmű interfészekkel és jól definiált protokollokkal, amelyekkel integrálhatók az egészbe.
Amikor mindezt éles környezetben szeretnénk megvalósítani, nem csak a választott technológia jelenti a különbséget, hanem egy olyan architektúra felépítése is, amely tolerálja a hibákat, szükség szerint skálázódik, automatikusan telepíthető és megfigyelhető . A termékhez igazított csapatoknak, a jól kezelt szerződéseknek, a decentralizált adatoknak és a robusztus felhőplatformnak köszönhetően a mikroszolgáltatások az ígéretből az összetett alkalmazások évekig tartó hatékony és fenntartható fejlesztési módjává válnak.