Microservice Architecture - Lær, bygg og distribuer mikrotjenester

Microservice Architecture:

Fra min , må du ha en grunnleggende forståelse av Microservice Architecture.Men å være profesjonell med vil kreve mer enn bare det grunnleggende. I denne bloggen vil du komme i dybden med de arkitektoniske konseptene og implementere dem ved hjelp av en UBER-casestudie.

I denne bloggen vil du lære om følgende:

• Definisjon av mikroservicearkitektur
• Nøkkelbegreper for mikroservicearkitektur
• Fordeler og ulemper med mikroservicearkitektur
• UBER - Case Study

Du kan henvise til , for å forstå det grunnleggende og fordelene med Microservices.

Det vil bare være rettferdig hvis jeg gir deg definisjonen av Microservices.

Definisjon av mikrotjenester

Som sådan er det ingen riktig definisjon av Microservices aka Microservice Architecture, men du kan si at det er et rammeverk som består av små, individuelt distribuerbare tjenester som utfører forskjellige operasjoner.

Microservices fokuserer på et enkelt forretningsdomene som kan implementeres som helt uavhengige distribuerbare tjenester og implementere dem på forskjellige teknologibunker.

Figur 1: Forskjellen mellom monolitisk og mikroservicearkitektur - mikroservicearkitektur

Se diagrammet ovenfor for å forstå forskjellen mellom monolitisk og mikroservicearkitektur.For en bedre forståelse av forskjeller mellom begge arkitekturer, kan du henvise til min forrige blogg

For å få deg til å forstå bedre, la meg fortelle deg noen viktige begreper innen mikroservicearkitektur.

Nøkkelbegreper for mikroservicearkitektur

Før du begynner å bygge dine egne applikasjoner ved hjelp av mikrotjenester, må du være klar over omfanget og funksjonene til applikasjonen din.

Følgende er noen retningslinjer som skal følges når du diskuterer mikrotjenester.

Retningslinjer når du designer mikrotjenester

• Når du bestemmer deg for å bygge en applikasjon, skal du som utvikler skille domenene og være tydelig med funksjonalitetene.
• Hver mikrotjeneste du designer, skal bare konsentrere seg om en tjeneste for applikasjonen.
• Forsikre deg om at du har designet applikasjonen på en slik måte at hver tjeneste kan distribueres individuelt.
• Sørg for at kommunikasjonen mellom mikrotjenester skjer via en statsløs server.
• Hver tjeneste kan videreføres til mindre tjenester, med egne mikrotjenester.

Nå som du har lest gjennom de grunnleggende retningslinjene mens du designer mikrotjenester, la oss forstå arkitekturen til mikrotjenester.

Hvordan fungerer mikroservicearkitektur?

En typisk Microservice Architecture (MSA) bør bestå av følgende komponenter:

1. Kunder
2. Identitetsleverandører
3. Gateway API
4. Meldingsformater
5. Databaser
6. Statisk innhold
7. Ledelse
8. Service Discovery

Se diagrammet nedenfor.

er en vs har en java

Figur 2: Architecture Of Microservices - Microservice Architecture

Jeg vet at arkitekturen ser litt kompleks ut, men la detJegforenkle det for deg.

1. Kunder

Arkitekturen starter med forskjellige typer klienter, fra forskjellige enheter som prøver å utføre forskjellige administrasjonsmuligheter som søk, bygg, konfigurer etc.

2. Identitetsleverandører

Disse forespørslene fra klientene sendes deretter videre til identitetsleverandørene som autentiserer forespørslene fra klientene og kommuniserer forespørslene til API Gateway. Forespørslene blir deretter kommunisert til de interne tjenestene via veldefinert API Gateway.

3. API-gateway

kan du lage en rekke objekter i java

Siden klienter ikke ringer til tjenestene direkte, fungerer API Gateway som et inngangspunkt for klientene til å videresende forespørsler til passende mikrotjenester.

Fordelene ved å bruke en API-gateway inkluderer:

• Alle tjenestene kan oppdateres uten at kundene vet det.
• Tjenester kan også bruke meldingsprotokoller som ikke er nettvennlige.
• API Gateway kan utføre tverrgående funksjoner som å gi sikkerhet, lastbalansering etc.

Etter å ha mottatt forespørsler fra klienter, består den interne arkitekturen av mikrotjenester som kommuniserer med hverandre gjennom meldinger for å håndtere klientforespørsler.

4. Meldingsformater

Det er to typer meldinger de kommuniserer gjennom:

• Synkrone meldinger: I en situasjon der klienter venter på svarene fra en tjeneste, pleier Microservices å bruke REST (representativ statsoverføring) da den er avhengig av en statsløs klient-server og HTTP-protokoll . Denne protokollen brukes ettersom det er et distribuert miljø hver funksjonalitet er representert med en ressurs for å utføre operasjoner
• Asynkrone meldinger: I en situasjon der klienter ikke venter på svarene fra en tjeneste, pleier Microservices å bruke protokoller som f.eks AMQP, STOMP, MQTT . Disse protokollene brukes i denne typen kommunikasjon siden karakteren av meldinger er definert og disse meldingene må være interoperable mellom implementeringer.

Det neste spørsmålet du kan tenke deg er hvordan applikasjonene som bruker Microservices håndterer dataene sine?

5. Datahåndtering

Vel, hver Microservice eier en privat database for å fange opp dataene sine og implementere den respektive forretningsfunksjonaliteten. Dessuten oppdateres databasene til Microservices kun via deres API for tjenester. Se diagrammet nedenfor:

Figur 3: Representasjon av mikrotjenester som håndterer data - mikroservicearkitektur

Tjenestene som tilbys av Microservices blir videreført til enhver ekstern tjeneste som støtter kommunikasjon mellom prosesser for forskjellige teknologibunker.

6. Statisk innhold

Etter at Microservices kommuniserer i seg selv, distribuerer de det statiske innholdet til en skybasert lagringstjeneste som kan levere dem direkte til klientene via Content Delivery Networks (CDNs) .

Bortsett fra komponentene ovenfor, er det noen andre komponenter som vises i en typisk Microservices Architecture:

7. Ledelse

Denne komponenten er ansvarlig for å balansere tjenestene på noder og identifisere feil.

8. Service Discovery

Fungerer som en guide til mikrotjenester for å finne ruten for kommunikasjon mellom dem, da den fører en liste over tjenester som noder ligger.

Abonner på youtube-kanalen vår for å få nye oppdateringer ..!

La oss nå se på fordeler og ulemper med denne arkitekturen for å få en bedre forståelse av når du skal bruke denne arkitekturen.

Fordeler og ulemper med Microservice Architecture

Se tabellen nedenfor.

La oss forstå mer om Microservices ved å sammenligne UBERs tidligere arkitektur med den nåværende.

UBER CASE STUDIE

UBERs tidligere arkitektur

Som mange oppstart startet UBER reisen med en monolitisk arkitektur bygget for et enkelt tilbud i en enkelt by. Å ha en kodebase virket renset på den tiden, og løste UBERs kjernevirksomhetsproblemer. Da UBER begynte å utvide seg over hele verden, møtte de imidlertid ulike problemer med hensyn til skalerbarhet og kontinuerlig integrasjon.

Figur 4: Monolitisk arkitektur av UBER - Microservice Architecture

Ovenstående diagram viser UBERs tidligere arkitektur.

hva er jit i java

• En REST API er tilstede som passasjer og sjåfør kobler seg til.
• Tre forskjellige adaptere brukes med API i dem, for å utføre handlinger som fakturering, betaling, sending av e-post / meldinger som vi ser når vi bestiller en drosje.
• En MySQL-database for å lagre alle dataene deres.

Så hvis du merker her, var alle funksjonene som passasjeradministrasjon, fakturering, varslingsfunksjoner, betalinger, turadministrasjon og sjåføradministrasjon sammensatt innenfor ett rammeverk.

Problemstilling

Mens UBER begynte å utvide seg over hele verden, introduserte denne typen rammeverk forskjellige utfordringer. Følgende er noen av de fremtredende utfordringene

• Alle funksjonene måtte bygges om, distribueres og testes igjen og igjen for å oppdatere en enkelt funksjon.
• Å fikse feil ble ekstremt vanskelig i et enkelt depot da utviklere måtte endre koden igjen og igjen.
• Å skalere funksjonene samtidig med introduksjonen av nye funksjoner over hele verden var ganske vanskelig å håndtere sammen.

Løsning

For å unngå slike problemer besluttet UBER å endre arkitekturen og følge de andre hypervekstbedriftene som Amazon, Netflix, Twitter og mange andre. Dermed besluttet UBER å bryte sin monolitiske arkitektur i flere kodebaser for å danne en mikroservicearkitektur.

Se diagrammet nedenfor for å se på UBERs mikrotjenestearkitektur.

Figur 5: Microservice Architecture Of UBER - Microservice Architecture

• Den største endringen vi observerer her er introduksjonen av API Gateway der alle sjåfører og passasjerer er koblet. Fra API Gateway er alle interne punkter koblet sammen som passasjerdrift, sjåføradministrasjon, turledelse og andre.
• Enhetene er individuelle separate distribuerbare enheter som utfører separate funksjoner.
  • For eksempel: Hvis du vil endre noe i faktureringsmikrotjenestene, må du bare distribuere faktureringsmikrotjenester og ikke trenger å distribuere de andre.
• Alle funksjonene ble nå skalert individuelt, dvs. avhengigheten mellom hver eneste funksjon ble fjernet.
  • For eksempel vet vi alle at antallet personer som søker etter drosjer er mer relativt mer enn de som faktisk bestiller drosje og betaler. Dette får oss en slutning om at antall prosesser som arbeider med passasjertilsynets mikroservice er mer enn antall prosesser som jobber med betalinger.

I dettevei, UBER hadde fordel av å skiftedet erarkitektur fra monolitisk til mikrotjenester.

Jeg håper du har likt å lese dette innlegget på Microservice Architecture.Jeg kommer med flere blogger, som også inneholder praktisk.
Interessert i å lære mer om mikrotjenester?

Hvis du ønsker å lære Microservices og bygge dine egne applikasjoner, så sjekk ut vår som kommer med instruktørledet live-opplæring og reell prosjektopplevelse. Denne opplæringen vil hjelpe deg med å forstå Microservices i dybden og hjelpe deg med å mestre emnet.

Har du et spørsmål til oss? Vennligst nevn det i kommentarfeltet til ” Microservice Architecture ”Og jeg kommer tilbake til deg.