Microservices Tutorial: Hvad er, Architecture og eksempel

Hvad er mikrotjenester?

Microservices er et serviceorienteret arkitekturmønster, hvor applikationer er bygget som en samling af forskellige mindste uafhængige serviceenheder. Det er en software Engineering tilgang, der fokuserer på at dekomponere en applikation i enkeltfunktionsmoduler med veldefinerede grænseflader. Disse moduler kan implementeres uafhængigt og drives af små teams, der ejer hele tjenestens livscyklus.

Udtrykket "mikro" refererer til størrelsen af ​​en mikroservice, som skal kunne håndteres af et enkelt udviklingsteam (5 til 10 udviklere). I denne metode opdeles store applikationer i de mindste uafhængige enheder.

Hvad er monolitisk Archilære?

Enkelt fortalt kan man sige, at monolitisk arkitektur er som en stor container, hvor alle softwarekomponenterne i en applikation er samlet i en enkelt pakke. Lad os diskutere et eksempel på en e-handelsbutik i konteksten af ​​en monolitisk arkitektur.

Monolithic Architecture of eCommerce Application

I enhver e-handelsapplikation er der nogle standardfunktioner som søgning, RevVisninger og vurderinger samt betalinger. Disse funktioner er tilgængelige for kunder ved hjælp af deres browser eller apps. Når udvikleren af ​​e-handelswebstedet implementerer applikationen, er det en enkelt monolitisk enhed. Koden til forskellige funktioner som søgning, RevVisninger og vurderinger samt betalinger er på den samme server. For at skalere applikationen skal du køre flere instanser (servere) af disse applikationer.

Hvad er Microservice Archilære?

Mikroservice Architecture er en arkitektonisk udviklingsstil, der gør det muligt at bygge applikationer som en samling af små autonome tjenester udviklet til et forretningsdomæne. Det er en variant af strukturel stilarkitektur, der hjælper med at arrangere applikationer som en løst koblet servicesamling. Mikrotjenesten Architecture indeholder finkornede tjenester og lette protokoller.

Lad os tage et eksempel på en e-handelsapplikation udviklet med mikroservicearkitektur. I dette eksempel på en mikroservicearkitektur fokuserer hver mikroservice på en enkelt forretningsfunktion. Søgning, vurdering og Review og Payment har hver deres instans (server) og kommunikerer med hinanden.

Microservices Architecture

I Monolitikum ArchiTektur, alle komponenterne samles i et enkelt modul. Men i Microservices ArchiTekturen spredes i individuelle moduler (mikrotjenester), der kommunikerer med hinanden, som vist i eksemplet med mikrotjenester ovenfor.

Kommunikationen mellem mikrotjenester er en statsløs kommunikation, hvor hvert par af anmodninger og svar er uafhængige. Derfor kan Microservices kommunikere ubesværet. I Microservice ArchiTeknologi, dataene er samlet. Hver mikrotjeneste har sit separate datalager.

Microservices vs. Monolithic Architecture

Microservices	Monolithic Architecture
Hver enhed i hele applikationen skal være den mindste, og den skal kunne levere ét specifikt forretningsmål.	En enkelt kodebase til alle forretningsmål.
Opstart af tjenesten er relativt hurtig.	Opstart af tjenesten tager længere tid.
Fejlisolering er nemt. Selv hvis én tjeneste går ned, kan andre fortsætte med at fungere.	Fejlisolering er vanskelig. Hvis en specifik funktion ikke fungerer, går hele systemet ned. For at håndtere dette problem skal applikationen genopbygges, testes igen og implementeres igen.
Alle mikrotjenester bør være løst koblet sammen, så ændringer foretaget i den ene ikke påvirker den anden.	Monolitisk arkitektur er tæt forbundet. Ændringer i ét kodemodul påvirker det andet.
Virksomheder kan anvende flere ressourcer på tjenester, der genererer et højere investeringsafkast.	Da tjenester ikke er isolerede, er individuel ressourceallokering ikke mulig.
Flere hardwareressourcer kunne allokeres til den tjeneste, der ofte bruges. I ovenstående e-handelseksempel tjekker flere brugere produktlisten og søger sammenlignet med betalinger, så flere ressourcer kunne allokeres til mikrotjenesten til søgning og produktliste.	Ansøgningsskalering er udfordrende såvel som spild.
Mikrotjenester forbliver altid konsistente og kontinuerligt tilgængelige.	Udviklingsværktøjer bliver overbelastede, da processen skal starte forfra.
Data er samlet. Dette giver individuelle mikrotjenester mulighed for at anvende en datamodel, der passer bedst til deres behov.	Data er centraliseret.
Små fokuserede teams. Parallel og hurtigere udvikling.	Det kræver et stort team og en betydelig teamledelsesindsats.
Ændring i datamodellen for én mikrotjeneste påvirker ikke andre mikrotjenester.	Ændringer i datamodellen påvirker hele databasen.
Interagerer med andre mikrotjenester ved hjælp af veldefinerede grænseflader.	Ikke anvendelig.
Mikrotjenester fungerer ud fra princippet om at fokusere på produkter, ikke projekter.	Lægger vægt på hele projektet.
Ingen krydsafhængigheder mellem kodebaser. Du kan bruge forskellige teknologier til forskellige mikrotjenester.	En funktion eller et program afhænger af andre.

Microservice udfordringer

• Mikrotjenester er afhængige af hinanden, og de bliver nødt til at kommunikere med hinanden.
• Sammenlignet med monolitiske systemer er der flere tjenester at overvåge, som er udviklet ved hjælp af forskellige programmeringssprog.
• Da det er et distribueret system, er det en iboende kompleks model.
• Forskellige tjenester vil have deres separate mekanisme, hvilket resulterer i en stor mængde hukommelse til ustrukturerede data.
• Effektiv ledelse og teamwork er nødvendigt for at forhindre kaskadeproblemer.
• Det vil være vanskeligt at reproducere et problem, når det er væk i én version og kommer tilbage i den nyeste version.
• Uafhængig implementering er kompliceret med Microservices.
• Mikroservicearkitektur bringer masser af operationer overhead.
• Det er vanskeligt at administrere applikationen, når nye tjenester tilføjes til systemet.
• En bred vifte af dygtige fagfolk er nødvendig for at understøtte heterogent distribuerede mikrotjenester.
• Microservice er dyrt, da du skal vedligeholde forskellig serverplads til forskellige forretningsopgaver.

SOA vs. Microservices

SOA-tjenester vedligeholdes i organisationen af ​​et register, der fungerer som en mappeliste. Applikationer skal slå tjenesterne op i registeret og kalde tjenesten. Med andre ord, SOA er ligesom et orkester, hvor hver kunstner optræder med sit instrument, mens musiklederen giver instruktioner til alle.

I den anden ende er Microservices en form for serviceorienteret arkitektur, hvor applikationer er bygget som en samling af forskellige mindre tjenester i stedet for én software eller applikation. Microservices er ligesom en trup, hvor hver danser er uafhængig og ved, hvad de skal gøre. Så hvis de misser nogle trin, ved de, hvordan de kommer tilbage til den rigtige rækkefølge. Her er en detaljeret sammenligning mellem SOA og Microservices.

Parameter	SOA	Microservices
Design type	I SOA eksponeres softwarekomponenter til den ydre verden til brug i form af tjenester.	Micro Service er en del af SOA. Det er en implementering af SOA.
Afhængighed	Forretningsenheder er afhængige.	De er uafhængige af hinanden.
Softwarens størrelse	Softwaren er større end konventionel software.	Softwarens størrelse er altid lille i Microservices.
Teknologi stak	Teknologistakken er lavere sammenlignet med Microservice.	Mikroserviceteknologistak kan være meget stor.
Ansøgningens art	Monolitisk af natur.	Fuld stak i naturen.
Selvstændig og fokus	SOA-applikationer er bygget til at udføre flere forretningsopgaver.	De er bygget til at udføre en enkelt forretningsopgave.
Deployment	Implementeringsprocessen er tidskrævende.	Implementeringen er ligetil og mindre tidskrævende.
Omkostningseffektivitet	Mere omkostningseffektiv.	Less omkostningseffektiv.
Skalerbarhed	Less sammenlignet med Microservices.	Meget skalerbar.
Forretningslogik	Forretningslogikkomponenter er gemt i et enkelt servicedomæne med simple kabelprotokoller (HTTP med XML eller JSON) og API-drevet med SDK'er/klienter.	Forretningslogik kan fungere på tværs af domæner med lag mellem tjenester (Middleware) i stil med enterprise Service Bus.

Mikroserviceværktøjer

1) Wiremock: Test af mikrotjenester

WireMock er et fleksibelt bibliotek til stubbing og mocking af webtjenester. Det kan konfigurere det svar, der returneres af HTTP API'en, når den modtager en specifik anmodning. Det bruges også til test af mikrotjenester.

Hent link: http://wiremock.org/

2) Docker

Docker er et open source-projekt, der giver os mulighed for at oprette, implementere og køre applikationer ved hjælp af containere. Ved at bruge disse containere kan udviklere køre en applikation som en enkelt pakke. Det giver dig mulighed for at levere biblioteker og andre afhængigheder i én pakke.

Hent link: https://www.docker.com/

3) Hystrix

Hystrix er en fejltolerance Java bibliotek. Dette værktøj er designet til at adskille adgangspunkter til eksterne tjenester, systemer og tredjepartsbiblioteker i et distribueret miljø som Microservices. Det forbedrer det overordnede system ved at isolere de fejlende tjenester og forhindre den kaskadelignende effekt af fejl.

Hent Link: https://github.com/Netflix/Hystrix

Bedste praksis for mikrotjenester Architecture

• Separat datalager for hver mikrotjeneste.
• Hold koden på et lignende modenhedsniveau.
• Separat build for hver Microservice.
• Behandl altid hver server som statsløs.

Ofte Stillede Spørgsmål