Microservices Tutorial: Hva er, Architecture og eksempel

Begrepet "mikro" refererer til størrelsen på en mikrotjeneste som må kunne administreres av et enkelt utviklingsteam (5 til 10 utviklere). I denne metodikken er store applikasjoner delt inn i de minste uavhengige enhetene.

Hva er monolittisk Archilære?

I lekmannstermer kan du si at monolittisk arkitektur er som en stor beholder der alle programvarekomponentene til en applikasjon er samlet i en enkelt pakke.

La oss diskutere et eksempel på en e-handelsbutikk i sammenheng med en monolittisk arkitektur.

I alle e-handelsapplikasjoner er det noen standardfunksjoner som søk, Review & Rangeringer og Betalinger. Disse funksjonene er tilgjengelige for kunder som bruker nettleseren eller appene deres. Når utvikleren av e-handelssiden distribuerer applikasjonen, er det en enkelt monolittisk enhet. Koden for forskjellige funksjoner som søk, Review og vurderinger og betalinger er på samme server. For å skalere applikasjonen må du kjøre flere forekomster (servere) av disse applikasjonene.

I det monolittiske Architecture, samles alle komponentene til en enkelt modul. Men i Microservices Archide er spredt i individuelle moduler (microservice) som kommuniserer med hverandre som vist i Microservices-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 Architecture, er dataene forent. Hver mikrotjeneste har sitt separate datalager. Neste i dette Java Microservices tutorial, vi vil lære om forskjellen mellom Microservices og monolittisk arkitektur.

Mikrotjenester vs. monolittisk Architecture

Microservices	Monolithic Architecture
Hver enhet i hele applikasjonen skal være den minste, og den skal kunne levere ett spesifikt forretningsmål.	En enkelt kodebase for alle forretningsmål
Tjenesten oppstart er relativt rask	Oppstart av tjenesten tar lengre tid
Feilisolering er enkelt. Selv om en 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 også distribueres på nytt.
Alle mikrotjenester bør være løst koblet slik at endringer som gjøres i den ene ikke påvirker den andre.	Monolittisk arkitektur er tett koblet. Endringer i en kodemodul påvirker den andre
Bedrifter kan distribuere flere ressurser til tjenester som genererer høyere avkastning	Siden tjenester ikke er isolert, er individuell ressursallokering ikke mulig
Flere maskinvareressurser kan tildeles tjenesten som brukes ofte. I e-handelseksemplet ovenfor sjekker flere brukere produktoppføringen og søker sammenlignet med betalinger. Så flere ressurser kan allokeres til søke- og produktoppføringsmikrotjenesten.	Applikasjonsskalering er utfordrende så vel som bortkastet.
Mikrotjenester forblir alltid konsistente og kontinuerlig tilgjengelige.	Utviklingsverktøy blir overbelastet ettersom prosessen må starte fra bunnen av.
Data er forent. Dette gjør at individuelle Microservice kan ta i bruk en datamodell som passer best for deres behov.	Data er sentralisert.
Små fokuserte team. Parallell og raskere utvikling	Stort team og betydelig teamledelsesinnsats er nødvendig
Endring i datamodellen til én mikrotjeneste påvirker ikke andre mikrotjenester.	Endring i datamodell påvirker hele databasen
Samhandler med andre mikrotjenester ved å bruke veldefinerte grensesnitt	Ikke aktuelt
Mikrotjenester jobber etter prinsippet som fokuserer på produkter, ikke prosjekter	Legg 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

• MicroServices 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 sin separate mekanisme, noe som resulterer i en stor mengde minne for ustrukturerte data.
• Effektiv ledelse og teamarbeid kreves for å forhindre overlappende problemer
• Å 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 Microservices.
• 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 katalogoppføring. Applikasjoner må slå opp tjenestene i registeret og påkalle tjenesten.

I en annen verden, SOA er akkurat som et orkester der hver artist opptrer med sitt instrument mens musikksjefen gir instruksjoner til alle.

På den andre enden er Microservices en form for tjenesteorientert arkitekturstil der applikasjoner bygges 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. La oss nå i denne Microservices-arkitekturopplæringen lære om forskjellen mellom SOA og Microservices.

Her er en detaljert sammenligning mellom SOA og Microservices

Parameter	SOA	Microservices
Design type	I 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.
Avhengighet	Forretningsenheter er avhengige.	De er uavhengige av hverandre.
Størrelsen på programvaren	Programvarestørrelsen er større enn noen konvensjonell programvare	Størrelsen på programvaren er alltid liten i Microservices
Teknologi Stack	Teknologistabelen er lavere sammenlignet med Microservice.	Microservice teknologistabel kan være veldig stor
Søknadens art	Monolitisk i naturen	Full stabel i naturen
Selvstendig og fokusert	SOA-applikasjoner er bygget for å utføre flere forretningsoppgaver.	De er bygget for å utføre én enkelt forretningsoppgave.
Utplassering	Implementeringsprosessen er tidkrevende.	Implementeringen er enkel og mindre tidkrevende.
Kostnad – effektivitet	Mer kostnadseffektivt.	Less kostnadseffektiv.
skalerbarhet	Less sammenlignet med Microservices.	Svært skalerbar.
Forretningslogikk	Forretningslogikkkomponenter lagres inne i enkelt tjenestedomene Enkle ledningsprotokoller (HTTP med XML JSON) API er drevet med SDK-er/klienter	Forretningslogikk kan leve på tvers av domener Enterprise Service Bus som lag mellom tjenester mellomvare

Microservices-verktøy

1) Wiremock: Testing av mikrotjenester

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

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

2) Havnearbeider

Docker er åpen kildekode-prosjekt som lar oss lage, distribuere og kjøre applikasjoner ved å bruke containere. Ved å bruke disse beholderne kan utviklere kjøre en applikasjon som en enkelt pakke. Den lar deg sende biblioteker og andre avhengigheter i én pakke.

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

3) Hystrix

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

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

Beste praksis for mikrotjenester Architecture

• Separat datalager for hver mikrotjeneste
• Hold koden på samme modenhetsnivå.
• Separat bygg for hver mikrotjeneste.
• Behandle alltid - alvorlig som statsløs.

Sammendrag

• Microservices er et tjenesteorientert arkitekturmønster der applikasjoner bygges som en samling av forskjellige minste uavhengige tjenesteenheter.
• Mikroservice Architecture er en arkitektonisk utviklingsstil som gjør det mulig å bygge en applikasjon som en samling av små autonome tjenester utviklet for et forretningsdomene.
• Monolittisk arkitektur er som en stor beholder der alle programvarekomponentene til en applikasjon er samlet i en enkelt pakke
• I en mikrotjeneste bør hver enhet i hele applikasjonen være den minste, og den bør kunne levere ett spesifikt forretningsmål
• I monolittisk arkitektur kan stor kodebase bremse hele utviklingsprosessen. Nye utgivelser kan ta måneder. Kodevedlikehold er vanskelig
• To typer mikrotjenester er 1) Stateless 2) Stateful
• Mikrotjenester i Java stole på hverandre, og de må kommunisere med hverandre. Hjelper deg med å legge vekt på en spesifikk funksjon og forretningsbehov
• Tjenesteorientert arkitektur, kort kjent som SOA, er en utvikling av distribuert databehandling basert på designmodellen for forespørsel eller svar for synkrone og asynkrone applikasjoner
• I SOA blir programvarekomponenter utsatt for den ytre verden for bruk i form av tjenester, mens Micro Service er en del av SOA. Det er en implementering av SOA
• Wiremock, Docker og Hystrix er noen populære Microservices-verktøy