Næsten ethvert computersystem udfører flere opgaver ved hjælp af delte ressourcer, og et af spørgsmålene ved computerprogrammering er, hvor tæt kodebitene, der udfører disse opgaver, skal knyttes til hinanden. Et stadig mere populært svar er begrebet mikroservice—et lille, diskret stykke funktionalitet, der interagerer med andre mikrotjenester for at skabe et større system.
Selvom den grundlæggende idé om at have sådanne diskrete komponenter ikke er ny, gør den måde, mikrotjenester implementeres på, det til et naturligt fundament for begge moderne skybaserede applikationer. Microservices passer også sammen med devops-filosofien, som tilskynder til hurtig og kontinuerlig udrulning af ny funktionalitet.
Hvad er mikrotjenester?
”Mikroen” i mikrotjenesterne antyder, at dette er små applikationer. Det er undertiden sandt, men en bedre måde at tænke på dem er, at de kun skal være så store som nødvendigt for at gøre en bestemt ting eller løse et bestemt problem. Problemet skal være begrebsmæssigt og ikke teknisk. Som Microsoft udtrykker det, "Microservices skal designes omkring forretningsegenskaber, ikke vandrette lag som datatilgang eller messaging." De kommunikerer med andre mikrotjenester og eksterne brugere via relativt stabile API'er for at oprette en større applikation.
Således kan den interne funktionalitet i en individuel mikroservice justeres eller radikalt opgraderes uden at påvirke resten af systemet. Dette til gengæld hænger sammen med, hvordan devops-butikker søger at operere: Hvis de specifikke funktioner i en større applikation er opdelt i diskrete, uafhængigt kørende stykker kode, er det lettere at leve devops-mantraet af CI / CD (kontinuerlig integration og kontinuerlig levering) . Også veldefinerede API'er gør mikroservices nemme at teste automatisk.
Mikrotjenestearkitektur versus monolitisk arkitektur
Du kan ofte høre mikrotjenester omtalt i form af en “mikrotjenestearkitektur.” Denne sætning omfatter ikke kun selve mikrotjenesterne, men komponenter til styring og serviceopdagelse samt en API-gateway, der håndterer kommunikation mellem mikrotjenester og omverdenen.
En "monolitisk anvendelse" er det modsatte af, hvad mikrotjenester er. Det er et retronym for et program, hvor al koden er i en stor binær eksekverbar fil. Som TechTarget forklarer, er en monolitisk applikation sværere at skalere og sværere at forbedre. Men fordi det er bygget som en enkelt sammenhængende applikation, kræver det ikke så meget styring som en mikrotjenestearkitektur.
Begrænsede begreber: Sådan defineres en mikroservice
Lad os tage et øjeblik sikkerhedskopi af vores tidligere befaling om, at mikrotjenester skal gøre en bestemt ting. Det er let at sige, men i praksis er funktionalitet ofte sammenflettet, og tegning af divisioner er sværere end det ser ud. Domæneanalyse og domænestyret design er de teoretiske tilgange, der hjælper dig med at drille din store billedopgave fra hinanden i individuelle problemer, som en mikroservice kan løse. I denne proces, skitseret i en oplysende række blogindlæg fra Microsoft, opretter du en abstrakt model af dit forretningsdomæne og opdager i processen de afgrænsede sammenhænge, som grupperer funktionalitet, der interagerer med verden på en bestemt måde.
For eksempel har du muligvis en afgrænset kontekst til forsendelse og en anden til konti. Et fysisk objekt i den virkelige verden ville have både en pris og et sted, det skal gå, selvfølgelig, men de afgrænsede sammenhænge repræsenterer specifikke måder, hvorpå din applikation tænker på og interagerer med disse objekter. Hver mikroservice skal eksistere fuldstændigt inden for en enkelt afgrænset kontekst, selvom nogle afgrænsede sammenhænge måske omfatter mere end en mikroservice.
Microservices vs. serviceorienteret arkitektur vs. webservices
På dette tidspunkt, hvis du er en it-professionel, der har eksisteret i branchen i et stykke tid, tror du måske meget af dette lyder velkendt. Ideen om små individuelle programmer, der arbejder sammen, kan minde dig om både SOA (serviceorienteret arkitektur) og webtjenester, to buzzwords fra de berusende Web 2.0 dage i 2000'erne. Mens der i en forstand virkelig ikke er noget nyt under solen, er der vigtige forskelle mellem disse begreber og mikrotjenester. Datamation har en god oversigt over forskellene, men her er en kort version:
- I en serviceorienteret arkitektur er enkeltkomponenter relativt tæt koblet og deler ofte aktiver såsom lagring, og de kommunikerer gennem et stykke specialsoftware kaldet en enterprise-lagringsbus. Mikrotjenester er mere uafhængige, deler færre ressourcer og kommunikerer via mere lette protokoller. Det er værd at bemærke, at mikrotjenester opstod ud af SOA-miljøet og undertiden betragtes som en slags SOA eller efterfølger til konceptet.
- En webtjeneste er et sæt af funktionaliteter, som andre applikationer har adgang til via nettet; sandsynligvis det mest udbredte eksempel er Google Maps, som en restaurants websted kan integrere for at give rutevejledning til kunder. Dette er en meget løsere forbindelse, end du ville se i en mikrotjenestearkitektur.
Kommunikation med mikrotjenester
En slagord, som du ofte vil høre brugt om mikrotjenestearkitekturer, er at de skal have "smarte slutpunkter og dumme rør". Med andre ord skal mikroservices sigte mod at bruge grundlæggende og veletablerede kommunikationsmetoder snarere end kompleks og tæt integration. Som bemærket er dette en anden ting, der adskiller mikrotjenester fra SOA.
Generelt skal kommunikation mellem mikrotjenester være asynkron, i den forstand, at kodetråde ikke er blokeret og venter på svar. (Det er stadig fint at bruge synkron kommunikationsprotokoller som f.eks. HTTP, selvom asynkrone protokoller som AMQP (Advanced Message Queuing Protocol) også er almindelige i mikrotjenestearkitekturer.) Denne form for løs kobling gør en mikrotjenestearkitektur mere fleksibel i lyset af fejlen. af individuelle komponenter eller dele af netværket, hvilket er en vigtig fordel.
Microservices, Java og Spring Boot og Spring Cloud
Noget af det første arbejde inden for mikrotjenester opstod i Java-samfundet; Martin Fowler var en tidlig talsmand. En Java-konference i Polen i 2012 indeholdt en af de vigtigste tidlige præsentationer om emnet med titlen “Micro services - Java, the Unix Way.” Det blev anbefalet at anvende de principper, der styrede udviklingen af de første Unix-applikationer i 1970'erne ("Skriv programmer der gør en ting og gør det godt. Skriv programmer for at arbejde sammen ”) til Java-udvikling.
Som et resultat af denne historie er der masser af Java-rammer, der giver dig mulighed for at opbygge mikrotjenester. En af de mest populære er Spring Boot, som er specielt designet til mikrotjenester; Boot udvides af Spring Cloud, som som navnet antyder, også giver dig mulighed for at distribuere disse tjenester til skyen. Pivotal Software, udvikleren af Spring, har en god tutorial om at komme i gang med udvikling af mikroservice ved hjælp af disse rammer.
Mikrotjenester og containere: Docker, Kubernetes og videre
Den underliggende teknologi, der er gået længst mod at få mikrotjenester i mainstream er containere. En container ligner en VM-forekomst, men i stedet for at inkludere et helt selvstændigt operativsystem er en container bare et isoleret brugerrum, der bruger værtsoperativsystemets kerne, men ellers holder koden udført inde i den selvstændigt. Containere er meget mindre end VM-forekomster og er lette at implementere hurtigt, enten lokalt eller i skyen, og kan centrifugeres op eller ned for at matche efterspørgsel og tilgængelige ressourcer.
Appellen af containere til mikrotjenester bør være åbenbar: Hver enkelt mikroservice kan køre i sin egen container, hvilket reducerer omkostningerne ved administration af tjenester betydeligt. De fleste containerimplementeringer har komplementære orkestreringsværktøjer, der automatiserer implementering, styring, skalering, netværk og tilgængelighed af containerbaserede applikationer. Det er kombinationen af små, lette at bygge mikrotjenester og containere, der er lette at implementere, der gør devops-filosofien mulig. Der er flere implementeringer af containerkonceptet, men langt den mest populære er Docker, som generelt er parret med Kubernetes som en orkestrationsplatform.
Foråret er, selvom det er populært, bundet til Java-platformen. Containerbaserede systemer er derimod polyglot: Ethvert programmeringssprog, som OS understøtter, kan køre i en container, hvilket giver mere fleksibilitet til programmører. Faktisk er en stor fordel ved mikroservices, at hver enkelt tjeneste kan skrives på det sprog, der giver mest mening, eller som udviklere er mest fortrolige med. Faktisk kunne en tjeneste genopbygges fuldstændigt på et nyt sprog uden at påvirke systemet som helhed, så længe dets API'er forbliver stabile. DZone har en artikel, der diskuterer fordele og ulemper ved Spring Cloud vs. Kubernetes for mikrotjenester.
Microservices design mønstre
Uanset hvilket sprog du bruger til at udvikle mikrotjenester, står du over for problemer, som andre udviklere har stødt på før. Designmønstre er formaliserede, abstrakte løsninger på tilbagevendende problemer inden for datalogi, og en række af dem er specifikt beregnet til mikrotjenester. Devopedia har en fantastisk liste, der inkluderer:
- Service Registry: til at forbinde klienter til tilgængelige forekomster af mikrotjenester
- Afbryder: for at forhindre, at mislykkede tjenester kaldes gentagne gange
- Tilbagefald: til at tilbyde et alternativ til en mislykket tjeneste
- Sidevogn: til levering af en ekstra tjeneste til hovedcontaineren, såsom til logning, synkronisering af tjenester eller overvågning
- Adapter: til at standardisere eller normalisere grænsefladen mellem hovedbeholderen og den eksterne verden
- Ambassadør: at forbinde hovedcontaineren til omverdenen, f.eks. Til proxying af lokale værtsforbindelser til eksterne forbindelser
Mikrotjenester og skyen: AWS og Azure
Som nævnt ovenfor er en af fordelene ved at bruge containere, at de let kan implementeres i skyen, hvor fleksible beregningsressourcer er tilgængelige, så du kan maksimere din applikations effektivitet. Som du måske forestiller dig, er de store offentlige cloud-leverandører alle ivrige efter, at du bruger deres platforme til at køre dine mikroservicebaserede apps. For mere information, se ressourcerne fra Amazon, Microsoft og Google.
