Nesten hvert datasystem utfører flere oppgaver ved hjelp av delte ressurser, og et av spørsmålene ved dataprogrammering er hvor nær kodebitene som utfører disse oppgavene, skal knyttes til hverandre. Et stadig mer populært svar er begrepet mikroservice—et lite, diskret stykke funksjonalitet som samhandler med andre mikrotjenester for å skape et større system.
Selv om den grunnleggende ideen om å ha slike diskrete komponenter ikke er ny, gjør måten mikrotjenester implementeres på, dem til et naturlig grunnlag for både moderne skybaserte applikasjoner. Microservices passer også sammen med devops-filosofien, som oppmuntrer til rask og kontinuerlig utrulling av ny funksjonalitet.
Hva er mikrotjenester?
"Micro" i mikrotjenester innebærer at dette er små applikasjoner. Noen ganger er det sant, men en bedre måte å tenke på dem er at de bare skal være så store som nødvendig for å gjøre en bestemt ting eller løse et bestemt problem. Det problemet skal være konseptuelt, ikke teknisk. Som Microsoft uttrykker det, "Microservices bør utformes rundt forretningsegenskaper, ikke horisontale lag som datatilgang eller meldinger." De kommuniserer med andre mikrotjenester og eksterne brukere via relativt stabile API-er for å lage en større applikasjon.
Dermed kan den interne funksjonaliteten til en enkelt mikroservice justeres eller radikalt oppgraderes uten å påvirke resten av systemet. Dette knytter seg til hvordan devops-butikker søker å operere: Hvis de spesifikke funksjonene til en større applikasjon er segmentert i diskrete, uavhengig opererende kodestykker, er det lettere å leve devops-mantraet til CI / CD (kontinuerlig integrering og kontinuerlig levering) . Også veldefinerte API-er gjør det enkelt å teste mikrotjenester.
Mikrotjenestearkitektur kontra monolitisk arkitektur
Du vil ofte høre mikrotjenester snakket om i form av en “mikrotjenestearkitektur.” Denne setningen omfatter ikke bare mikrotjenestene selv, men komponenter for ledelse og serviceoppdagelse, samt en API-gateway som håndterer kommunikasjon mellom mikrotjenester og omverdenen.
En “monolitisk applikasjon” er det motsatte av hva mikrotjenester er. Det er et retronym for et program der all koden er i en stor binær kjørbar fil. Som TechTarget forklarer, er en monolitisk applikasjon vanskeligere å skalere og vanskeligere å forbedre. Men fordi den er bygget som en enkelt sammenhengende applikasjon, krever den ikke så mye styring som en mikrotjenestearkitektur.
Begrensede konsepter: Hvordan definere en mikrotjeneste
La oss sikkerhetskopiere et øyeblikk til vårt tidligere bud om at mikrotjenester skal gjøre en bestemt ting. Det er lett å si, men i praksis er funksjonalitet ofte sammenflettet, og tegning av divisjoner er vanskeligere enn det ser ut. Domeneanalyse og domenedrevet design er de teoretiske tilnærmingene som vil hjelpe deg med å plage din store oppgave i individuelle problemer som en mikroservice kan løse. I denne prosessen, skissert i en lysende serie blogginnlegg fra Microsoft, lager du en abstrakt modell av forretningsdomenet ditt, og oppdager i prosessen de avgrensede kontekstene, som grupperer sammen funksjonalitet som samhandler med verden på en bestemt måte.
For eksempel kan du ha en avgrenset kontekst for frakt og en annen for kontoer. Et fysisk objekt fra den virkelige verden vil ha både en pris og et sted den må gå, selvfølgelig, men de avgrensede kontekstene representerer spesifikke måter applikasjonen din tenker på og samhandler med disse objektene. Hver mikroservice skal eksistere helt innenfor en enkelt avgrenset kontekst, selv om noen avgrensede sammenhenger kan omfatte mer enn én mikroservice.
Microservices vs. serviceorientert arkitektur vs. webtjenester
På dette punktet, hvis du er en IT-proff som har vært rundt i bransjen en stund, kan du synes mye av dette høres kjent ut. Ideen om små individuelle programmer som samarbeider, kan minne deg om både SOA (serviceorientert arkitektur) og webtjenester, to moteord fra de berusende Web 2.0-dagene på 2000-tallet. Mens det på en måte virkelig ikke er noe nytt under solen, er det viktige skiller mellom disse konseptene og mikrotjenestene. Datamation har en god oversikt over forskjellene, men her er en kort versjon:
- I en serviceorientert arkitektur er enkeltkomponenter relativt tett koblet, og deler ofte eiendeler som lagring, og de kommuniserer gjennom et stykke spesialisert programvare som kalles en enterprise storage bus. Mikrotjenester er mer uavhengige, deler færre ressurser og kommuniserer via flere lette protokoller. Det er verdt å merke seg at mikrotjenester oppsto fra SOA-miljøet, og noen ganger betraktes som en slags SOA, eller etterfølger til konseptet.
- En webtjeneste er et sett med funksjonalitet som andre applikasjoner har tilgang til via nettet; sannsynligvis det vanligste eksemplet er Google Maps, som nettstedet til en restaurant kan bygge inn for å gi veibeskrivelse til kundene. Dette er en mye løsere forbindelse enn du ville sett i en mikrotjenestearkitektur.
Kommunikasjon med mikrotjenester
Et slagord du ofte vil høre om mikrotjenestearkitekturer, er at de skal inneholde "smarte endepunkter og dumme rør." Med andre ord, mikrotjenester skal ha som mål å bruke grunnleggende og veletablerte kommunikasjonsmetoder i stedet for kompleks og tett integrering. Som nevnt er dette en annen ting som skiller mikrotjenester fra SOA.
Generelt sett skal kommunikasjon mellom mikrotjenester være asynkron, i den forstand at kodetråder ikke er blokkert og venter på svar. (Det er fortsatt greit å bruke synkron kommunikasjonsprotokoller som HTTP, selv om asynkrone protokoller som AMQP (Advanced Message Queuing Protocol) også er vanlige i mikrotjenestearkitekturer.) Denne typen løs kobling gjør en mikrotjenestearkitektur mer fleksibel i lys av feilen av enkelte komponenter eller deler av nettverket, noe som er en viktig fordel.
Microservices, Java og Spring Boot og Spring Cloud
Noe av det første arbeidet med mikrotjenester oppsto i Java-samfunnet; Martin Fowler var en tidlig talsmann. En Java-konferanse i Polen i 2012 inneholdt en av de viktigste tidlige presentasjonene om emnet, med tittelen “Micro services - Java, the Unix Way.” Den anbefalte å bruke prinsippene som styrte utviklingen av de første Unix-applikasjonene på 1970-tallet (“Skriv programmer som gjør en ting og gjør det bra. Skriv programmer for å jobbe sammen ”) til Java-utvikling.
Som et resultat av denne historien er det mange Java-rammer som gjør det mulig å bygge mikrotjenester. En av de mest populære er Spring Boot, som er spesielt designet for mikrotjenester; Boot er utvidet av Spring Cloud, som som navnet antyder, lar deg også distribuere disse tjenestene til skyen. Pivotal Software, utvikleren av Spring, har en god veiledning om å komme i gang med utvikling av mikroservice ved hjelp av disse rammene.
Mikrotjenester og beholdere: Docker, Kubernetes og videre
Den underliggende teknologien som har gått lengst mot å få mikrotjenester inn i mainstream er containere. En container ligner på en VM-forekomst, men i stedet for å inkludere et helt selvstendig operativsystem, er en container bare et isolert brukerområde som bruker vertsoperativsystemets kjerne, men ellers holder koden utført inne i den selvstendig. Beholdere er mye mindre enn VM-forekomster og er enkle å distribuere raskt, enten lokalt eller i skyen, og kan spinnes opp eller ned for å matche etterspørsel og tilgjengelige ressurser.
Appellen til containere for mikrotjenester bør være åpenbar: Hver enkelt mikrotjeneste kan kjøre i sin egen container, noe som reduserer kostnadene ved å administrere tjenester betydelig. De fleste containerimplementeringer har komplementære orkestreringsverktøy som automatiserer distribusjon, administrasjon, skalering, nettverksbygging og tilgjengelighet av containerbaserte applikasjoner. Det er kombinasjonen av små, enkle å bygge mikrotjenester og containere som er enkle å distribuere som gjør devops-filosofien mulig. Det er flere implementeringer av containerkonseptet, men den aller mest populære er Docker, som vanligvis er parret med Kubernetes som en orkestrasjonsplattform.
Våren, mens den er populær, er knyttet til Java-plattformen. Containerbaserte systemer er derimot polyglot: Ethvert programmeringsspråk som operativsystemet støtter, kan kjøres i en container, noe som gir programmerere mer fleksibilitet. Faktisk er en stor fordel med mikrotjenester at hver enkelt tjeneste kan skrives på hvilket språk som er mest fornuftig eller som utviklere er mest komfortable med. En tjeneste kan faktisk bygges helt om på et nytt språk uten å påvirke systemet som helhet, så lenge API-ene forblir stabile. DZone har en artikkel som diskuterer fordeler og ulemper ved Spring Cloud vs. Kubernetes for mikrotjenester.
Microservices designmønstre
Uansett hvilket språk du bruker for å utvikle mikrotjenester, vil du møte problemer som andre utviklere har opplevd før. Designmønstre er formaliserte, abstrakte løsninger på gjentatte problemer innen informatikk, og en rekke av dem er spesielt for mikrotjenester. Devopedia har en flott liste, som inkluderer:
- Service Register: for å koble klienter til tilgjengelige forekomster av mikrotjenester
- Circuit Breaker: for å forhindre at mislykkede tjenester blir ringt gjentatte ganger
- Tilbakeslag: for å tilby et alternativ til en mislykket tjeneste
- Sidevogn: for å tilby en ekstra tjeneste til hovedcontaineren, for eksempel for logging, synkronisering av tjenester eller overvåking
- Adapter: for å standardisere eller normalisere grensesnittet mellom hovedbeholderen og den eksterne verdenen
- Ambassadør: for å koble hovedcontaineren til omverdenen, for eksempel for proxying av lokale vertsforbindelser til eksterne forbindelser
Mikrotjenester og skyen: AWS og Azure
Som nevnt ovenfor er en av fordelene med å bruke containere at de enkelt kan distribueres til skyen, der fleksible beregningsressurser er tilgjengelige, slik at du kan maksimere applikasjonens effektivitet. Som du kanskje forestiller deg, er de store offentlige skyleverandørene ivrige etter at du bruker plattformene sine til å kjøre dine mikroservicebaserte apper. For mer informasjon, sjekk ut ressursene fra Amazon, Microsoft og Google.
