Microservices Tutorial: Hvad er, Architecture og eksempel

Udtrykket "mikro" refererer til størrelsen af ​​en mikrotjeneste, som skal kunne administreres af et enkelt udviklingsteam (5 til 10 udviklere). I denne metode er store applikationer opdelt i mindste uafhængige enheder.

Hvad er monolitisk Archilære?

I lægmandstermer kan man sige, at monolitisk arkitektur er som en stor beholder, hvor alle softwarekomponenterne i en applikation er samlet i en enkelt pakke.

Lad os diskutere et eksempel på en e-handelsbutik i sammenhæng med en monolitisk arkitektur.

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

I Monolitikum Architecture, smelter alle komponenterne sammen til et enkelt modul. Men i Microservices Archide er spredt i individuelle moduler (microservice), som kommunikerer med hinanden som vist i Microservices-eksemplet 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 mikrotjenesten Architecture, er dataene fødereret. Hver mikroservice har sit separate datalager. Næste i dette Java Microservices tutorial, vi vil lære om forskellen mellem Microservices og monolitisk arkitektur.

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 for alle forretningsmål
Servicestart er relativt hurtig	Servicestart tager længere tid
Fejlisolering er let. Selvom en tjeneste går ned, kan en anden fortsætte med at fungere.	Fejlisolering er vanskelig. Hvis en bestemt funktion ikke virker, går hele systemet ned. For at håndtere dette problem skal applikationen genopbygges, gentestes og også geninstalleres.
Alle mikrotjenester bør være løst koblet, så ændringer foretaget i den ene ikke påvirker den anden.	Monolitisk arkitektur er tæt forbundet. Ændringer i et kodemodul påvirker det andet
Virksomheder kan implementere flere ressourcer til tjenester, der genererer højere ROI	Da tjenester ikke er isolerede, er individuel ressourceallokering ikke mulig
Flere hardwareressourcer kunne allokeres til den tjeneste, der ofte bruges. I e-handelseksemplet ovenfor tjekker flere brugere produktlisten og søger sammenlignet med betalinger. Så der kunne allokeres flere ressourcer til søge- og produktlistemikrotjenesten.	Ansøgningsskalering er udfordrende såvel som spild.
Mikrotjenester forbliver altid konsekvente og konstant tilgængelige.	Udviklingsværktøjer bliver overbebyrdede, da processen skal starte fra bunden.
Data er fødereret. Dette giver den enkelte Microservice mulighed for at vedtage en datamodel, der passer bedst til dens behov.	Data er centraliseret.
Små fokuserede teams. Parallel og hurtigere udvikling	Et stort team og en betydelig teamledelsesindsats er påkrævet
Ændring i datamodellen for én mikrotjeneste påvirker ikke andre mikrotjenester.	Ændring i datamodel påvirker hele databasen
Interagerer med andre mikrotjenester ved at bruge veldefinerede grænseflader	Ikke relevant
Microservices arbejder efter princippet, der fokuserer på produkter, ikke projekter	Læg 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

• MicroServices 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 sin separate mekanisme, hvilket resulterer i en stor mængde hukommelse til ustrukturerede data.
• Effektiv ledelse og teamwork kræves for at forhindre cascading problemer
• At gengive et problem vil være en vanskelig opgave, når det er væk i én version og kommer tilbage i den seneste version.
• Uafhængig implementering er kompliceret med Microservices.
• Mikroservicearkitektur bringer masser af operationer overhead.

• Det er svært at administrere applikationen, når nye tjenester tilføjes til systemet
• En bred vifte af dygtige fagfolk er påkrævet 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 adresseliste. Ansøgninger skal slå tjenesterne op i registreringsdatabasen og påberåbe sig tjenesten.

I en anden verden, SOA er ligesom et orkester, hvor hver kunstner optræder med sit instrument, mens musiklederen giver instruktioner til alle.

På den anden ende er Microservices en form for serviceorienteret arkitekturstil, hvor applikationer er bygget som en samling af forskellige mindre tjenester i stedet for en software eller applikation.

Microservices er ligesom en trup, hvor hver danser er uafhængig og ved, hvad de skal gøre. Så hvis de går glip af nogle trin, ved de, hvordan de kommer tilbage til den rigtige rækkefølge. Lad os nu i denne Microservices arkitektur tutorial lære om forskellen mellem SOA og Microservices.

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	Softwarestørrelsen er større end nogen 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 i naturen	Fuld stabel 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.
Omkostninger – effektivitet	Mere omkostningseffektiv.	Less omkostningseffektiv.
Skalerbarhed	Less sammenlignet med Microservices.	Meget skalerbar.
Forretningslogik	Forretningslogikkomponenter gemmes inde i et enkelt tjenestedomæne Simple wire-protokoller (HTTP med XML JSON) API drives med SDK'er/klienter	Forretningslogik kan leve på tværs af domæner, Enterprise Service Bus-lignende lag mellem tjenester, Middleware

Mikroserviceværktøjer

1) Wiremock: Test af mikrotjenester

WireMock er et fleksibelt bibliotek til at stoppe og håne webtjenester. Det kan konfigurere svaret, der returneres af HTTP API'en, når det modtager en specifik anmodning. Det bruges også til at teste mikrotjenester.

Hent link:http://wiremock.org/

2) Docker

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

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

3) Hystrix

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

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

Bedste praksis for mikrotjenester Architecture

• Separat datalager for hver mikrotjeneste
• Behold koden på et lignende modenhedsniveau.
• Separat build for hver mikrotjeneste.
• Behandl altid - alvorlig som statsløs.

Resumé

• Microservices er et serviceorienteret arkitekturmønster, hvor applikationer er bygget som en samling af forskellige mindste uafhængige serviceenheder.
• Mikroservice Architecture er en arkitektonisk udviklingsstil, der gør det muligt at bygge en applikation som en samling af små autonome tjenester udviklet til et forretningsdomæne.
• Monolitisk arkitektur er som en stor beholder, hvor alle softwarekomponenterne i en applikation er samlet i en enkelt pakke
• I en mikroservice skal hver enhed af hele applikationen være den mindste, og den bør kunne levere ét specifikt forretningsmål
• I monolitisk arkitektur kan en stor kodebase bremse hele udviklingsprocessen. Nye udgivelser kan tage måneder. Kodevedligeholdelse er vanskelig
• To typer mikrotjenester er 1) Statsløse 2) Stateful
• Mikrotjenester i Java stole på hinanden, og de bliver nødt til at kommunikere med hinanden. Hjælper dig med at lægge vægt på en specifik funktion og forretningsbehov
• Serviceorienteret arkitektur kort kendt som SOA er en udvikling af distribueret databehandling baseret på anmodnings- eller svardesignmodellen til synkrone og asynkrone applikationer
• I SOA eksponeres softwarekomponenter for den ydre verden til brug i form af tjenester, mens Micro Service er en del af SOA. Det er en implementering af SOA
• Wiremock, Docker og Hystrix er nogle populære Microservices-værktøjer