Microservices Tutorial: Hva er, Architecture og eksempel
⚡ Smart oppsummering
Mikrotjenester er et tjenesteorientert arkitekturmønster der en applikasjon er bygget som en samling av små, uavhengige tjenesteenheter. Denne ressursen forklarer monolittisk kontra mikrotjenestearkitektur, deres forskjeller, utfordringer, SOA-sammenligning, populære verktøy og beste praksis.
Hva er mikrotjenester?
Microservices er et tjenesteorientert arkitekturmønster der applikasjoner bygges som en samling av forskjellige minste uavhengige tjenesteenheter. Det er en software engineering tilnærming som fokuserer på å dekomponere en applikasjon i enkeltfunksjonsmoduler med veldefinerte grensesnitt. Disse modulene kan distribueres uavhengig og drives av små team som eier hele livssyklusen til tjenesten.
Begrepet «mikro» refererer til størrelsen på en mikrotjeneste, som må kunne håndteres av et enkelt utviklingsteam (5 til 10 utviklere). I denne metodikken deles store applikasjoner inn i de minste uavhengige enhetene.
Hva er monolittisk Archilære?
Enkelt forklart kan man si at monolittisk arkitektur er som en stor beholder der alle programvarekomponentene i et program er samlet i én pakke. La oss diskutere et eksempel på en e-handelsbutikk i konteksten av en monolittisk arkitektur.
Monolithic Architecture of eCommerce Application
I alle e-handelsapplikasjoner er det noen standardfunksjoner som søk, RevVisninger og vurderinger, og betalinger. Disse funksjonene er tilgjengelige for kunder som bruker nettleseren eller appene sine. Når utvikleren av e-handelsnettstedet distribuerer applikasjonen, er det én enkelt monolittisk enhet. Koden for forskjellige funksjoner som søk, RevVisninger og vurderinger, og betalinger er på samme server. For å skalere applikasjonen må du kjøre flere instanser (servere) av disse applikasjonene.
Hva er Microservice Archilære?
Mikroservice Architecture er en arkitektonisk utviklingsstil som tillater å bygge applikasjoner som en samling av små autonome tjenester utviklet for et forretningsdomene. Det er en variant av strukturell stilarkitektur som hjelper til med å arrangere applikasjoner som en løst koblet tjenestesamling. Mikrotjenesten Architecture inneholder finmaskede tjenester og lette protokoller.
La oss ta et eksempel på en e-handelsapplikasjon utviklet med mikrotjenestearkitektur. I dette eksemplet på mikrotjenestearkitektur er hver mikrotjeneste fokusert på én enkelt forretningsfunksjon. Søk, vurdering og Review og Payment har hver sin instans (server) og kommuniserer med hverandre.
Microservices Architecture
I det monolittiske Architekstur, alle komponentene samles i én enkelt modul. Men i Microservices ArchiTeknologi er de spredt i individuelle moduler (mikrotjenester) som kommuniserer med hverandre, som vist i mikrotjenester-eksemplet ovenfor.
Kommunikasjonen mellom mikrotjenester er en statsløs kommunikasjon der hvert par av forespørsel og svar er uavhengige. Derfor kan mikrotjenester kommunisere uanstrengt. I mikrotjenesten ArchiTeknologi, dataene er samlet. Hver mikrotjeneste har sitt eget datalager.
Mikrotjenester vs. monolittisk Architecture
| Microservices | Monolithic Architecture |
|---|---|
| Hver enhet i hele applikasjonen skal være den minste, og den skal kunne levere ett spesifikt forretningsmål. | Én enkelt kodebase for alle forretningsmål. |
| Oppstart av tjenesten går relativt raskt. | Oppstart av tjenesten tar lengre tid. |
| Det er enkelt å isolere feil. Selv om én tjeneste går ned, kan andre fortsette å fungere. | Feilisolering er vanskelig. Hvis en spesifikk funksjon ikke fungerer, går hele systemet ned. For å håndtere dette problemet må applikasjonen bygges på nytt, testes på nytt og distribueres på nytt. |
| Alle mikrotjenester bør være løst koblet sammen, slik at endringer gjort i den ene ikke påvirker den andre. | Monolittisk arkitektur er tett koblet sammen. Endringer i én kodemodul påvirker den andre. |
| Bedrifter kan bruke flere ressurser på tjenester som genererer høyere avkastning. | Siden tjenester ikke er isolerte, er det ikke mulig å fordele individuelle ressurser. |
| Flere maskinvareressurser kan allokeres til tjenesten som brukes ofte. I e-handelseksemplet ovenfor sjekker flere brukere produktlisten og søker sammenlignet med betalinger, slik at flere ressurser kan allokeres til mikrotjenesten for søk og produktliste. | Applikasjonsskalering er utfordrende så vel som bortkastet. |
| Mikrotjenester forblir alltid konsistente og kontinuerlig tilgjengelige. | Utviklingsverktøy blir overbelastet ettersom prosessen må starte på nytt. |
| Data er samlet. Dette lar individuelle mikrotjenester ta i bruk en datamodell som passer best til deres behov. | Data er sentralisert. |
| Små fokuserte team. Parallell og raskere utvikling. | Det kreves et stort team og betydelig innsats fra teamledelsen. |
| Endring i datamodellen til én mikrotjeneste påvirker ikke andre mikrotjenester. | Endring i datamodellen påvirker hele databasen. |
| Samhandler med andre mikrotjenester ved å bruke veldefinerte grensesnitt. | Ikke aktuelt. |
| Mikrotjenester fungerer etter prinsippet om å fokusere på produkter, ikke prosjekter. | Legger vekt på hele prosjektet. |
| Ingen kryssavhengigheter mellom kodebaser. Du kan bruke forskjellige teknologier for forskjellige mikrotjenester. | En funksjon eller et program avhenger av andre. |
Mikroserviceutfordringer
- Mikrotjenester er avhengige av hverandre, og de må kommunisere med hverandre.
- Sammenlignet med monolittiske systemer, er det flere tjenester å overvåke som er utviklet med forskjellige programmerings språk.
- Siden det er et distribuert system, er det en iboende kompleks modell.
- Ulike tjenester vil ha sine egne mekanismer, noe som resulterer i en stor mengde minne for ustrukturerte data.
- Effektiv ledelse og samarbeid er nødvendig for å forhindre kaskadeproblemer.
- Å reprodusere et problem vil være en vanskelig oppgave når det er borte i én versjon og kommer tilbake i den nyeste versjonen.
- Uavhengig distribusjon er komplisert med mikrotjenester.
- Mikrotjenestearkitektur gir mange operasjoner overhead.
- Det er vanskelig å administrere applikasjonen når nye tjenester legges til systemet.
- Et bredt spekter av dyktige fagfolk er nødvendig for å støtte heterogent distribuerte mikrotjenester.
- Mikroservice er kostbart, ettersom du trenger å opprettholde forskjellig serverplass for forskjellige forretningsoppgaver.
SOA vs. mikrotjenester
SOA-tjenester vedlikeholdes i organisasjonen av et register som fungerer som en katalogliste. Applikasjoner må slå opp tjenestene i registeret og starte tjenesten. Med andre ord, SOA er akkurat som et orkester der hver artist opptrer med sitt instrument mens musikksjefen gir instruksjoner til alle.
På den andre siden er Microservices en form for tjenesteorientert arkitekturstil der applikasjoner er bygget som en samling av forskjellige mindre tjenester i stedet for én programvare eller applikasjon. Microservices er akkurat som en tropp der hver danser er uavhengig og vet hva de trenger å gjøre. Så hvis de går glipp av noen trinn, vet de hvordan de skal komme tilbake til riktig rekkefølge. Her er en detaljert sammenligning mellom SOA og Microservices.
| Parameter | SOA | Microservices |
|---|---|---|
| Design type | I SOA blir programvarekomponenter eksponert mot den ytre verden for bruk i form av tjenester. | Micro Service er en del av SOA. Det er en implementering av SOA. |
| Avhengighet | Forretningsenheter er avhengige. | De er uavhengige av hverandre. |
| Størrelsen på programvaren | Programvarestørrelsen er større enn all konvensjonell programvare. | Størrelsen på programvaren er alltid liten i Microservices. |
| Teknologi Stack | Teknologistabelen er lavere sammenlignet med Microservice. | Microservice teknologistabel kan være veldig stor. |
| Søknadens art | Monolitisk av natur. | Full stabel i naturen. |
| Selvstendig og fokusert | SOA-applikasjoner er bygget for å utføre flere forretningsoppgaver. | De er bygget for å utføre én enkelt forretningsoppgave. |
| Utplassering | Distribusjonsprosessen er tidkrevende. | Implementeringen er enkel og mindre tidkrevende. |
| Kostnadseffektivitet | Mer kostnadseffektivt. | Less kostnadseffektiv. |
| skalerbarhet | Less sammenlignet med Microservices. | Svært skalerbar. |
| Forretningslogikk | Forretningslogikkkomponenter lagres i et enkelt tjenestedomene, med enkle kablede protokoller (HTTP med XML eller JSON) og API-drevet med SDK-er/klienter. | Forretningslogikk kan leve på tvers av domener, med lag mellom tjenester (Middleware) som ligner på enterprise Service Bus. |
Microservices-verktøy
1) Wiremock: Testing av mikrotjenester
WireMock er et fleksibelt bibliotek for stubbing og mocking av webtjenester. Det kan konfigurere svaret som returneres av HTTP API-et når det mottar en spesifikk forespørsel. Det brukes også til testing av mikrotjenester.
Last ned link: http://wiremock.org/
2) Havnearbeider
Docker er et åpen kildekode-prosjekt som lar oss opprette, distribuere og kjøre applikasjoner ved hjelp av containere. Ved å bruke disse containerne kan utviklere kjøre en applikasjon som én pakke. Det lar deg sende biblioteker og andre avhengigheter i én pakke.
Last ned link: https://www.docker.com/
3) Hystrix
Hystrix er en feiltoleranse Java bibliotek. Dette verktøyet er utviklet for å separere tilgangspunkter til eksterne tjenester, systemer og tredjepartsbiblioteker i et distribuert miljø som Microservices. Det forbedrer det overordnede systemet ved å isolere de sviktende tjenestene og forhindre kaskadeeffekten av feil.
Last ned Link: https://github.com/Netflix/Hystrix
Beste praksis for mikrotjenester Architecture
- Separat datalager for hver mikrotjeneste.
- Hold koden på et lignende modenhetsnivå.
- Separat bygg for hver mikrotjeneste.
- Behandle alltid hver server som statsløs.



