En af de skift, der sker inden for it under banneret af digital transformation, er nedbrydning af store, monolitiske applikationer i mikrotjenester—små, diskrete enheder af funktionalitet - der kører i containere—softwarepakker, der indeholder alle tjenestens kode og afhængigheder, der kan isoleres og let flyttes fra en server til en anden.
Containeriserede arkitekturer som disse er lette at opskalere og køre i skyen, og individuelle mikrotjenester kan hurtigt rulles ud og gentages. Kommunikation mellem disse mikrotjenester bliver imidlertid mere og mere kompleks, da applikationer bliver større, og flere forekomster af den samme service kører samtidigt. Et servicenet er en voksende arkitektonisk form, der har til formål at dynamisk forbinde disse mikrotjenester på en måde, der reducerer administrations- og programmeringsomkostninger.
Hvad er et servicenet?
I bred forstand er et servicenet, som Red Hat beskriver det, "en måde at kontrollere, hvordan forskellige dele af en applikation deler data med hinanden." Denne beskrivelse kunne dog omfatte mange forskellige ting. Faktisk lyder det meget ligesom den middleware, som de fleste udviklere er bekendt med fra klientserverapplikationer.
Det, der gør et servicenet unikt, er, at det er bygget til at imødekomme distribuerede mikroservicemiljøers unikke natur. I en applikation i stor skala bygget fra mikrotjenester kan der være flere forekomster af en given tjeneste, der kører på tværs af forskellige lokale servere eller cloud-servere. Alle disse bevægelige dele gør det naturligvis vanskeligt for individuelle mikrotjenester at finde de andre tjenester, de har brug for at kommunikere med. Et servicenet sørger automatisk for at opdage og forbinde tjenester på et øjeblik-til-øjeblik-basis, så det ikke er nødvendigt for både menneskelige udviklere og individuelle mikrotjenester.
Tænk på et servicenetværk svarende til softwaredefineret netværk (SDN) til niveau 7 i OSI-netværksmodellen. Ligesom SDN opretter et abstraktionslag, så netværksadministratorer ikke behøver at håndtere fysiske netværksforbindelser, afkobler et servicenetværk den underliggende infrastruktur i applikationen fra den abstrakte arkitektur, som du interagerer med.
Idéen om et servicenet opstod organisk, da udviklere begyndte at kæmpe med problemerne med virkelig enorme distribuerede arkitekturer. Linkerd, det første projekt inden for dette område, blev født som en udløber af et internt projekt på Twitter. Istio, et andet populært servicenet med større virksomhedsopbakning, stammer fra Lyft. (Vi vil se nærmere på begge disse projekter om et øjeblik.)
Servicenet belastningsbalancering
En af nøglefunktionerne, som et servicenet giver, er belastningsbalancering. Vi tænker normalt på belastningsafbalancering som en netværksfunktion - du vil forhindre en server eller et netværkslink i at blive overvældet af trafik, så du ruter dine pakker i overensstemmelse hermed. Servicemaske gør noget lignende på applikationsniveau, som Twain Taylor beskriver, og forståelse, der giver dig en god fornemmelse af, hvad vi mener, når vi siger, at et servicenetværk er som softwaredefineret netværk for applikationslaget.
I det væsentlige er et af opgaverne i servicenettet at holde styr på, hvilke forekomster af forskellige mikrotjenester, der er fordelt på tværs af infrastrukturen, er "sundeste." Det kan afstemme dem for at se, hvordan de har det, eller holde styr på, hvilke forekomster der reagerer langsomt på serviceanmodninger og sende efterfølgende anmodninger til andre forekomster. Servicenettet kan udføre lignende arbejde for netværksruter og bemærke, når meddelelser tager for lang tid at komme til deres destination, og tage andre ruter for at kompensere. Disse afmatninger kan skyldes problemer med den underliggende hardware eller simpelthen at tjenesterne er overbelastet med anmodninger eller arbejder ved deres behandlingskapacitet. Det vigtige er, at servicenettet kan finde en anden forekomst af den samme tjeneste og rute til den i stedet, hvilket således gør den mest effektive brug af den samlede applikations kapacitet.
Servicenet mod Kubernetes
Hvis du er lidt fortrolig med containerbaserede arkitekturer, undrer du dig måske over, hvor Kubernetes, den populære open source container orkestreringsplatform, passer ind i dette billede. Når alt kommer til alt, er ikke hele pointen med Kubernetes, at den styrer, hvordan dine containere kommunikerer med hinanden? Som Kublr-teamet påpeger på deres virksomhedsblog, kunne du tænke på Kubernetes '"service" -ressource som en meget grundlæggende form for servicenet, da det giver serviceopdagelse og afbalancering af anmodninger. Men fuldt udstyrede servicemasker giver meget mere funktionalitet, som styring af sikkerhedspolitikker og kryptering, "kredsløb" for at suspendere anmodninger om langsomt reagerende forekomster, belastningsafbalancering som beskrevet ovenfor og meget mere.
Husk, at de fleste servicemaske faktisk kræver, at et orkestrationssystem som Kubernetes er på plads. Servicemasker tilbyder udvidet funktionalitet, ikke en erstatning.
Servicemesh mod API-gateways
Hver mikroservice leverer en applikationsprogrammeringsgrænseflade (API), der fungerer som det middel, hvormed andre tjenester kommunikerer med det. Dette rejser spørgsmålet om forskellene mellem et servicenetværk og andre mere traditionelle former for API-styring, som API-gateways. Som IBM forklarer, står en API-gateway mellem en gruppe af mikrotjenester og "omverdenen" og routing af serviceanmodninger efter behov, så rekvirenten ikke behøver at vide, at den har at gøre med en mikroservicebaseret applikation. Et servicenetværk formidler på den anden side anmodninger "inde" i mikroserviceappen, hvor de forskellige komponenter er fuldt opmærksomme på deres miljø.
En anden måde at tænke på det, som Justin Warren skriver i Forbes, er, at et servicenet er til øst-vest-trafik inden for en klynge, og en API-gateway er til nord-syd-trafik, der går ind og ud af klyngen. Men hele ideen om et servicenet er stadig tidligt og i bevægelse. Mange servicemasker - inklusive Linkerd og Istio - tilbyder nu også nord-syd-funktionalitet.
Service mesh-arkitektur
Idéen om et servicenetværk er først opstået i de sidste par år, og der er mange forskellige tilgange til løsning af "servicenet" -problemet, dvs. styring af kommunikation til mikrotjenester. Andrew Jenkins fra Aspen Mesh identificerer tre mulige valg vedrørende, hvor kommunikationslaget oprettet af servicenettet muligvis lever:
- I en bibliotek at hver af dine mikrotjenester importerer
- I en knudepunktagent der leverer tjenester til alle containere på en bestemt node
- I en sidevogn container, der kører sammen med din applikationscontainer
Sidevognbaseret mønster er et af de mest populære servicemaskemønstre derude - så meget, at det på nogle måder er blevet synonymt med servicemasker generelt. Selvom det ikke strengt taget er sandt, har sidevogn tilgang fået så meget trækkraft, at dette er den arkitektur, vi vil se nærmere på.
Sidevogne i servicenet
Hvad betyder det at sige, at en sidevogncontainer "kører sammen" med din applikationscontainer? Red Hat har en ret god forklaring. Hver mikrotjenestebeholder i et servicenetværk af denne type har en anden proxykontainer, der svarer til den. Al den logik, der kræves til service-til-service-kommunikation, uddrages af mikroservicen og lægges i sidevognen.
Dette kan virke kompliceret - når alt kommer til alt fordobler du effektivt antallet af containere i din applikation! Men du bruger også et designmønster, der er nøglen til at forenkle distribuerede apps. Ved at sætte al den netværks- og kommunikationskode i en separat container, har du gjort den til en del af infrastrukturen og befriet udviklere fra at implementere den som en del af applikationen.
I det væsentlige er det, du har tilbage, en mikroservice, der kan være laserfokuseret på dens forretningslogik. Mikroservicen behøver ikke at vide, hvordan man kommunikerer med alle de andre tjenester i det vilde og skøre miljø, hvor de opererer. Det behøver kun at vide, hvordan man kommunikerer med sidevognen, som tager sig af resten.
Servicemasker: Linkerd, Envio, Istio, konsul
Så hvad er servicemaskerne tilgængelige til brug? Der er ikke ligefrem kommercielle produkter på hylden derude. De fleste servicenetværk er open source-projekter, som det tager lidt finagling at gennemføre. De store navne er:
- Linkerd (udtalt "linker-dee") - Udgivet i 2016, og dermed den ældste af disse tilbud, blev Linkerd udskilt fra et bibliotek udviklet på Twitter. En anden tung hitter i dette rum, Conduit, blev rullet ind i Linkerd-projektet og danner grundlaget for Linkerd 2.0.
- Envoy - Oprettet i Lyft indtager Envoy "dataplan" -delen af et servicenet. For at give et fuldt servicenet skal det parres med et "kontrolplan" som ...
- Istio — Istio er udviklet i samarbejde af Lyft, IBM og Google og er en kontrolplan til service af proxyer som Envoy. Mens Istio og Envoy er et standardpar, kan hver parres med andre platforme.
- HashiCorp Consul - Introduceret med Consul 1.2, en funktion kaldet Connect tilføjede tjenestekryptering og identitetsbaseret autorisation til HashiCorps distribuerede system til serviceopdagelse og konfiguration, hvilket gør det til et fuldt servicenetværk.
Hvilket servicenet passer til dig? En sammenligning ligger uden for denne artikels anvendelsesområde, men det er værd at bemærke, at alle ovenstående produkter er blevet bevist i store og krævende miljøer. Linkerd og Istio har de mest omfattende funktions sæt, men alle udvikler sig hurtigt. Det kan være en god idé at tjekke George Mirandas sammenfatning af funktionerne i Linkerd, Envoy og Istio, men husk at hans artikel blev skrevet før Conduit og Linkerd gik sammen.
Husk også, at dette rum er nyt, og at nye konkurrenter kan dukke op når som helst. For eksempel begyndte Amazon i november 2018 at tilbyde en offentlig forhåndsvisning af et AWS-servicenet. I betragtning af hvor mange butikker der bruger Amazons offentlige sky, bør AWS App Mesh have stor indflydelse.
