Mikroszolgáltatások bemutatója: Mi az, Architecture és példa

Mik azok a mikroszolgáltatások?

Mikro szolgáltatások egy szolgáltatás-orientált architektúra-minta, amelyben az alkalmazások különböző legkisebb független szolgáltatási egységek gyűjteményeként épülnek fel. Ez egy szoftverfejlesztés megközelítés, amely egy alkalmazás egyfunkciós modulokra bontására összpontosít, jól definiált interfésszel. Ezeket a modulokat önállóan telepíthetik és működtethetik a szolgáltatás teljes életciklusát birtokló kis csapatok.

A „mikro” kifejezés egy mikroszolgáltatás méretezésére utal, amelyet egyetlen fejlesztőcsapatnak (5-10 fejlesztő) kell kezelnie. Ebben a módszertanban a nagy alkalmazásokat a legkisebb független egységekre osztják.

Mi az a monolit Architectúra?

Közérthetően fogalmazva, a monolitikus architektúra olyan, mint egy nagy konténer, amelyben egy alkalmazás összes szoftverkomponense egyetlen csomagba van sűrítve. Nézzünk meg egy e-kereskedelmi áruház példáját a monolitikus architektúra kontextusában.

Monolitikus ArchiAz e-kereskedelmi alkalmazás felépítése

Bármely e-kereskedelmi alkalmazásban van néhány szabványos funkció, mint például a Keresés, RevMegtekintések és értékelések, valamint Fizetések. Ezek a funkciók böngészőjükön vagy alkalmazásaikon keresztül érhetők el az ügyfelek számára. Amikor az e-kereskedelmi webhely fejlesztője telepíti az alkalmazást, az egyetlen monolitikus egység. A különböző funkciók, például a Keresés kódja RevA View & Ratings, valamint a Payments ugyanazon a szerveren található. Az alkalmazás skálázásához több példányt (szervert) kell futtatni ezekből az alkalmazásokból.

Mi az a Microservice Architectúra?

Mikroszolgáltatás Architectúra egy olyan építészeti fejlesztési stílus, amely lehetővé teszi alkalmazások létrehozását kis önálló szolgáltatások gyűjteményeként, amelyeket üzleti tartományra fejlesztettek ki. Ez a szerkezeti stílusú architektúra egy változata, amely segít az alkalmazások lazán összekapcsolt szolgáltatásgyűjteményként való elrendezésében. A mikroszolgáltatás ArchiA tecture finomszemcsés szolgáltatásokat és könnyű protokollokat tartalmaz.

Vegyünk egy példát egy mikroszolgáltatás-architektúrával fejlesztett e-kereskedelmi alkalmazásra. Ebben a mikroszolgáltatás-architektúra példában minden mikroszolgáltatás egyetlen üzleti képességre összpontosít. Keresés, Értékelés és RevAz iew és a Payment mindegyikének megvan a saját példánya (szervere), és kommunikálnak egymással.

Mikro szolgáltatások Architectúra

A monolitban Archistruktúrában az összes komponens egyetlen modulba egyesül. De a mikroszolgáltatásokban ArchiA struktúrában különálló modulokra (mikroszolgáltatásokra) vannak szétosztva, amelyek kommunikálnak egymással, ahogy az a fenti mikroszolgáltatási példában is látható.

A mikroszolgáltatások közötti kommunikáció állapot nélküli kommunikáció, ahol minden kérés és válasz pár független. Így a mikroszolgáltatások könnyedén tudnak kommunikálni. A Mikroszolgáltatásban ArchiA struktúrában az adatok összevont módon vannak jelen. Minden mikroszolgáltatásnak külön adattárolója van.

Mikroszolgáltatások kontra monolit Architectúra

Mikro szolgáltatások	Monolitikus Architectúra
A teljes alkalmazás minden egységének a legkisebbnek kell lennie, és képesnek kell lennie egy konkrét üzleti cél megvalósítására.	Egyetlen kódbázis minden üzleti célhoz.
A szolgáltatás indítása viszonylag gyors.	A szolgáltatás indítása több időt vesz igénybe.
A hibák elkülönítése egyszerű. Még ha egy szolgáltatás ki is áll, a többi továbbra is működhet.	A hibák elkülönítése nehéz. Ha bármelyik funkció nem működik, a teljes rendszer leáll. A probléma kezeléséhez az alkalmazást újra kell építeni, újra tesztelni és újra telepíteni.
Minden mikroszolgáltatást lazán kell összekapcsolni, hogy az egyikben végrehajtott módosítások ne befolyásolják a másikat.	A monolitikus architektúra szorosan összekapcsolt. Az egyik kódmodulban végrehajtott változtatások hatással vannak a másikra.
A vállalkozások több erőforrást fordíthatnak olyan szolgáltatásokra, amelyek magasabb megtérülést generálnak.	Mivel a szolgáltatások nem elszigeteltek, az egyedi erőforrás-elosztás nem lehetséges.
Több hardver erőforrást lehetne allokálni a gyakran használt szolgáltatáshoz. A fenti e-kereskedelmi példában több felhasználó ellenőrzi a terméklistát és keres, mint fizetés, így több erőforrást lehetne allokálni a keresési és terméklistázási mikroszolgáltatáshoz.	Az alkalmazások méretezése kihívást jelent, és pazarló is.
A mikroszolgáltatások mindig konzisztensek és folyamatosan elérhetőek maradnak.	A fejlesztőeszközök túlterhelődnek, mivel a folyamatot a nulláról kell kezdeni.
Az adatok összevont módon működnek. Ez lehetővé teszi az egyes mikroszolgáltatások számára, hogy az igényeiknek leginkább megfelelő adatmodellt alkalmazzák.	Az adatok központosítva vannak.
Kis, fókuszált csapatok. Párhuzamos és gyorsabb fejlesztés.	Nagy csapatra és jelentős csapatvezetési erőfeszítésre van szükség.
Az egyik Mikroszolgáltatás adatmodelljének változása nem érinti a többi Mikroszolgáltatást.	Az adatmodell változása a teljes adatbázist érinti.
Jól definiált interfészek használatával kommunikál más mikroszolgáltatásokkal.	Nem alkalmazható.
A mikroszolgáltatások azon az elven működnek, hogy a termékekre, nem pedig a projektekre összpontosítanak.	A hangsúlyt a teljes projektre helyezi.
Nincsenek keresztfüggőségek a kódalapok között. A különböző mikroszolgáltatásokhoz különböző technológiákat használhat.	Egy funkció vagy program másoktól függ.

Mikroszolgáltatási kihívások

• A mikroszolgáltatások egymásra támaszkodnak, és kommunikálniuk kell egymással.
• A monolitikus rendszerekhez képest több olyan szolgáltatást kell felügyelni, amelyeket különböző módon fejlesztettek ki programozási nyelvek.
• Mivel elosztott rendszerről van szó, eleve összetett modellről van szó.
• A különböző szolgáltatásoknak külön mechanizmusuk lesz, ami nagy mennyiségű memóriát eredményez a strukturálatlan adatok számára.
• Hatékony irányításra és csapatmunkára van szükség a problémák odáig fajulásának megelőzéséhez.
• Egy probléma reprodukálása nehéz feladat lesz, ha az egyik verzióban már nem létezik, majd a legújabb verzióban újra megjelenik.
• A független telepítés bonyolult a mikroszolgáltatások esetében.
• A mikroszolgáltatási architektúra rengeteg műveletet jelent.
• Nehéz kezelni az alkalmazást, amikor új szolgáltatásokat adnak hozzá a rendszerhez.
• A heterogén módon elosztott mikroszolgáltatások támogatásához széles körű, képzett szakemberekre van szükség.
• A mikroszolgáltatás költséges, mivel a különböző üzleti feladatokhoz különböző szerverterületet kell fenntartani.

SOA kontra mikroszolgáltatások

A SOA szolgáltatásokat a szervezetben egy nyilvántartás tartja karban, amely címtárlistaként működik. Az alkalmazásoknak meg kell keresniük a szolgáltatásokat a nyilvántartásban, és meg kell hívniuk azokat. Más szóval, SOA olyan, mint egy zenekar, ahol minden művész a saját hangszerével lép fel, miközben a zeneigazgató utasításokat ad mindenkinek.

Másrészt a mikroszolgáltatások egy szolgáltatásorientált architektúra, amelyben az alkalmazások különböző kisebb szolgáltatások gyűjteményeként épülnek fel egyetlen szoftver vagy alkalmazás helyett. A mikroszolgáltatások olyanok, mint egy társulat, ahol minden táncos független és tudja, mit kell tennie. Tehát, ha kihagynak néhány lépést, tudják, hogyan térjenek vissza a helyes sorrendhez. Íme egy részletes összehasonlítás a SOA és a mikroszolgáltatások között.

Vizsgált paraméter	SOA	Mikro szolgáltatások
Tervezési típus	A SOA-ban a szoftverösszetevők ki vannak téve a külvilágnak, hogy szolgáltatás formájában használják őket.	A Micro Service a SOA része. Ez a SOA megvalósítása.
Függőség	Az üzleti egységek függőek.	Függetlenek egymástól.
A szoftver mérete	A szoftver mérete nagyobb, mint bármely hagyományos szoftveré.	A szoftver mérete mindig kicsi a mikroszolgáltatásokban.
Technológiai verem	A technológiai stack alacsonyabb a Microservice-hez képest.	A mikroszolgáltatási technológiai halom nagyon nagy lehet.
Az alkalmazás jellege	Monolitikus jellegű.	Teljes verem a természetben.
Független és fókusz	A SOA-alkalmazások több üzleti feladat elvégzésére készültek.	Egyetlen üzleti feladat elvégzésére készültek.
bevetés	A telepítési folyamat időigényes.	A telepítés egyszerű és kevésbé időigényes.
Költséghatékonyság	Költséghatékonyabb.	Less költséghatékony.
Bővíthetőség	Less a Mikroszolgáltatásokhoz képest.	Nagyon skálázható.
Üzleti logika	Az üzleti logikai komponensek egyetlen szolgáltatástartományon belül tárolódnak, egyszerű vezetékprotokollokkal (HTTP XML-lel vagy JSON-nal) és SDK-kkal/kliensekkel vezérelt API-kkal.	Az üzleti logika több tartományon átívelően is működhet, a szolgáltatások között vállalati Service Bus-szerű rétegekkel (Middleware).

Mikroszolgáltatások Eszközök

1) Wiremock: Mikroszolgáltatások tesztelése

WireMock egy rugalmas függvénykönyvtár webszolgáltatások csonkolásához és mockolásához. Beállíthatja a HTTP API által visszaadott választ, amikor egy adott kérést kap. Mikroszolgáltatások tesztelésére is használják.

Download link: http://wiremock.org/

2) Docker

A Docker egy nyílt forráskódú projekt, amely lehetővé teszi alkalmazások létrehozását, telepítését és futtatását konténerek segítségével. Ezen konténerek használatával a fejlesztők egyetlen csomagként futtathatják az alkalmazásokat. Lehetővé teszi a könyvtárak és más függőségek egyetlen csomagban történő szállítását.

Download link: https://www.docker.com/

3) Hystrix

A Hystrix egy hibatűrő Java könyvtár. Ez az eszköz a távoli szolgáltatások, rendszerek és harmadik féltől származó könyvtárak hozzáférési pontjainak elkülönítésére szolgál egy elosztott környezetben, például a Microservices-ben. Javítja az általános rendszert azáltal, hogy elkülöníti a hibás szolgáltatásokat és megakadályozza a hibák kaszkádszerű hatását.

Letöltés Link: https://github.com/Netflix/Hystrix

A mikroszolgáltatások legjobb gyakorlatai Architectúra

• Külön adattároló minden mikroszolgáltatáshoz.
• Tartsd a kódot hasonló érettségi szinten.
• Külön build minden egyes mikroszolgáltatáshoz.
• Mindig kezelje az egyes szervereket állapot nélküliként.

GYIK