Microservice Architecture - Lær, opbyg og implementer mikroservices

Microservice-arkitektur:

Fra min , skal du have en grundlæggende forståelse af Microservice Architecture.Men at være professionel med kræver mere end bare det grundlæggende. I denne blog vil du komme i dybden med de arkitektoniske koncepter og implementere dem ved hjælp af en UBER-case study.

I denne blog lærer du om følgende:

hvad er en metode javascript

• Definition af mikroservicearkitektur
• Nøglebegreber for mikroservicearkitektur
• Fordele og ulemper ved mikroservicearkitektur
• UBER - Casestudie

Du kan henvise til , for at forstå de grundlæggende og fordele ved Microservices.

Det vil kun være fair, hvis jeg giver dig definitionen af ​​Microservices.

Definition af mikrotjenester

Som sådan er der ingen korrekt definition af Microservices aka Microservice Architecture, men du kan sige, at det er en ramme, der består af små, individuelt implementerbare tjenester, der udfører forskellige operationer.

Mikroservices fokuserer på et enkelt forretningsdomæne, der kan implementeres som fuldstændigt uafhængige implementerbare tjenester og implementere dem på forskellige teknologistakke.

Figur 1: Forskellen mellem monolitisk og mikroservicearkitektur - mikroservicearkitektur

Se diagrammet ovenfor for at forstå forskellen mellem monolitisk og mikroservicearkitektur.For en bedre forståelse af forskelle mellem begge arkitekturer kan du henvise til min tidligere blog

Lad mig fortælle dig nogle nøglebegreber inden for mikroservicearkitektur for at få dig til at forstå det bedre.

Nøglebegreber for mikroservicearkitektur

Før du begynder at opbygge dine egne applikationer ved hjælp af mikrotjenester, skal du være klar over omfanget og funktionerne i din applikation.

Følgende er nogle retningslinjer, der skal følges, når du diskuterer mikrotjenester.

Retningslinjer under design af mikrotjenester

• Når du beslutter dig for at opbygge en applikation som udvikler, skal du adskille domænerne og være klar over funktionaliteterne.
• Hver mikroservice, du designer, skal kun koncentrere sig om en applikationstjeneste.
• Sørg for, at du har designet applikationen på en sådan måde, at hver tjeneste kan distribueres individuelt.
• Sørg for, at kommunikationen mellem mikrotjenester sker via en statsløs server.
• Hver tjeneste kan videreføres til mindre tjenester med deres egne mikrotjenester.

Nu hvor du har læst de grundlæggende retningslinjer, mens du designer mikrotjenester, så lad os forstå mikrotjenesternes arkitektur.

Hvordan fungerer mikroservicearkitektur?

En typisk Microservice-arkitektur (MSA) skal bestå af følgende komponenter:

1. Kunder
2. Identitetsudbydere
3. Gateway API
4. Meddelelsesformater
5. Databaser
6. Statisk indhold
7. Ledelse
8. Serviceopdagelse

Se diagrammet nedenfor.

Figur 2: Architecture Of Microservices - Microservice Architecture

Jeg ved, at arkitekturen ser lidt kompleks ud, men lad det værejegforenkle det for dig.

1. Kunder

Arkitekturen starter med forskellige typer klienter, fra forskellige enheder, der prøver at udføre forskellige styringsfunktioner såsom søgning, opbygning, konfiguration osv.

2. Identitetsudbydere

Disse anmodninger fra klienterne sendes derefter til identitetsudbydere, der godkender anmodninger fra klienter og kommunikerer anmodningerne til API Gateway. Anmodningerne meddeles derefter til de interne tjenester via veldefineret API Gateway.

3. API-gateway

Da klienter ikke ringer direkte til tjenesterne, fungerer API Gateway som et indgangspunkt for klienterne til at videresende anmodninger til passende mikrotjenester.

Fordelene ved at bruge en API-gateway inkluderer:

• Alle tjenester kan opdateres uden at kunderne ved det.
• Tjenester kan også bruge beskedprotokoller, der ikke er webvenlige.
• API Gateway kan udføre tværgående funktioner såsom at give sikkerhed, belastningsafbalancering osv.

Efter modtagelse af anmodninger fra klienter består den interne arkitektur af mikrotjenester, der kommunikerer med hinanden via beskeder for at håndtere klientanmodninger.

4. Meddelelsesformater

Der er to typer meddelelser, hvorigennem de kommunikerer:

• Synkronbeskeder: I den situation, hvor klienter venter på svarene fra en tjeneste, har Microservices normalt en tendens til at bruge REST (repræsentativ statsoverførsel) da den er afhængig af en statsløs, klientserver og HTTP-protokol . Denne protokol bruges, da det er et distribueret miljø, hver funktionalitet er repræsenteret med en ressource til at udføre operationer
• Asynkrone meddelelser: I den situation, hvor klienter ikke venter på svar fra en tjeneste, har Microservices normalt en tendens til at bruge protokoller som f.eks AMQP, STOMP, MQTT . Disse protokoller bruges i denne type kommunikation, da meddelelsernes art er defineret, og disse meddelelser skal være interoperable mellem implementeringer.

Det næste spørgsmål, der kan komme til at tænke dig, er, hvordan håndterer de applikationer, der bruger Microservices, deres data?

5. Datahåndtering

Hver Microservice ejer en privat database til at indfange deres data og implementere den respektive forretningsfunktionalitet. Desuden opdateres Microservices databaser kun via deres service API. Se diagrammet nedenfor:

Figur 3: Repræsentation af mikrotjenester, der håndterer data - mikroservicearkitektur

De tjenester, der leveres af Microservices, overføres til enhver fjerntjeneste, der understøtter kommunikation mellem forskellige processer for forskellige teknologiestakke.

6. Statisk indhold

Efter at Microservices kommunikerer i sig selv, distribuerer de det statiske indhold til en skybaseret lagringstjeneste, der kan levere dem direkte til klienterne via Content Delivery Networks (CDN'er) .

hvad er char i java

Bortset fra ovenstående komponenter er der nogle andre komponenter, der vises i en typisk Microservices-arkitektur:

7. Ledelse

Denne komponent er ansvarlig for at balancere tjenesterne på noder og identificere fejl.

8. Opdagelse af service

Fungerer som en guide til mikroservices for at finde kommunikationsruten mellem dem, da den opretholder en liste over tjenester, som noder er placeret.

Abonner på vores youtube-kanal for at få nye opdateringer ..!

Lad os nu se på fordele og ulemper ved denne arkitektur for at få en bedre forståelse af, hvornår de skal bruge denne arkitektur.

Fordele og ulemper ved mikroservicearkitektur

Se nedenstående tabel.

Lad os forstå mere om Microservices ved at sammenligne UBERs tidligere arkitektur med den nuværende.

UBER CASE STUDIE

UBERs tidligere arkitektur

Som mange startups begyndte UBER sin rejse med en monolitisk arkitektur bygget til et enkelt tilbud i en enkelt by. At have en kodebase syntes at være renset på det tidspunkt og løste UBERs kerneforretningsproblemer. Da UBER begyndte at ekspandere over hele verden, stod de dog hårdt over for forskellige problemer med hensyn til skalerbarhed og kontinuerlig integration.

Figur 4: Monolitisk arkitektur af UBER - mikroservicearkitektur

Ovenstående diagram viser UBERs tidligere arkitektur.

• En REST API er til stede, som passager og fører forbinder.
• Tre forskellige adaptere bruges med API indeni dem til at udføre handlinger som fakturering, betalinger, afsendelse af e-mails / meddelelser, som vi ser, når vi bestiller en taxa.
• En MySQL-database til lagring af alle deres data.

Så hvis du bemærker her, blev alle funktionerne som passagerstyring, fakturering, underretningsfunktioner, betalinger, turstyring og chaufførstyring sammensat inden for en enkelt ramme.

Problemformulering

Mens UBER begyndte at ekspandere over hele verden, introducerede denne type rammer forskellige udfordringer. Følgende er nogle af de fremtrædende udfordringer

• Alle funktionerne skulle genopbygges, implementeres og testes igen og igen for at opdatere en enkelt funktion.
• Fix bugs blev ekstremt vanskelig i et enkelt arkiv, da udviklere måtte ændre koden igen og igen.
• Det var ret svært at skalere funktionerne samtidigt med introduktionen af ​​nye funktioner over hele verden.

Løsning

For at undgå sådanne problemer besluttede UBER at ændre sin arkitektur og følge de andre hypervækstvirksomheder som Amazon, Netflix, Twitter og mange andre. Således besluttede UBER at bryde sin monolitiske arkitektur i flere kodebaser for at danne en mikroservicearkitektur.

Se diagrammet nedenfor for at se på UBERs mikroservicearkitektur.

Figur 5: Microservice Architecture Of UBER - Microservice Architecture

• Den største ændring, som vi observerer her, er introduktionen af ​​API Gateway, hvor alle chauffører og passagerer er forbundet. Fra API Gateway er alle interne punkter forbundet som passagerstyring, chaufførstyring, turstyring og andre.
• Enhederne er individuelle separate implementerbare enheder, der udfører separate funktioner.
  • For eksempel: Hvis du vil ændre noget i faktureringsmikrotjenesterne, skal du bare installere kun faktureringsmikrotjenester og ikke behøver at distribuere de andre.
• Alle funktionerne blev nu skaleret individuelt, dvs. den indbyrdes afhængighed mellem hver eneste funktion blev fjernet.
  • For eksempel ved vi alle, at antallet af personer, der søger efter førerhuse, er forholdsvis mere end de mennesker, der faktisk bestiller en taxa og betaler. Dette får os en slutning om, at antallet af processer, der arbejder på passagerstyringsmikroservicen, er mere end antallet af processer, der arbejder med betalinger.

Herivej, UBER nydt godt af skiftdensarkitektur fra monolitisk til mikrotjenester.

Jeg håber, du har nydt at læse dette indlæg om Microservice Architecture.Jeg vil komme med flere blogs, som også indeholder hands-on.
Er du interesseret i at lære mere om mikrotjenester?

Hvis du ønsker at lære Microservices og oprette dine egne applikationer, så tjek vores som kommer med instruktørstyret live træning og projektoplevelse i det virkelige liv. Denne træning vil hjælpe dig med at forstå Microservices i dybden og hjælpe dig med at opnå mestring over emnet.

Har du et spørgsmål til os? Nævn det i kommentarfeltet i ” Microservice-arkitektur ”Og jeg vender tilbage til dig.