Mikropalveluiden opetusohjelma: Mikä on, Architecture ja esimerkki

Termi "mikro" viittaa mikropalvelun koon määrittämiseen, jonka on oltava yhden kehitystiimin (5–10 kehittäjää) hallittavissa. Tässä metodologiassa suuret sovellukset on jaettu pienimpiin itsenäisiin yksiköihin.

Mikä on monoliitti Architektuuri?

Maallikkotermeillä voidaan sanoa, että monoliittinen arkkitehtuuri on kuin iso kontti, jossa kaikki sovelluksen ohjelmistokomponentit on koottu yhdeksi paketiksi.

Keskustellaan esimerkistä verkkokauppakaupasta monoliittisen arkkitehtuurin yhteydessä.

Kaikissa verkkokauppasovelluksissa on joitain vakioominaisuuksia, kuten haku, Reviw & Ratings ja Payments. Nämä ominaisuudet ovat asiakkaiden käytettävissä selaimen tai sovellusten avulla. Kun verkkokauppasivuston kehittäjä ottaa sovelluksen käyttöön, se on yksi monoliittinen yksikkö. Koodi eri ominaisuuksille, kuten haku, Review & Ratings ja Payments ovat samalla palvelimella. Sovelluksen skaalaamiseksi sinun on suoritettava useita näiden sovellusten esiintymiä (palvelimia).

Monoliitissa ArchiTecture, kaikki komponentit sulautuvat yhdeksi moduuliksi. Mutta mikropalveluissa Archine on hajautettu yksittäisiksi moduuleiksi (mikropalvelu), jotka kommunikoivat keskenään, kuten yllä olevassa Microservices-esimerkissä on esitetty.

Mikropalvelujen välinen viestintä on tilatonta viestintää, jossa jokainen pyyntö- ja vastauspari on riippumaton. Näin ollen mikropalvelut voivat kommunikoida vaivattomasti. Mikropalvelussa Architieto on yhdistetty. Jokaisella mikropalvelulla on oma tietovarastonsa. Seuraavaksi tässä Java Microservices-opetusohjelma, opimme erosta mikropalvelujen ja monoliittisen arkkitehtuurin välillä.

Mikropalvelut vs. monoliitti Archirakenne

mikro Palvelut	yhtenäinen Archirakenne
Koko sovelluksen jokaisen yksikön tulee olla pienin, ja sen tulee pystyä saavuttamaan yksi tietty liiketoimintatavoite.	Yksi koodipohja kaikille liiketoimintatavoitteille
Palvelun käynnistys on suhteellisen nopeaa	Palvelun käynnistäminen vie enemmän aikaa
Vian eristäminen on helppoa. Vaikka yksi palvelu katkeaisi, toinen voi jatkaa toimintaansa.	Vian eristäminen on vaikeaa. Jos jokin tietty ominaisuus ei toimi, koko järjestelmä menee alas. Tämän ongelman ratkaisemiseksi sovellus on rakennettava uudelleen, testattava uudelleen ja myös otettava uudelleen käyttöön.
Kaikki mikropalvelut tulee kytkeä löyhästi, jotta yhteen tehdyt muutokset eivät vaikuta toiseen.	Monoliittinen arkkitehtuuri on tiiviisti kytketty. Muutokset yhdessä koodimoduulissa vaikuttavat toiseen
Yritykset voivat käyttää enemmän resursseja palveluihin, jotka tuottavat korkeamman sijoitetun pääoman tuottoprosentin	Koska palvelut eivät ole erillisiä, yksilöllinen resurssien allokointi ei ole mahdollista
Usein käytetylle palvelulle voitaisiin varata enemmän laitteistoresursseja. Yllä olevassa verkkokaupan esimerkissä useampi käyttäjä tarkistaa tuotetiedot ja tekee haun maksuihin verrattuna. Haku- ja tuotelistausmikropalveluun voitaisiin siis kohdentaa enemmän resursseja.	Sovellusten skaalaus on haastavaa ja tuhlattavaa.
Mikropalvelut ovat aina johdonmukaisia ​​ja jatkuvasti saatavilla.	Kehitystyökalut ovat ylikuormitettuja, koska prosessi on aloitettava alusta.
Tiedot on yhdistetty. Tämän ansiosta yksittäinen Microservice voi ottaa käyttöön tarpeisiinsa parhaiten sopivan tietomallin.	Tiedot on keskitetty.
Pienet keskittyneet tiimit. Rinnakkainen ja nopeampi kehitys	Vaatii suurta tiimiä ja huomattavaa tiiminhallintatyötä
Yhden Mikropalvelun tietomallin muutos ei vaikuta muihin mikropalveluihin.	Tietomallin muutos vaikuttaa koko tietokantaan
On vuorovaikutuksessa muiden mikropalvelujen kanssa käyttämällä hyvin määriteltyjä rajapintoja	Ei sovellettavissa
Mikropalvelut toimivat periaatteella, joka keskittyy tuotteisiin, ei projekteihin	Korosta koko projektia
Ei ristiriippuvuutta koodikantojen välillä. Voit käyttää eri tekniikoita eri mikropalveluissa.	Yksi toiminto tai ohjelma riippuu muista.

Mikropalveluhaasteet

• MicroServices ovat riippuvaisia ​​toisistaan, ja niiden on kommunikoitava keskenään.
• Verrattuna monoliittisiin järjestelmiin on valvottavana enemmän palveluita, joita kehitetään erilaisilla ohjelmointikielet.
• Koska se on hajautettu järjestelmä, se on luonnostaan ​​monimutkainen malli.
• Eri palveluilla on oma erillinen mekanisminsa, mikä johtaa suureen määrään muistia jäsentämättömälle tiedolle.
• Tehokasta hallintaa ja tiimityötä vaaditaan peräkkäisten ongelmien estämiseksi
• Ongelman toistaminen on vaikea tehtävä, kun se on poissa yhdessä versiossa ja tulee takaisin uusimmassa versiossa.
• Itsenäinen käyttöönotto on monimutkaista mikropalveluiden kanssa.
• Mikropalveluarkkitehtuuri tuo mukanaan runsaasti operaatioita.

• Sovelluksen hallinta on vaikeaa, kun järjestelmään lisätään uusia palveluita
• Heterogeenisesti hajautettujen mikropalvelujen tukemiseen tarvitaan laaja joukko ammattitaitoisia ammattilaisia
• Mikropalvelu on kallista, koska sinun on ylläpidettävä erilaista palvelintilaa eri liiketoimintatehtäviä varten.

SOA vs. mikropalvelut

SOA-palveluita ylläpitää organisaatiossa rekisteri, joka toimii hakemistolistauksena. Sovellusten täytyy etsiä palvelut rekisteristä ja kutsua palvelu.

Toisessa maailmassa, SOA on kuin orkesteri, jossa jokainen taiteilija esiintyy omalla instrumentillaan musiikinjohtajan ohjeistaessa kaikkia.

Toisaalta Microservices on eräänlainen palvelukeskeinen arkkitehtuurityyli, jossa sovellukset rakennetaan kokoelmaksi erilaisia ​​pienempiä palveluita yhden ohjelmiston tai sovelluksen sijaan.

Microservices on kuin seurue, jossa jokainen tanssija on itsenäinen ja tietää mitä pitää tehdä. Joten jos heiltä puuttuu joitain vaiheita, he tietävät, kuinka palata oikeaan järjestykseen. Tässä Microservices-arkkitehtuurin opetusohjelmassa opitaan SOA:n ja mikropalvelujen eroista.

Tässä on yksityiskohtainen vertailu SOA:n ja mikropalvelujen välillä

Parametri	SOA	mikro Palvelut
Suunnittelutyyppi	SOA:ssa ohjelmistokomponentit altistetaan ulkomaailmalle käytettäväksi palvelujen muodossa.	Micro Service on osa SOA:ta. Se on SOA:n toteutus.
riippuvuus	Liiketoimintayksiköt ovat riippuvaisia.	Ne ovat toisistaan ​​riippumattomia.
Ohjelmiston koko	Ohjelmiston koko on suurempi kuin mikään perinteinen ohjelmisto	Mikropalveluissa ohjelmiston koko on aina pieni
Teknologiapino	Teknologiapino on pienempi kuin Microservice.	Mikropalveluteknologiapino voi olla hyvin suuri
Sovelluksen luonne	Luonteeltaan monoliittinen	Täysi pino luonnossa
Itsenäinen ja keskittynyt	SOA-sovellukset on rakennettu suorittamaan useita liiketoiminnan tehtäviä.	Ne on suunniteltu suorittamaan yksittäinen liiketoimintatehtävä.
Käyttöönotto	Käyttöönottoprosessi on aikaa vievä.	Käyttöönotto on yksinkertaista ja vähemmän aikaa vievää.
Kustannustehokkuus	Kustannustehokkaampi.	Less kustannustehokas.
skaalautuvuus	Less verrattuna mikropalveluihin.	Erittäin skaalautuva.
Liikelogiikka	Liiketoimintalogiikkakomponentit on tallennettu yhden palvelualueen sisällä. Yksinkertaiset johtoprotokollat ​​(HTTP ja XML JSON) API ohjataan SDK:illa/asiakkailla	Liiketoimintalogiikka voi elää verkkotunnuksissa yrityksen Service Busissa, kuten palveluiden väliohjelmistokerroksissa

Mikropalvelutyökalut

1) Wiremock: Testing Microservices

WireMock on joustava kirjasto verkkopalveluiden tynkimiseen ja pilkkaamiseen. Se voi määrittää HTTP-sovellusliittymän palauttaman vastauksen, kun se vastaanottaa tietyn pyynnön. Sitä käytetään myös mikropalveluiden testaamiseen.

Download link:http://wiremock.org/

2) Telakka

Docker on avoimen lähdekoodin projekti, jonka avulla voimme luoda, ottaa käyttöön ja ajaa sovelluksia säiliöiden avulla. Näitä säilöjä käyttämällä kehittäjät voivat suorittaa sovelluksen yhtenä pakettina. Sen avulla voit lähettää kirjastoja ja muita riippuvuuksia yhdessä paketissa.

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

3) Hystrix

Hystrix on vikasietoinen Java-kirjasto. Tämä työkalu on suunniteltu erottamaan etäpalvelujen, järjestelmien ja kolmannen osapuolen kirjastojen käyttöpisteet hajautetussa ympäristössä, kuten Microservices. Se parantaa koko järjestelmää eristämällä vialliset palvelut ja estämällä vikojen kaskadivaikutuksen.

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

Mikropalveluiden parhaat käytännöt Archirakenne

• Erillinen tietovarasto jokaiselle mikropalvelulle
• Säilytä samanlainen koodi.
• Erillinen versio jokaiselle Micro-palvelulle.
• Kohtele aina – vakavaa valtiottomina.

Yhteenveto

• Microservices on palvelukeskeinen arkkitehtuurimalli, jossa sovellukset rakennetaan kokoelmaksi erilaisia ​​pienimpiä itsenäisiä palveluyksiköitä.
• Mikropalvelu Architecture on arkkitehtoninen kehitystyyli, joka mahdollistaa sovelluksen rakentamisen kokoelmana pieniä itsenäisiä palveluita, jotka on kehitetty yritysalueelle.
• Monoliittinen arkkitehtuuri on kuin iso kontti, jossa kaikki sovelluksen ohjelmistokomponentit on koottu yhdeksi paketiksi
• Mikropalvelussa koko sovelluksen jokaisen yksikön tulee olla pienin ja sen tulee pystyä saavuttamaan yksi tietty liiketoimintatavoite
• Monoliittisessa arkkitehtuurissa suuri koodikanta voi hidastaa koko kehitysprosessia. Uudet julkaisut voivat kestää kuukausia. Koodin ylläpito on vaikeaa
• Kahden tyyppisiä mikropalveluita ovat 1) valtiottomat 2) tilalliset
• Mikropalvelut sisään Java luottavat toisiinsa, ja heidän on kommunikoitava keskenään. Auttaa sinua korostamaan tiettyä ominaisuutta ja liiketoiminnan tarpeita
• Palvelukeskeinen arkkitehtuuri, joka tunnetaan lyhyesti SOA:na, on hajautetun laskennan evoluutio, joka perustuu pyyntö- tai vastaussuunnittelumalliin synkronisille ja asynkronisille sovelluksille.
• SOA:ssa ohjelmistokomponentit altistetaan ulkomaailmalle käytettäväksi palveluina, kun taas Micro Service on osa SOA:ta. Se on SOA:n toteutus
• Wiremock, Docker ja Hystrix ovat suosittuja Microservices-työkaluja