Mikroteenuste õpetus: mis on Architektuur ja näide

Mõiste "mikro" viitab mikroteenuse suuruse määramisele, mida peab hallata üks arendusmeeskond (5–10 arendajat). Selles metoodikas on suured rakendused jagatud väikseimateks sõltumatuteks üksusteks.

Mis on monoliit Architektuur?

Võhiku terminites võib öelda, et monoliitne arhitektuur on nagu suur konteiner, milles kõik rakenduse tarkvarakomponendid on koondatud ühte paketti.

Arutleme e-poe näitel monoliitse arhitektuuri kontekstis.

Igas e-kaubanduse rakenduses on mõned standardfunktsioonid, nagu otsing, Revvaade ja hinnangud ning maksed. Need funktsioonid on juurdepääsetavad klientidele, kes kasutavad oma brauserit või rakendusi. Kui e-kaubanduse saidi arendaja rakenduse juurutab, on see üks monoliitne üksus. kood erinevate funktsioonide jaoks, nagu otsing, Reveew & Ratings ja Payments asuvad samas serveris. Rakenduse skaleerimiseks peate käivitama nende rakenduste mitu eksemplari (serverit).

Monoliitses ArchiKõik komponendid ühinevad üheks mooduliks. Aga mikroteenustes Archistruktuuris on need jaotatud üksikuteks mooduliteks (mikroteenus), mis suhtlevad üksteisega, nagu on näidatud ülaltoodud mikroteenuste näites.

Mikroteenuste vaheline suhtlus on olekuta side, kus iga päringu ja vastuse paar on sõltumatu. Seega saavad mikroteenused pingevabalt suhelda. Mikroteenuses ArchiAndmed on ühendatud. Igal mikroteenusel on eraldi andmesalv. Järgmine selles Java Mikroteenuste õpetusest õpime tundma erinevust mikroteenuste ja monoliitse arhitektuuri vahel.

Mikroteenused vs monoliitsed Architektuur

Microservices	monoliitne Architektuur
Kogu rakenduse iga üksus peaks olema väikseim ja see peaks suutma ellu viia ühe konkreetse ärieesmärgi.	Üks koodibaas kõigi ärieesmärkide jaoks
Teenuse käivitamine on suhteliselt kiire	Teenuse käivitamine võtab rohkem aega
Vea isoleerimine on lihtne. Isegi kui üks teenus lakkab, võib teine ​​toimida jätkata.	Rikke isoleerimine on keeruline. Kui mõni konkreetne funktsioon ei tööta, läheb kogu süsteem alla. Selle probleemi lahendamiseks tuleb rakendus uuesti üles ehitada, uuesti testida ja ka uuesti juurutada.
Kõik mikroteenused peaksid olema lõdvalt ühendatud, et ühes tehtud muudatused ei mõjutaks teist.	Monoliitne arhitektuur on tihedalt seotud. Muudatused ühes koodimoodulis mõjutavad teist
Ettevõtted saavad kasutada rohkem ressursse teenustele, mis toovad suuremat ROI-d	Kuna teenused ei ole isoleeritud, ei ole ressursside individuaalne jaotamine võimalik
Sageli kasutatavale teenusele võiks eraldada rohkem riistvararessursse. Ülaltoodud e-kaubanduse näites kontrollib tooteloendit ja otsib maksetega võrreldes rohkem kasutajaid. Seega võiks otsingu ja tooteloendi mikroteenusele eraldada rohkem ressursse.	Rakenduste skaleerimine on nii keeruline kui ka raiskav.
Mikroteenused on alati järjepidevad ja pidevalt kättesaadavad.	Arendustööriistad on ülekoormatud, kuna protsess peab algama nullist.
Andmed on ühendatud. See võimaldab individuaalsel Microservice'il võtta kasutusele andmemudeli, mis vastab tema vajadustele kõige paremini.	Andmed on tsentraliseeritud.
Väikesed keskendunud meeskonnad. Paralleelne ja kiirem areng	Vaja on suurt meeskonda ja märkimisväärseid meeskonna juhtimise pingutusi
Ühe mikroteenuse andmemudeli muutmine ei mõjuta teisi mikroteenuseid.	Muutus andmemudelis mõjutab kogu andmebaasi
Suhtleb teiste mikroteenustega, kasutades täpselt määratletud liideseid	ei ole kohaldatav
Mikroteenused töötavad põhimõttel, mis keskendub toodetele, mitte projektidele	Pane rõhku kogu projektile
Koodialuste vahel ristsõltuvusi pole. Erinevate mikroteenuste jaoks saate kasutada erinevaid tehnoloogiaid.	Üks funktsioon või programm sõltub teistest.

Mikroteenuste väljakutsed

• MicroServices sõltuvad üksteisest ja nad peavad üksteisega suhtlema.
• Võrreldes monoliitsete süsteemidega on jälgimiseks rohkem teenuseid, mis on välja töötatud erinevatel viisidel programmeerimiskeeled.
• Kuna tegemist on hajutatud süsteemiga, on see oma olemuselt keeruline mudel.
• Erinevatel teenustel on oma eraldi mehhanism, mille tulemuseks on suur hulk mälu struktureerimata andmete jaoks.
• Kaskaadprobleemide vältimiseks on vajalik tõhus juhtimine ja meeskonnatöö
• Probleemi taasesitamine on keeruline ülesanne, kui see ühes versioonis on kadunud ja naaseb uusimas versioonis.
• Iseseisev juurutamine on mikroteenustega keeruline.
• Mikroteenuste arhitektuur toob kaasa palju toiminguid.

• Rakenduste haldamine on keeruline, kui süsteemi lisatakse uusi teenuseid
• Heterogeenselt jaotatud mikroteenuste toetamiseks on vaja laia valikut kvalifitseeritud spetsialiste
• Mikroteenus on kulukas, kuna erinevate äriülesannete jaoks on vaja hoida erinevat serveriruumi.

SOA vs mikroteenused

SOA-teenuseid haldab organisatsioonis register, mis toimib kataloogide loendina. Rakendused peavad teenused registrist üles otsima ja teenuse välja kutsuma.

Teises maailmas, SOA on nagu orkester, kus iga artist esineb oma pilliga, samal ajal kui muusikajuht annab kõigile juhiseid.

Teisest küljest on mikroteenused teenustele orienteeritud arhitektuuristiili vorm, kus rakendused on üles ehitatud erinevate väiksemate teenuste kogumina, mitte ühe tarkvara või rakendusena.

Microservices on täpselt nagu trupp, kus iga tantsija on sõltumatu ja teab, mida ta peab tegema. Seega, kui nad jätavad mõne sammu vahele, teavad nad, kuidas õigesse järjestusse tagasi jõuda. Nüüd selles Microservices arhitektuuri õpetuses õpime tundma SOA ja mikroteenuste erinevust.

Siin on üksikasjalik võrdlus SOA ja mikroteenuste vahel

Parameeter	SOA	Microservices
Disainitüüp	SOA-s on tarkvara komponendid teenuste kujul kasutamiseks avatud välismaailmale.	Micro Service on osa SOA-st. See on SOA rakendus.
Sõltuvus	Äriüksused on sõltuvad.	Nad on üksteisest sõltumatud.
Tarkvara suurus	Tarkvara maht on suurem kui mis tahes tavapärasel tarkvaral	Tarkvara suurus on Microservices alati väike
Tehnoloogia virn	Tehnoloogiapinn on Microservice'iga võrreldes madalam.	Mikroteenuste tehnoloogiapakk võib olla väga suur
Rakenduse olemus	Oma olemuselt monoliitne	Täielik virn looduses
Sõltumatu ja keskendunud	SOA-rakendused on loodud mitme äritegevuse täitmiseks.	Need on loodud ühe äriülesande täitmiseks.
Deployment	Kasutusprotsess on aeganõudev.	Juurutamine on lihtne ja vähem aeganõudev.
Kulud – tõhusus	Kuluefektiivsem.	Less kuluefektiivne.
Skaalautuvus	Less võrreldes mikroteenustega.	Väga skaleeritav.
Äriloogika	Äriloogika komponendid salvestatakse ühes teenusedomeenis Lihtsad juhtmeprotokollid (HTTP XML JSON-iga) API juhitakse SDK-de/klientidega	Äriloogika võib eksisteerida üle domeenide ettevõtte Service Bus nagu kihtide vahel teenuste vahevara

Mikroteenuste tööriistad

1) Wiremock: mikroteenuste testimine

WireMock on paindlik raamatukogu veebiteenuste stuubimiseks ja mõnitamiseks. See saab konfigureerida vastuse, mille HTTP API tagastab, kui ta saab konkreetse päringu. Seda kasutatakse ka mikroteenuste testimiseks.

Download link:http://wiremock.org/

2) Docker

Docker on avatud lähtekoodiga projekt, mis võimaldab meil konteinerite abil rakendusi luua, juurutada ja käitada. Neid konteinereid kasutades saavad arendajad käitada rakendust ühe paketina. See võimaldab saata teeke ja muid sõltuvusi ühes pakendis.

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

3) Hystrix

Hystrix on tõrketaluvusega Java raamatukogu. See tööriist on mõeldud kaugteenuste, süsteemide ja kolmanda osapoole teekide juurdepääsupunktide eraldamiseks hajutatud keskkonnas, näiteks mikroteenustes. See parandab üldist süsteemi, eraldades tõrgeteta teenused ja hoides ära rikete kaskaadefekti.

Lae Link:https://github.com/Netflix/Hystrix

Mikroteenuste parimad tavad Architektuur

• Iga mikroteenuse jaoks eraldi andmesalv
• Hoidke sarnase küpsusastmega kood.
• Iga mikroteenuse jaoks eraldi järg.
• Alati kohelda – tõsist kui kodakondsuseta.

kokkuvõte

• Mikroteenused on teenusele orienteeritud arhitektuurimuster, milles rakendused on üles ehitatud mitmesuguste väikseimate sõltumatute teenindusüksuste kogumina.
• Mikroteenus Architecture on arhitektuurne arendusstiil, mis võimaldab luua rakenduse ärivaldkonna jaoks välja töötatud väikeste autonoomsete teenuste kogumina.
• Monoliitne arhitektuur on nagu suur konteiner, milles kõik rakenduse tarkvarakomponendid on koondatud ühte paketti
• Mikroteenuses peaks kogu rakenduse iga üksus olema väikseim ja see peaks suutma saavutada ühe konkreetse ärieesmärgi
• Monoliitses arhitektuuris võib suur koodibaas kogu arendusprotsessi aeglustada. Uued väljaanded võivad kesta kuid. Koodi hooldamine on keeruline
• Kahte tüüpi mikroteenused on 1) kodakondsuseta 2) olekupõhised
• Mikroteenused sisse Java toetuda üksteisele ja nad peavad üksteisega suhtlema. Aitab teil rõhutada konkreetset funktsiooni ja ettevõtte vajadusi
• Teenusele orienteeritud arhitektuur, lühidalt tuntud kui SOA, on hajutatud andmetöötluse edasiarendus, mis põhineb päringu või vastuse disainimudelil sünkroonsete ja asünkroonsete rakenduste jaoks.
• SOA-s on tarkvarakomponendid teenuste kujul kasutamiseks avatud välismaailmale, samas kui Micro Service on SOA osa. See on SOA rakendus
• Wiremock, Docker ja Hystrix on mõned populaarsed mikroteenuste tööriistad