En av endringene som skjer innen IT under banneret av digital transformasjon er nedbryting av store, monolitiske applikasjoner til mikrotjenester—små, diskrete funksjonalitetsenheter - som kjører i containere—programvarepakker som inkluderer all tjenestens kode og avhengigheter som kan isoleres og enkelt flyttes fra en server til en annen.
Containeriserte arkitekturer som disse er enkle å skalere opp og kjøre i skyen, og individuelle mikrotjenester kan raskt rulles ut og gjentas. Imidlertid blir kommunikasjonen mellom disse mikrotjenestene stadig mer kompleks etter hvert som applikasjoner blir større og flere forekomster av den samme tjenesten kjøres samtidig. Et servicenett er en fremvoksende arkitektonisk form som tar sikte på å koble disse mikrotjenestene dynamisk på en måte som reduserer administrasjons- og programmeringsomkostninger.
Hva er et servicenett?
I vid forstand er et servicenett, som Red Hat beskriver det, "en måte å kontrollere hvordan forskjellige deler av et program deler data med hverandre." Denne beskrivelsen kan imidlertid omfatte mange forskjellige ting. Faktisk høres det veldig ut som mellomvare som de fleste utviklere er kjent med fra klientserver-applikasjoner.
Det som gjør et servicenett unikt, er at det er bygget for å imøtekomme den unike naturen til distribuerte mikroservicemiljøer. I et stort program bygget fra mikrotjenester kan det være flere forekomster av en hvilken som helst tjeneste, som kjører på tvers av lokale eller skyservere. Alle disse bevegelige delene gjør det åpenbart vanskelig for individuelle mikrotjenester å finne de andre tjenestene de trenger å kommunisere med. Et servicenett tar seg automatisk av å oppdage og koble til tjenester øyeblikkelig, slik at både menneskelige utviklere og individuelle mikrotjenester ikke trenger å gjøre det.
Tenk på et servicenett som tilsvarer programvaredefinert nettverk (SDN) for nivå 7 i OSI-nettverksmodellen. Akkurat som SDN lager et abstraksjonslag slik at nettverksadministratorer ikke trenger å forholde seg til fysiske nettverkstilkoblinger, kobler et servicenett den underliggende infrastrukturen til applikasjonen fra den abstrakte arkitekturen du kommuniserer med.
Ideen om et servicenett oppsto organisk da utviklere begynte å takle problemene med virkelig enorme distribuerte arkitekturer. Linkerd, det første prosjektet i dette området, ble født som et utløp for et internt prosjekt på Twitter. Istio, et annet populært servicenett med stor bedriftsstøtte, stammer fra Lyft. (Vi vil se nærmere på begge disse prosjektene om et øyeblikk.)
Lastbalansering av servicenett
En av nøkkelegenskapene et servicenett gir er lastbalansering. Vi tenker vanligvis på lastbalansering som en nettverksfunksjon - du vil forhindre at en server eller nettverkskobling blir overveldet av trafikk, så du ruter pakkene dine deretter. Servicemasker gjør noe lignende på applikasjonsnivå, som Twain Taylor beskriver, og forståelse som gir deg en god følelse av hva vi mener når vi sier at et servicenett er som programvaredefinert nettverk for applikasjonslaget.
I hovedsak er en av jobbene til servicenettet å holde rede på hvilke forekomster av ulike mikrotjenester fordelt på infrastrukturen som er "sunneste." Det kan avstemme dem for å se hvordan de har det, eller holde rede på hvilke forekomster som reagerer sakte på tjenesteforespørsler og sende etterfølgende forespørsler til andre forekomster. Servicenettet kan gjøre lignende arbeider for nettverksruter, og merker når meldinger tar for lang tid å komme til destinasjonen, og tar andre ruter for å kompensere. Disse forsinkelsene kan skyldes problemer med den underliggende maskinvaren, eller rett og slett til at tjenestene blir overbelastet med forespørsler eller arbeider med deres behandlingskapasitet. Det viktige er at servicenettet kan finne en annen forekomst av samme tjeneste og rute til den i stedet, og dermed utnytte kapasitetens samlede applikasjon mest effektivt.
Servicenett mot Kubernetes
Hvis du er litt kjent med containerbaserte arkitekturer, lurer du kanskje på hvor Kubernetes, den populære open source containerorkestrasjonsplattformen, passer inn i dette bildet. Tross alt, er ikke hele poenget med Kubernetes at det styrer hvordan containerne dine kommuniserer med hverandre? Som Kublr-teamet påpeker på bedriftens blogg, kan du tenke på Kubernetes “service” -ressurs som en veldig grunnleggende type servicenett, da det gir serviceoppdagelse og balansering av forespørsler. Men fullverdige servicenettverk gir mye mer funksjonalitet, som å administrere sikkerhetsretningslinjer og kryptering, "kretsløp" for å avbryte forespørsler om sakte reagerende forekomster, belastningsbalansering som beskrevet ovenfor og mye mer.
Husk at de fleste servicemasker faktisk krever at et orkestrasjonssystem som Kubernetes er på plass. Servicemasker tilbyr utvidet funksjonalitet, ikke erstatning.
Servicenett mot API-gateways
Hver mikrotjeneste vil gi et applikasjonsprogrammeringsgrensesnitt (API) som fungerer som et middel som andre tjenester kommuniserer med det. Dette reiser spørsmålet om forskjellene mellom et servicenett og andre mer tradisjonelle former for API-administrasjon, som API-gateways. Som IBM forklarer, står en API-gateway mellom en gruppe mikrotjenester og den "utenfor" verden, og rutetjenesteforespørsler etter behov, slik at rekvirenten ikke trenger å vite at den har å gjøre med en mikrotjenestebasert applikasjon. Et servicenett, derimot, formidler forespørsler "inne" i mikroserviceappen, hvor de forskjellige komponentene er fullstendig klar over miljøet.
En annen måte å tenke på det, som Justin Warren skriver inn Forbes, er at et servicenett er for øst-vest-trafikk i en klynge, og en API-gateway er for nord-sør-trafikk som går inn og ut av klyngen. Men hele ideen om et servicenett er fortsatt tidlig og i flyt. Mange servicenettverk - inkludert Linkerd og Istio - tilbyr nå også nord-sør-funksjonalitet.
Service mesh arkitektur
Ideen om et servicenett har dukket opp bare de siste par årene, og det er mange forskjellige tilnærminger for å løse "servicenett" -problemet, dvs. administrere kommunikasjon for mikrotjenester. Andrew Jenkins fra Aspen Mesh identifiserer tre mulige valg angående hvor kommunikasjonslaget som er opprettet av servicenettet kan leve:
- I en bibliotek som hver av mikrotjenestene dine importerer
- I en node-agent som gir tjenester til alle containere på en bestemt node
- I en sidevogn container som kjører sammen med applikasjonsbeholderen din
Sidevognbasert mønster er et av de mest populære servicemaskemønstrene der ute - så mye at det på noen måter har blitt synonymt med servicemasker generelt. Selv om det ikke er strengt tatt sant, har sidevogntilnærmingen fått så mye trekk at dette er arkitekturen vi skal se nærmere på.
Sidevogner i servicenett
Hva betyr det å si at en sidevogncontainer "kjører ved siden av" applikasjonscontaineren din? Red Hat har en ganske god forklaring. Hver mikrotjenestebeholder i et servicenett av denne typen har en annen proxy-container som tilsvarer den. All logikken som kreves for kommunikasjon mellom tjeneste og tjeneste, trekkes ut av mikroservicen og settes inn i sidevognen.
Dette kan virke komplisert - når alt kommer til alt dobler du antallet containere i applikasjonen din! Men du bruker også et designmønster som er nøkkelen til å forenkle distribuerte apper. Ved å sette all den nettverks- og kommunikasjonskoden i en egen container, har du gjort den til en del av infrastrukturen og frigjort utviklere fra å implementere den som en del av applikasjonen.
I det vesentlige er det du har igjen en mikroservice som kan være laserfokusert på forretningslogikken. Microservice trenger ikke å vite hvordan de skal kommunisere med alle de andre tjenestene i det ville og sprø miljøet der de opererer. Det trenger bare å vite hvordan man skal kommunisere med sidevognen, som tar seg av resten.
Servicemasker: Linkerd, Envio, Istio, konsul
Så hva er servicenettene som er tilgjengelige for bruk? Vel, det er ikke akkurat kommersielle produkter der ute. De fleste servicenettverk er åpen kildekode-prosjekter som det tar litt finagling å implementere. De store navnene er:
- Linkerd (uttales "linker-dee") - Utgitt i 2016, og dermed den eldste av disse tilbudene, ble Linkerd spunnet av fra et bibliotek utviklet på Twitter. En annen tung hit i dette rommet, Conduit, ble rullet inn i Linkerd-prosjektet og danner grunnlaget for Linkerd 2.0.
- Envoy — Opprettet i Lyft, opptar Envoy “dataplan” -delen av et servicenett. For å gi et fullservicenett, må det sammenkobles med et "kontrollplan", som ...
- Istio — Istio er utviklet i samarbeid av Lyft, IBM og Google og er en kontrollplan for å betjene fullmakter som Envoy. Mens Istio og Envoy er et standardpar, kan hver sammenkobles med andre plattformer.
- HashiCorp Consul — Introdusert med Consul 1.2, en funksjon kalt Connect lagt til tjenestekryptering og identitetsbasert autorisasjon til HashiCorps distribuerte system for tjenesteoppdagelse og konfigurasjon, og gjør det til et fullservicenett.
Hvilket servicenett passer for deg? En sammenligning ligger utenfor omfanget av denne artikkelen, men det er verdt å merke seg at alle produktene ovenfor er bevist i store og krevende miljøer. Linkerd og Istio har de mest omfattende funksjonssettene, men alle utvikler seg raskt. Det kan være lurt å sjekke George Mirandas oversikt over funksjonene til Linkerd, Envoy og Istio, men husk at artikkelen hans ble skrevet før Conduit og Linkerd gikk sammen.
Husk også at dette rommet er nytt, og at nye konkurrenter kan dukke opp når som helst. For eksempel begynte Amazon i november 2018 å tilby en offentlig forhåndsvisning av et AWS-servicenett. Med tanke på hvor mange butikker som bruker Amazons offentlige sky, bør AWS App Mesh ha stor innvirkning.
