Microservice Architecture - Lär dig, bygg och distribuera mikrotjänster

Microservice Architecture:

Från min måste du ha en grundläggande förståelse för Microservice Architecture.Men att vara professionell med kräver mer än bara grunderna. I den här bloggen kommer du att fördjupa dig i arkitekturkoncepten och implementera dem med en UBER-fallstudie.

I den här bloggen lär du dig om följande:

• Definition av Microservice-arkitektur
• Nyckelbegrepp för Microservice-arkitektur
• För- och nackdelar med Microservice-arkitektur
• UBER - Fallstudie

Du kan hänvisa till , för att förstå grunderna och fördelarna med Microservices.

Det kommer bara att vara rättvist om jag ger dig definitionen av Microservices.

Definition av mikrotjänster

Som sådan finns det ingen riktig definition av Microservices aka Microservice Architecture, men du kan säga att det är ett ramverk som består av små, individuellt distribuerbara tjänster som utför olika operationer.

Mikrotjänster fokuserar på en enda företagsdomän som kan implementeras som helt oberoende distribuerbara tjänster och implementera dem på olika teknikstackar.

Figur 1: Skillnaden mellan monolitisk och mikroservicearkitektur - mikroservicearkitektur

Se diagrammet ovan för att förstå skillnaden mellan monolitisk och mikroservicearkitektur.För en bättre förståelse av skillnader mellan båda arkitekturerna kan du hänvisa till min tidigare blogg

För att få dig att förstå bättre, låt mig berätta några viktiga begrepp inom mikroservicearkitekturen.

Nyckelbegrepp för Microservice-arkitektur

Innan du börjar bygga dina egna applikationer med mikrotjänster måste du vara tydlig med tillämpningens omfattning och funktioner.

Nedan följer några riktlinjer som ska följas när man diskuterar mikrotjänster.

Riktlinjer vid utformning av mikrotjänster

• Som utvecklare, när du bestämmer dig för att bygga en applikation, separera domänerna och vara tydliga med funktionerna.
• Varje mikrotjänst du utformar ska endast koncentrera sig på en tjänst i applikationen.
• Se till att du har utformat applikationen på ett sådant sätt att varje tjänst kan distribueras individuellt.
• Se till att kommunikationen mellan mikrotjänster sker via en statslös server.
• Varje tjänst kan vidareutvecklas till mindre tjänster med sina egna mikrotjänster.

Nu när du har läst igenom de grundläggande riktlinjerna när du utformar mikrotjänster, låt oss förstå strukturen för mikrotjänster.

Hur fungerar Microservice Architecture?

En typisk Microservice-arkitektur (MSA) bör bestå av följande komponenter:

1. Kunder
2. Identitetsleverantörer
3. Gateway API
4. Meddelandeformat
5. Databaser
6. Statiskt innehåll
7. Förvaltning
8. Service Discovery

Se diagrammet nedan.

Figur 2: Architecture Of Microservices - Microservice Architecture

Jag vet att arkitekturen ser lite komplex ut, men låtJagförenkla det för dig.

1. Kunder

Arkitekturen börjar med olika typer av klienter, från olika enheter som försöker utföra olika hanteringsfunktioner som att söka, bygga, konfigurera etc.

2. Identitetsleverantörer

Dessa förfrågningar från klienterna skickas sedan vidare till identitetsleverantörerna som autentiserar förfrågningar från klienter och kommunicerar förfrågningarna till API Gateway. Förfrågningarna kommuniceras sedan till de interna tjänsterna via väldefinierad API-gateway.

3. API-gateway

Eftersom klienter inte ringer direkt till tjänsterna fungerar API Gateway som en startpunkt för klienterna att vidarebefordra förfrågningar till lämpliga mikrotjänster.

Fördelarna med att använda en API-gateway inkluderar:

• Alla tjänster kan uppdateras utan att klienterna vet det.
• Tjänster kan också använda meddelandeprotokoll som inte är webbvänliga.
• API Gateway kan utföra tvärgående funktioner som att tillhandahålla säkerhet, lastbalansering etc.

Efter att ha mottagit förfrågningar från klienter består den interna arkitekturen av mikrotjänster som kommunicerar med varandra genom meddelanden för att hantera klientförfrågningar.

4. Meddelandeformat

Det finns två typer av meddelanden genom vilka de kommunicerar:

• Synkrona meddelanden: I en situation där kunder väntar på svaren från en tjänst brukar Microservices bruka använda REST (representativ statsöverföring) eftersom det är beroende av en statslös klient-server och HTTP-protokoll . Detta protokoll används eftersom det är en distribuerad miljö varje funktion representeras med en resurs för att utföra operationer
• Asynkrona meddelanden: I en situation där klienter inte väntar på svaren från en tjänst tenderar Microservices vanligtvis att använda protokoll som AMQP, STOMP, MQTT . Dessa protokoll används i denna typ av kommunikation eftersom meddelandets natur definieras och dessa meddelanden måste vara interoperabla mellan implementeringar.

Nästa fråga som kan komma att tänka på dig är hur applikationerna som använder Microservices hanterar deras data?

5. Datahantering

Varje Microservice äger en privat databas för att fånga in sina data och implementera respektive affärsfunktionalitet. Dessutom uppdateras Microservices databaser endast via deras service-API. Se diagrammet nedan:

Figur 3: Representation av mikrotjänster som hanterar data - mikroservicearkitektur

Tjänsterna som tillhandahålls av Microservices överförs till alla fjärrtjänster som stöder kommunikation mellan olika processer för olika teknikstackar.

6. Statiskt innehåll

Efter att Microservices kommunicerar inom sig själva distribuerar de det statiska innehållet till en molnbaserad lagringstjänst som kan leverera dem direkt till klienterna via Innehållsleveransnätverk (CDN) .

Förutom ovanstående komponenter finns det några andra komponenter som visas i en typisk Microservices-arkitektur:

7. Ledning

Denna komponent ansvarar för att balansera tjänsterna på noder och identifiera fel.

8. Upptäck service

Fungerar som en guide till mikrotjänster för att hitta kommunikationsvägen mellan dem eftersom den upprätthåller en lista över tjänster på vilka noder finns.

Prenumerera på vår youtube-kanal för att få nya uppdateringar ..!

Låt oss nu titta på för- och nackdelarna med denna arkitektur för att få en bättre förståelse för när du ska använda den här arkitekturen.

För- och nackdelar med Microservice Architecture

Se tabellen nedan.

Låt oss förstå mer om Microservices genom att jämföra UBERs tidigare arkitektur med den nuvarande.

UBER CASE STUDY

UBERs tidigare arkitektur

Som många startups började UBER sin resa med en monolitisk arkitektur byggd för ett enda erbjudande i en enda stad. Att ha en kodbas verkade städas vid den tiden och löste UBER: s kärnverksamhetsproblem. Men när UBER började expandera över hela världen mötte de rigoröst olika problem med avseende på skalbarhet och kontinuerlig integration.

sortera funktion c ++ array

Figur 4: Monolitisk arkitektur av UBER - Microservice Architecture

Ovanstående diagram visar UBERs tidigare arkitektur.

• Det finns ett REST API som passagerare och förare ansluter till.
• Tre olika adaptrar används med API inom dem, för att utföra åtgärder som fakturering, betalningar, skicka e-post / meddelanden som vi ser när vi bokar en taxi.
• En MySQL-databas för att lagra all deras data.

Så om du märker här alla funktioner som passagerarhantering, fakturering, aviseringsfunktioner, betalningar, resehantering och förarhantering var sammansatta inom ett enda ramverk.

Problemförklaring

Medan UBER började expandera över hela världen introducerade denna typ av ram olika utmaningar. Följande är några av de framträdande utmaningarna

• Alla funktioner måste byggas om, distribueras och testas om och om igen för att uppdatera en enda funktion.
• Åtgärda fel blev extremt svårt i ett enda arkiv eftersom utvecklare var tvungna att ändra koden om och om igen.
• Att skala funktionerna samtidigt med introduktionen av nya funktioner över hela världen var ganska svårt att hantera tillsammans.

Lösning

För att undvika sådana problem beslutade UBER att ändra sin arkitektur och följa andra hypertillväxtföretag som Amazon, Netflix, Twitter och många andra. Således beslutade UBER att bryta sin monolitiska arkitektur i flera kodbaser för att bilda en mikroservicearkitektur.

Se diagrammet nedan för att titta på UBERs mikrotjänstarkitektur.

Figur 5: Microservice Architecture Of UBER - Microservice Architecture

• Den stora förändringen som vi observerar här är introduktionen av API Gateway genom vilken alla förare och passagerare är anslutna. Från API Gateway är alla interna punkter anslutna som passagerarhantering, förarhantering, resehantering och andra.
• Enheterna är individuella separata distribuerbara enheter som utför separata funktioner.
  • Till exempel: Om du vill ändra någonting i faktureringsmikrotjänsterna, behöver du bara distribuera endast faktureringsmikrotjänster och behöver inte distribuera de andra.
• Alla funktioner har nu skalats individuellt, dvs. det ömsesidiga beroendet mellan varje funktion togs bort.
  • Till exempel vet vi alla att antalet personer som söker efter hytter är mer jämförelsevis mer än de som faktiskt bokar en hytt och betalar. Detta får oss en slutsats om att antalet processer som arbetar med passagerarhanteringens mikrotjänst är mer än antalet processer som arbetar med betalningar.

I dennasätt, UBER gynnades av att flyttadessarkitektur från monolitisk till mikrotjänster.

Jag hoppas att du har haft glädje av att läsa detta inlägg på Microservice Architecture.Jag kommer att komma med fler bloggar, som också kommer att innehålla hands-on.
Intresserad av att lära dig mer om mikrotjänster?

Om du vill lära dig Microservices och bygga dina egna applikationer, kolla in våra som kommer med instruktörsledad liveutbildning och verklig projektupplevelse. Denna utbildning hjälper dig att förstå Microservices på djupet och hjälper dig att behärska ämnet.

Har du en fråga till oss? Vänligen nämna det i kommentarfältet i ” Microservice-arkitektur ”Och jag kommer tillbaka till dig.