Microservices Tutorial: Hva er, Architecture og eksempel

⚡ Smart oppsummering

Mikrotjenester er et tjenesteorientert arkitekturmønster der en applikasjon er bygget som en samling av små, uavhengige tjenesteenheter. Denne ressursen forklarer monolittisk kontra mikrotjenestearkitektur, deres forskjeller, utfordringer, SOA-sammenligning, populære verktøy og beste praksis.

  • 🧩 Kjernekonsept: Mikrotjenester deler opp en applikasjon i enkeltfunksjonelle, uavhengig distribuerbare moduler, som hver eies av et lite team på 5 til 10 utviklere.
  • 📦 Monolittisk kontrast: En monolittisk applikasjon samler alle funksjoner i én pakke på én server, så skalering betyr å kjøre flere fullstendige kopier.
  • 🏗️ Mikroservice Archilære: Hver tjeneste håndterer én forretningsfunksjon, kjører på sin egen instans og kommuniserer gjennom lette, tilstandsløse protokoller.
  • 🗄️ Forbundne data: Hver mikrotjeneste eier sitt eget datalager, så en endring i én tjenestes datamodell påvirker ikke de andre.
  • 🛠️ Verktøy og praksis: Verktøy som WireMock, Docker og Hystrix støtter testing, distribusjon og feiltoleranse; hold hver tjeneste tilstandsløs med sin egen build.

Opplæring i mikrotjenester

Hva er mikrotjenester?

Microservices er et tjenesteorientert arkitekturmønster der applikasjoner bygges som en samling av forskjellige minste uavhengige tjenesteenheter. Det er en software engineering tilnærming som fokuserer på å dekomponere en applikasjon i enkeltfunksjonsmoduler med veldefinerte grensesnitt. Disse modulene kan distribueres uavhengig og drives av små team som eier hele livssyklusen til tjenesten.

Begrepet «mikro» refererer til størrelsen på en mikrotjeneste, som må kunne håndteres av et enkelt utviklingsteam (5 til 10 utviklere). I denne metodikken deles store applikasjoner inn i de minste uavhengige enhetene.

Hva er monolittisk Archilære?

Enkelt forklart kan man si at monolittisk arkitektur er som en stor beholder der alle programvarekomponentene i et program er samlet i én pakke. La oss diskutere et eksempel på en e-handelsbutikk i konteksten av en monolittisk arkitektur.

Monolithic Architecture of eCommerce Application

Monolithic Architecture of eCommerce Application

I alle e-handelsapplikasjoner er det noen standardfunksjoner som søk, RevVisninger og vurderinger, og betalinger. Disse funksjonene er tilgjengelige for kunder som bruker nettleseren eller appene sine. Når utvikleren av e-handelsnettstedet distribuerer applikasjonen, er det én enkelt monolittisk enhet. Koden for forskjellige funksjoner som søk, RevVisninger og vurderinger, og betalinger er på samme server. For å skalere applikasjonen må du kjøre flere instanser (servere) av disse applikasjonene.

Hva er Microservice Archilære?

Mikroservice Architecture er en arkitektonisk utviklingsstil som tillater å bygge applikasjoner som en samling av små autonome tjenester utviklet for et forretningsdomene. Det er en variant av strukturell stilarkitektur som hjelper til med å arrangere applikasjoner som en løst koblet tjenestesamling. Mikrotjenesten Architecture inneholder finmaskede tjenester og lette protokoller.

La oss ta et eksempel på en e-handelsapplikasjon utviklet med mikrotjenestearkitektur. I dette eksemplet på mikrotjenestearkitektur er hver mikrotjeneste fokusert på én enkelt forretningsfunksjon. Søk, vurdering og Review og Payment har hver sin instans (server) og kommuniserer med hverandre.

Microservices Architecture

Microservices Architecture

I det monolittiske Architekstur, alle komponentene samles i én enkelt modul. Men i Microservices ArchiTeknologi er de spredt i individuelle moduler (mikrotjenester) som kommuniserer med hverandre, som vist i mikrotjenester-eksemplet ovenfor.

Kommunikasjonen mellom mikrotjenester er en statsløs kommunikasjon der hvert par av forespørsel og svar er uavhengige. Derfor kan mikrotjenester kommunisere uanstrengt. I mikrotjenesten ArchiTeknologi, dataene er samlet. Hver mikrotjeneste har sitt eget datalager.

Mikrotjenester vs. monolittisk Architecture

MicroservicesMonolithic Architecture
Hver enhet i hele applikasjonen skal være den minste, og den skal kunne levere ett spesifikt forretningsmål.Én enkelt kodebase for alle forretningsmål.
Oppstart av tjenesten går relativt raskt.Oppstart av tjenesten tar lengre tid.
Det er enkelt å isolere feil. Selv om én tjeneste går ned, kan andre fortsette å fungere.Feilisolering er vanskelig. Hvis en spesifikk funksjon ikke fungerer, går hele systemet ned. For å håndtere dette problemet må applikasjonen bygges på nytt, testes på nytt og distribueres på nytt.
Alle mikrotjenester bør være løst koblet sammen, slik at endringer gjort i den ene ikke påvirker den andre.Monolittisk arkitektur er tett koblet sammen. Endringer i én kodemodul påvirker den andre.
Bedrifter kan bruke flere ressurser på tjenester som genererer høyere avkastning.Siden tjenester ikke er isolerte, er det ikke mulig å fordele individuelle ressurser.
Flere maskinvareressurser kan allokeres til tjenesten som brukes ofte. I e-handelseksemplet ovenfor sjekker flere brukere produktlisten og søker sammenlignet med betalinger, slik at flere ressurser kan allokeres til mikrotjenesten for søk og produktliste.Applikasjonsskalering er utfordrende så vel som bortkastet.
Mikrotjenester forblir alltid konsistente og kontinuerlig tilgjengelige.Utviklingsverktøy blir overbelastet ettersom prosessen må starte på nytt.
Data er samlet. Dette lar individuelle mikrotjenester ta i bruk en datamodell som passer best til deres behov.Data er sentralisert.
Små fokuserte team. Parallell og raskere utvikling.Det kreves et stort team og betydelig innsats fra teamledelsen.
Endring i datamodellen til én mikrotjeneste påvirker ikke andre mikrotjenester.Endring i datamodellen påvirker hele databasen.
Samhandler med andre mikrotjenester ved å bruke veldefinerte grensesnitt.Ikke aktuelt.
Mikrotjenester fungerer etter prinsippet om å fokusere på produkter, ikke prosjekter.Legger vekt på hele prosjektet.
Ingen kryssavhengigheter mellom kodebaser. Du kan bruke forskjellige teknologier for forskjellige mikrotjenester.En funksjon eller et program avhenger av andre.

Mikroserviceutfordringer

  • Mikrotjenester er avhengige av hverandre, og de må kommunisere med hverandre.
  • Sammenlignet med monolittiske systemer, er det flere tjenester å overvåke som er utviklet med forskjellige programmerings språk.
  • Siden det er et distribuert system, er det en iboende kompleks modell.
  • Ulike tjenester vil ha sine egne mekanismer, noe som resulterer i en stor mengde minne for ustrukturerte data.
  • Effektiv ledelse og samarbeid er nødvendig for å forhindre kaskadeproblemer.
  • Å reprodusere et problem vil være en vanskelig oppgave når det er borte i én versjon og kommer tilbake i den nyeste versjonen.
  • Uavhengig distribusjon er komplisert med mikrotjenester.
  • Mikrotjenestearkitektur gir mange operasjoner overhead.
  • Det er vanskelig å administrere applikasjonen når nye tjenester legges til systemet.
  • Et bredt spekter av dyktige fagfolk er nødvendig for å støtte heterogent distribuerte mikrotjenester.
  • Mikroservice er kostbart, ettersom du trenger å opprettholde forskjellig serverplass for forskjellige forretningsoppgaver.

SOA vs. mikrotjenester

SOA-tjenester vedlikeholdes i organisasjonen av et register som fungerer som en katalogliste. Applikasjoner må slå opp tjenestene i registeret og starte tjenesten. Med andre ord, SOA er akkurat som et orkester der hver artist opptrer med sitt instrument mens musikksjefen gir instruksjoner til alle.

På den andre siden er Microservices en form for tjenesteorientert arkitekturstil der applikasjoner er bygget som en samling av forskjellige mindre tjenester i stedet for én programvare eller applikasjon. Microservices er akkurat som en tropp der hver danser er uavhengig og vet hva de trenger å gjøre. Så hvis de går glipp av noen trinn, vet de hvordan de skal komme tilbake til riktig rekkefølge. Her er en detaljert sammenligning mellom SOA og Microservices.

ParameterSOAMicroservices
Design typeI SOA blir programvarekomponenter eksponert mot den ytre verden for bruk i form av tjenester.Micro Service er en del av SOA. Det er en implementering av SOA.
AvhengighetForretningsenheter er avhengige.De er uavhengige av hverandre.
Størrelsen på programvarenProgramvarestørrelsen er større enn all konvensjonell programvare.Størrelsen på programvaren er alltid liten i Microservices.
Teknologi StackTeknologistabelen er lavere sammenlignet med Microservice.Microservice teknologistabel kan være veldig stor.
Søknadens artMonolitisk av natur.Full stabel i naturen.
Selvstendig og fokusertSOA-applikasjoner er bygget for å utføre flere forretningsoppgaver.De er bygget for å utføre én enkelt forretningsoppgave.
UtplasseringDistribusjonsprosessen er tidkrevende.Implementeringen er enkel og mindre tidkrevende.
Kostnadseffektivitet Mer kostnadseffektivt.Less kostnadseffektiv.
skalerbarhetLess sammenlignet med Microservices.Svært skalerbar.
ForretningslogikkForretningslogikkkomponenter lagres i et enkelt tjenestedomene, med enkle kablede protokoller (HTTP med XML eller JSON) og API-drevet med SDK-er/klienter.Forretningslogikk kan leve på tvers av domener, med lag mellom tjenester (Middleware) som ligner på enterprise Service Bus.

Microservices-verktøy

1) Wiremock: Testing av mikrotjenester

WireMock er et fleksibelt bibliotek for stubbing og mocking av webtjenester. Det kan konfigurere svaret som returneres av HTTP API-et når det mottar en spesifikk forespørsel. Det brukes også til testing av mikrotjenester.

Last ned link: http://wiremock.org/

2) Havnearbeider

Docker er et åpen kildekode-prosjekt som lar oss opprette, distribuere og kjøre applikasjoner ved hjelp av containere. Ved å bruke disse containerne kan utviklere kjøre en applikasjon som én pakke. Det lar deg sende biblioteker og andre avhengigheter i én pakke.

Last ned link: https://www.docker.com/

3) Hystrix

Hystrix er en feiltoleranse Java bibliotek. Dette verktøyet er utviklet for å separere tilgangspunkter til eksterne tjenester, systemer og tredjepartsbiblioteker i et distribuert miljø som Microservices. Det forbedrer det overordnede systemet ved å isolere de sviktende tjenestene og forhindre kaskadeeffekten av feil.

Last ned Link: https://github.com/Netflix/Hystrix

Beste praksis for mikrotjenester Architecture

  • Separat datalager for hver mikrotjeneste.
  • Hold koden på et lignende modenhetsnivå.
  • Separat bygg for hver mikrotjeneste.
  • Behandle alltid hver server som statsløs.

Spørsmål og svar

AI-funksjoner pakkes ofte som individuelle mikrotjenester, slik at applikasjoner kan kalle en modell over et API uten å bygge den inn. AI driver også intelligent ruting, autoskalering og avviksdeteksjon på tvers av mange tjenester.

Ja. AI-drevne observasjonsverktøy korrelerer logger, målinger og tracpå tvers av tjenester for å oppdage feil, forutsi flaskehalser og finne rotårsaken raskere enn manuell analyse i et stort distribuert system.

Mikrotjenester klassifiseres vanligvis som tilstandsløse og tilstandsfulle. Tilstandsløse mikrotjenester beholder ikke data mellom forespørsler, mens tilstandsfulle mikrotjenester opprettholder data- eller øktstatus, ofte støttet av sitt eget dedikerte datalager.

Store teknologiselskaper som Netflix, Amazon, Uber og Spotify bruke mikrotjenester til å skalere uavhengig og distribuere ofte. Tilnærmingen passer for skybaserte applikasjoner med mye trafikk som trenger raske, isolerte utgivelser.

Oppsummer dette innlegget med: