Bemærk. overs.: Service mesh er et fænomen, der endnu ikke har en stabil oversættelse til russisk (mere end 2 år siden foreslog vi muligheden "mesh for services", og lidt senere begyndte nogle kolleger aktivt at fremme kombinationen "service sieve"). Konstant snak om denne teknologi har ført til en situation, hvor marketing og tekniske komponenter er for tæt sammenflettet. Dette vidunderlige materiale fra en af forfatterne til det originale udtryk er beregnet til at give klarhed for ingeniører og andre.
Tegneserie fra
Indledning
Hvis du er en softwareingeniør, der arbejder et sted i backend-systemer, er udtrykket "service mesh" sandsynligvis allerede blevet fast forankret i dit sind i løbet af de sidste par år. Takket være en mærkelig tilfældighed overtager denne sætning branchen mere og mere, og hypen og de kampagnetilbud, der er forbundet med den, vokser som en snebold, der flyver ned ad bakke og viser ingen tegn på at bremse farten.
Tjenestenet blev født i det skumle, forudindtagede vand i det cloud-native økosystem. Desværre betyder det, at meget af kontroversen omkring det spænder fra "snak med lavt kalorieindhold" til - for at bruge et teknisk udtryk - direkte nonsens. Men skærer du igennem al støjen, vil du opdage, at servicemasken har en meget reel, defineret og vigtig funktion.
I dette indlæg vil jeg prøve at gøre netop det: give en ærlig, dybdegående, ingeniør-fokuseret guide til servicenetværk. Jeg vil ikke bare svare på spørgsmålet: "Hvad er det?", - men også "Hvorfor?"og "Hvorfor nu?". Til sidst vil jeg prøve at skitsere, hvorfor (efter min mening) netop denne teknologi har skabt så vanvittig opsigt, hvilket er en interessant historie i sig selv.
Hvem er jeg?
Hej alle! Mit navn er . Jeg er en af skaberne — det allerførste service mesh-projekt og det projekt, der er skyld i udtrykkets udseende servicenet som sådan (undskyld gutter!). (Bemærk oversættelse.: Forresten, ved begyndelsen af dette udtryks udseende, for mere end 2,5 år siden, oversatte vi allerede det tidlige materiale fra den samme forfatter med titlen ". ") Jeg leder også er en startup, der skaber fede service mesh-ting som Linkerd og .
Du kan sikkert gætte, at jeg har en meget forudindtaget og subjektiv holdning til dette spørgsmål. Jeg vil dog forsøge at holde bias på et minimum (med undtagelse af et afsnit: "Hvorfor er der så meget snak om servicenet?", - hvori jeg stadig vil dele mine forudfattede ideer). Jeg vil også gøre mit bedste for at gøre denne guide så objektiv som muligt. For specifikke eksempler vil jeg primært stole på Linkerds erfaring, samtidig med at jeg påpeger forskelle (hvis nogen), som jeg kender til i implementeringen af andre service mesh-typer.
Okay, tid til at gå videre til godbidderne.
Hvad er et servicenet?
På trods af al hypen er strukturen af servicemasken ret enkel. Dette er blot en flok brugerrumsproxyer placeret "ved siden af" tjenesterne (vi taler lidt om, hvad "næste" er senere), plus et sæt kontrolprocesser. Fuldmagterne kaldes samlet dataplan, og kontrolprocesserne kaldes kontrolplan. Dataplanet opsnapper opkald mellem tjenester og laver "alle mulige forskellige ting" med dem; Kontrolplanet koordinerer følgelig proxyens adfærd og giver adgang til dig, dvs. operatør, til API'et, så netværket kan manipuleres og måles som en helhed.
Hvad er det for en proxy? Dette er en Layer 7-bevidst TCP-proxy (dvs. "under hensyntagen til" lag 7 i OSI-modellen) som HAProxy og NGINX. Du kan vælge en proxy efter din smag; Linkerd bruger en Rust-proxy, blot navngivet . Vi sætter det sammen specifikt til servicenet. Andre masker foretrækker andre fuldmagter (Envoy er et almindeligt valg). Men at vælge en proxy er kun et spørgsmål om implementering.
Hvad gør disse proxy-servere? Det er klart, at de proxy-opkald til og fra tjenester (strengt taget fungerer de som proxyer og omvendte proxyer og håndterer både indgående og udgående opkald). Og de implementerer et funktionssæt, der fokuserer på opkald между tjenester. Dette fokus på trafik mellem tjenester er det, der adskiller en servicemesh-proxy fra f.eks. API-gateways eller indgående proxyer (sidstnævnte fokuserer på opkald, der kommer ind i klyngen fra omverdenen). (Bemærk. overs.: For en sammenligning af eksisterende Ingress-controllere til Kubernetes, hvoraf mange bruger den allerede nævnte Envoy, se .)
Så vi har ordnet dataplanet. Kontrolplanet er enklere: Det er et sæt komponenter, der giver al den mekanik, som dataplanet skal bruge for at fungere på en koordineret måde, herunder serviceopdagelse, udstedelse af TLS-certifikater, metrisk aggregering osv. Dataplanet informerer kontrolplanet om dens adfærd; til gengæld giver kontrolplanet en API, der giver dig mulighed for at ændre og overvåge opførselen af dataplanet som helhed.
Nedenfor er et diagram over kontrolplanet og dataplanet i Linkerd. Som du kan se, omfatter kontrolplanet flere forskellige komponenter, herunder en Prometheus-instans, der indsamler metrics fra proxy-servere, samt andre komponenter som f.eks. destination (tjenesteopdagelse), identity (certifikatmyndighed, CA) og public-api (endepunkter for web og CLI). I modsætning hertil er dataplanet en simpel linkerd-proxy ved siden af applikationsforekomsten. Dette er blot et logisk diagram; I en implementering i den virkelige verden har du muligvis tre replikaer af hver kontrolplankomponent og hundredvis eller tusinder af proxyer i dataplanet.
(De blå rektangler i dette diagram symboliserer grænserne for Kubernetes pods. Du kan se, at beholderne med linkerd-proxy er i samme pod som applikationsbeholderne. Dette skema er kendt som sidevognscontainer.)
Service mesh-arkitektur har flere vigtige implikationer. For det første, da en proxys opgave er at aflytte opkald mellem tjenester, giver et servicemesh kun mening, hvis din applikation blev oprettet til et bestemt sæt tjenester. Mesh man kan brug med monolitter, men dette er klart overflødigt af hensyn til én enkelt proxy, og dets funktionalitet vil næppe være efterspurgt.
En anden vigtig konsekvens er, at servicemasken kræver kæmpe stor antal fuldmagter. Faktisk knytter Linkerd en linkerd-proxy til hver instans af hver tjeneste (andre implementeringer tilføjer en proxy til hver node/vært/virtuel maskine. Det er alligevel meget). Sådan aktiv brug af fuldmagter medfører i sig selv en række yderligere komplikationer:
- Proxyer i dataplanet skal være hurtig, da der for hvert opkald er et par opkald til proxyen: et på klientsiden, et på serversiden.
- Også fuldmagter bør være lille и letvægts. Hver vil forbruge hukommelse og CPU-ressourcer, og dette forbrug vil vokse lineært med applikationen.
- Du skal bruge en mekanisme til at implementere og opdatere et stort antal proxyer. At gøre det manuelt er ikke en mulighed.
Generelt ser et servicenet sådan ud (i det mindste fra et fugleperspektiv): du installerer en masse userspace-proxyer, der "gør noget" med intern trafik mellem tjenester og bruger et kontrolplan til at overvåge og administrere dem.
Nu er det tid til at stille spørgsmålet "Hvorfor?"
Hvad er et servicenet til?
De, der først stødte på ideen om et servicenet, kunne blive tilgivet for at føle sig lidt frygtsomme. Service mesh-designet betyder, at det ikke kun vil øge latensen i applikationen, men også vil forbruge ressourcer og vil tilføje en masse nye mekanismer i infrastrukturen. Først sætter du et servicenet op, og så ser du pludselig, at du skal servicere hundredvis (hvis ikke tusindvis) af proxyer. Spørgsmålet er, hvem vil frivilligt gøre dette?
Svaret på dette spørgsmål har to dele. For det første kan transaktionsomkostningerne forbundet med implementering af disse proxyer reduceres betydeligt takket være nogle ændringer, der sker i økosystemet (mere om dette senere).
For det andet er en enhed som denne faktisk en fantastisk måde at introducere yderligere logik i systemet på. Ikke kun fordi et servicemesh kan tilføje en masse ny funktionalitet, men også fordi det kan gøres uden at forstyrre økosystemet. Faktisk er hele service mesh-modellen baseret på denne præmis: i et multiservice-system, uanset hvad gør individuelle tjenester, trafik mellem dem er det ideelle punkt at tilføje funktionalitet.
For eksempel, i Linkerd (som i de fleste meshes) er funktionaliteten primært fokuseret på HTTP-kald, inklusive HTTP/2 og gRPC*. Funktionaliteten er ret rig - den kan opdeles i tre klasser:
- Funktioner relateret til pålidelighed. Gentagne anmodninger, timeouts, kanarisk tilgang (trafikopdeling/omdirigering) osv.
- Funktioner relateret til overvågning. Sammenlægning af succesrater, forsinkelser og anmodningsmængder for hver tjeneste eller individuelle retninger; opbygning af topologiske kort over tjenester mv.
- Funktioner relateret til sikkerhed. Gensidig TLS, adgangskontrol mv.
* Fra Linkerds synspunkt er gRPC praktisk talt ikke anderledes end HTTP/2: den bruger bare protobuf i nyttelasten. Fra en udviklers synspunkt er de to ting selvfølgelig forskellige.
Mange af disse mekanismer fungerer på anmodningsniveauet (deraf "L7 proxy"). For eksempel, hvis Foo-tjenesten foretager et HTTP-kald til Bar-tjenesten, kan linkerd-proxyen på Foo-siden udføre intelligent belastningsbalancering og dirigere opkald fra Foo til Bar-instanser baseret på den observerede latens; den kan gentage anmodningen om nødvendigt (og hvis den er idempotent); den kan optage svarkoden og timeout osv. På samme måde kan linkerd-proxy på Bar-siden afvise en anmodning, hvis den ikke er tilladt, eller anmodningsgrænsen overskrides; kan registrere en forsinkelse fra sin side mv.
Proxyer kan også "gøre noget" på forbindelsesniveauet. For eksempel kan linkerd-proxy på Foo-siden starte en TLS-forbindelse, og linkerd-proxy på Bar-siden kan afslutte den, og begge sider kan verificere hinandens TLS-certifikater*. Dette giver ikke kun kryptering mellem tjenester, men også en kryptografisk sikker måde at identificere tjenester på: Foo og Bar kan "bevise", at de er, som de siger, de er.
* "Mutual of a friend" betyder, at klientcertifikatet også er verificeret (gensidig TLS). I "klassisk" TLS, for eksempel mellem en browser og en server, er certifikatet for kun den ene side (serveren) normalt verificeret.
Uanset om de opererer på anmodnings- eller forbindelsesniveau, er det vigtigt at understrege, at alle servicemesh-funktioner er det operationelle Karakter. Linkerd er ikke i stand til at transformere semantikken af nyttelasten - f.eks. tilføje felter til et JSON-fragment eller foretage ændringer i protobuf. Vi vil tale om denne vigtige funktion senere, når vi taler om ESB og middleware.
Dette er det sæt funktioner, som et servicemesh tilbyder. Spørgsmålet opstår: hvorfor ikke implementere dem direkte i applikationen? Og hvorfor overhovedet bøvle med en proxy?
Hvorfor service mesh er en god idé
Selvom mulighederne for et servicenet er spændende, ligger dets kerneværdi faktisk ikke i dets funktioner. Til sidst vi Kan implementere dem direkte i applikationen (vi vil se senere, at dette var oprindelsen til servicemasken). For at prøve at opsummere det i én sætning er værdien af et servicenet: det giver funktioner, der er afgørende for at køre moderne serversoftware på en ensartet måde på tværs af hele stakken og uafhængig af applikationskode.
Lad os analysere dette forslag.
«Funktioner, der er afgørende for at køre moderne serversoftware" Hvis du opretter en transaktionsserverapplikation, der er forbundet til det offentlige internet, accepterer anmodninger fra omverdenen og svarer på dem inden for kort tid - for eksempel en webapplikation, en API-server og langt de fleste andre moderne applikationer - og hvis du implementerer det som et sæt tjenester, der synkront interagerer med hinanden, og hvis du konstant opgraderer denne software, tilføjer nye funktioner, og hvis du er tvunget til at vedligeholde dette system i funktionsdygtig stand under ændringsprocessen - i denne sag, tillykke, du skaber moderne serversoftware. Og alle disse fantastiske funktioner, der er anført ovenfor, viser sig faktisk at være kritiske for dig. Applikationen skal være pålidelig, sikker, og du skal kunne observere, hvad den gør. Det er præcis de spørgsmål, som service mesh hjælper med at løse.
(OK, det foregående afsnit inkluderer stadig min overbevisning om, at denne tilgang er den moderne måde at skabe serversoftware på. Andre foretrækker at udvikle monolitter, "reaktive mikrotjenester" og andre ting, der ikke falder ind under definitionen ovenfor. Disse mennesker har sandsynligvis deres mening er anderledes end min. Til gengæld tror jeg, at de er "forkerte" - selvom servicemasken under alle omstændigheder ikke er særlig nyttig for dem).
«Uniform for hele stakken" Funktionaliteten fra et servicenet er ikke kun missionskritisk. De gælder for alle tjenester i applikationen, uanset hvilket sprog de er skrevet i, hvilken ramme de bruger, hvem der har skrevet dem, hvordan de blev implementeret og eventuelle andre finesser i deres udvikling og brug.
«Uafhængig af applikationskode" Endelig giver et servicemesh ikke kun ensartet funktionalitet på tværs af hele stakken, det gør det på en måde, der ikke kræver, at applikationen skal redigeres. Det grundlæggende grundlag for service mesh-funktionalitet, herunder opgaver til konfiguration, opdatering, drift, vedligeholdelse osv., ligger helt på platformsniveau og er uafhængig af applikationen. Applikationen kan ændres uden at påvirke servicenetværket. Til gengæld kan servicemasken ændres uden deltagelse fra applikationen.
Kort sagt, et servicenet giver ikke kun vital funktionalitet, men gør det også på en global, ensartet og applikationsuafhængig måde. Og så selvom servicemesh-funktionalitet kan implementeres i servicekode (for eksempel som et bibliotek inkluderet i hver service), vil denne tilgang ikke give den ensartethed og uafhængighed, der er så værdifuld i tilfælde af et servicemesh.
Og alt hvad du skal gøre er at tilføje en masse fuldmagter! Jeg lover, at vi meget snart vil se på driftsomkostningerne forbundet med at tilføje disse fuldmagter. Men lad os først stoppe op og se på denne idé om uafhængighed fra forskellige perspektiver. mennesker.
Hvem hjælper service mesh?
Hvor ubelejligt det end kan være, for at en teknologi kan blive en vigtig del af økosystemet, skal den accepteres af mennesker. Så hvem er interesseret i service mesh? Hvem har gavn af dets brug?
Hvis du udvikler moderne serversoftware, kan du nogenlunde tænke på dit team som en gruppe tjenesteejereder sammen udvikler og implementerer forretningslogik, og platformejere, udvikling af den interne platform, som disse tjenester fungerer på. I små organisationer kan det være de samme mennesker, men efterhånden som virksomheden vokser, har disse roller en tendens til at blive mere udtalte og endda opdelt i underroller... (Der er meget at sige her om devops' skiftende karakter, den organisatoriske virkning af mikrotjenester osv.) n. Men lad os nu tage disse beskrivelser som givne).
Fra dette synspunkt er de klare modtagere af servicenettet platformsejerne. I sidste ende er målet for platformsteamet trods alt at skabe en intern platform, hvor serviceejere kan implementere forretningslogik og gøre det på en måde, der sikrer, at de er så uafhængige som muligt af de uklare detaljer i driften. Ikke alene tilbyder et servicemesh funktioner, der er afgørende for at nå dette mål, det gør det på en måde, der igen ikke pålægger tjenesteejere afhængigheder.
Tjenesteejere kommer også til gode, dog på en mere indirekte måde. Målet for serviceejeren er at være så produktiv som muligt med at implementere logikken i forretningsprocessen, og jo mindre han skal bekymre sig om driftsmæssige problemer, jo bedre. I stedet for at skulle beskæftige sig med at implementere, f.eks. prøve politikker igen eller TLS, kan de udelukkende fokusere på forretningsmål og håbe, at platformen tager sig af resten. Dette er en stor fordel for dem.
Den organisatoriske værdi af en sådan opdeling mellem ejerne af platforme og tjenester kan ikke overvurderes. Jeg tror, hun bidrager det vigtigste bidrag til værdien af servicenettet.
Vi lærte denne lektie, da en tidlig Linkerd-fan fortalte os, hvorfor de valgte servicemesh: fordi det gjorde det muligt for dem at "holde den snakkende butik på et minimum." Her er nogle detaljer: fyrene fra et stort firma migrerede deres platform til Kubernetes. Da applikationen håndterede følsomme oplysninger, ønskede de at kryptere al kommunikation på tværs af klyngerne. Situationen blev dog kompliceret af tilstedeværelsen af hundredvis af tjenester og hundredvis af udviklingsteams. Udsigten til at kontakte alle og overbevise dem om at inkludere TLS-support i deres planer gjorde dem slet ikke glade. Efter at have installeret Linkerd, overførte de ansvar fra udviklere (fra hvilket synspunkt dette var unødvendige problemer) til platformere, for hvem dette var en topprioritet. Linkerd løste med andre ord ikke så meget et teknisk problem for dem, men et organisatorisk problem.
Kort sagt er et servicenet mere en løsning, ikke en teknisk, men socio-teknisk Problemer. (Tak skal du have for at introducere dette udtryk.)
Vil et servicenet løse alle mine problemer?
Ja. Jeg mener, nej!
Hvis du ser på de tre klasser af funktioner, der er skitseret ovenfor – pålidelighed, sikkerhed og observerbarhed – bliver det klart, at et servicenet ikke er en komplet løsning på nogen af disse problemer. Mens Linkerd kan genudsende anmodninger (hvis den ved, at de er idempotente), er den ikke i stand til at træffe beslutninger om, hvad der skal returneres til brugeren, hvis tjenesten er permanent fejlet - disse beslutninger skal træffes af applikationen. Linkerd kan føre statistik over vellykkede anmodninger, men den er ikke i stand til at se på tjenesten og levere dens interne målinger - applikationen skal have sådanne værktøjer. Og selvom Linkerd er i stand til at organisere mTLS, kræver fuldgyldige sikkerhedsløsninger meget mere.
En delmængde af funktionerne i disse områder, der tilbydes af servicenettet, vedrører platforms funktioner. Med dette mener jeg funktioner, der:
- Uafhængig af forretningslogik. Måden, hvorpå opkaldshistogrammer mellem Foo og Bar er konstrueret, er fuldstændig uafhængig af hvorfor Foo ringer til Bar.
- Svært at implementere korrekt. I Linkerd er genforsøg parametriseret med alle mulige smarte ting som genforsøgsbudgetter (prøv budgetter igen), da en usofistikeret, direkte tilgang til implementering af sådanne ting helt sikkert vil føre til fremkomsten af en såkaldt "lavine af anmodninger" (forsøg storm igen) og andre problemer, der er karakteristiske for distribuerede systemer.
- Mest effektiv, når den påføres ensartet. TLS-mekanismen giver kun mening, hvis den anvendes overalt.
Da disse funktioner er implementeret på proxy-niveau (og ikke på applikationsniveau), leverer servicemasken dem på платформы, ikke applikationer. Det er således ikke ligegyldigt, hvilket sprog tjenesterne er skrevet i, hvilke rammer de bruger, hvem der har skrevet dem og hvorfor. Proxyer opererer uden for alle disse detaljer, og det grundlæggende grundlag for denne funktionalitet, herunder opgaver til konfiguration, opdatering, drift, vedligeholdelse osv., ligger udelukkende på platformsniveau.
Eksempler på service mesh-kapaciteter
For at opsummere er et servicenet ikke en komplet løsning for pålidelighed, observerbarhed eller sikkerhed. Omfanget af disse områder kræver deltagelse af serviceejere, Ops/SRE-teams og andre virksomhedsenheder. Servicenettet giver kun et "udsnit" på platformsniveau for hvert af disse områder.
Hvorfor er servicenet blevet populært lige nu?
Nu tænker du sikkert: ok, hvis servicenetværket er så godt, hvorfor begyndte vi så ikke at implementere millioner af proxyer i stakken for ti år siden?
Der er et banalt svar på dette spørgsmål: for ti år siden byggede alle monolitter, og ingen havde brug for et servicenet. Dette er sandt, men efter min mening går dette svar glip af pointen. Selv for ti år siden blev begrebet mikrotjenester som en lovende måde at bygge store systemer på i vid udstrækning diskuteret og anvendt hos virksomheder som Twitter, Facebook, Google og Netflix. Den generelle opfattelse – i hvert fald i de dele af branchen, jeg kom i kontakt med – var, at mikrotjenester var den "rigtige måde" at bygge store systemer på, selvom det var pokkers svært.
Selv om der for ti år siden var virksomheder, der drev mikrotjenester, satte de naturligvis ikke fuldmagter overalt, hvor de kunne, for at danne et servicenet. Men hvis du ser godt efter, gjorde de noget lignende: mange af disse virksomheder krævede brugen af et særligt internt bibliotek til netværkskommunikation (nogle gange kaldet et tykt klientbibliotek, fedt klientbibliotek).
Netflix havde Hysterix, Google havde Stubby, Twitter havde Finagle-biblioteket. Finagle var for eksempel obligatorisk for hver ny tjeneste på Twitter. Det håndterede både klient- og serversiden af forbindelser, tillod gentagne anmodninger, understøttede anmodningsrouting, belastningsbalancering og måling. Det gav et ensartet lag af pålidelighed og observerbarhed på tværs af hele Twitter-stakken, uanset hvad tjenesten lavede. Det fungerede selvfølgelig kun til JVM-sprog og var baseret på en programmeringsmodel, der skulle bruges til hele applikationen. Dens funktionalitet var dog næsten den samme som servicenettets. (Faktisk var den første version af Linkerd simpelthen Finagle pakket ind i proxy-form.)
For ti år siden var der således ikke kun mikrotjenester, men også specielle proto-service-mesh-biblioteker, der løste de samme problemer, som servicemesh løser i dag. Selve servicemasken eksisterede dog ikke dengang. Der skulle et skift mere til, før hun dukkede op.
Og det er her, det dybere svar ligger, skjult i en anden ændring, der er sket i løbet af de sidste 10 år: omkostningerne ved at implementere mikrotjenester er faldet dramatisk. De ovennævnte virksomheder, der brugte mikrotjenester for ti år siden – Twitter, Netflix, Facebook, Google – var virksomheder af enorm skala og enorme ressourcer. De havde ikke kun behovet, men også evnen til at bygge, implementere og drive store mikrotjenester-baserede applikationer. Den energi og indsats, som Twitter-ingeniører lægger i at flytte fra en monolitisk til en mikroservicetilgang, er fantastisk. (For at være retfærdig, så er det faktum, at det lykkedes.) Den slags infrastrukturelle manøvrer var dengang umulige for mindre virksomheder.
Spol frem til nutiden. Der er startups i dag, hvor forholdet mellem mikrotjenester og udviklere er 5:1 (eller endda ), og hvad mere er, de klarer dem med succes! Hvis en startup på 5 personer nemt kan drive 50 mikrotjenester, så har noget klart reduceret omkostningerne ved deres implementering.
1500 mikrotjenester i Monzo; hver linje er en foreskrevet netværksregel, der tillader trafik
Den dramatiske reduktion i omkostningerne ved at drive mikrotjenester er resultatet af én proces: containernes stigende popularitet и orkestratorer. Dette er netop det dybe svar på spørgsmålet om, hvad der bidrog til fremkomsten af servicenettet. Den samme teknologi gjorde både servicemasker og mikrotjenester attraktive: Kubernetes og Docker.
Hvorfor? Nå, Docker løser et stort problem - emballageproblemet. Ved at pakke en applikation og dens (ikke-netværks) runtime-afhængigheder ind i en container, forvandler Docker applikationen til en udskiftelig enhed, der kan hostes og køres hvor som helst. Samtidig forenkler det betjeningen betydeligt flersproget Stak: Fordi en container er en atomisk enhed for udførelse, til udrulning og operationelle formål, er det ligegyldigt, hvad der er indeni, det være sig en JVM-, Node-, Go-, Python- eller Ruby-applikation. Du starter det bare, og det er det.
Kubernetes tager alt til det næste niveau. Nu hvor der er tonsvis af "ting at køre" og tonsvis af maskiner at køre dem på, er der behov for et værktøj, der kan korrelere dem med hinanden. I bred forstand giver du Kubernetes en masse containere og mange maskiner, og det kortlægger dem op mod hinanden (selvfølgelig er dette en dynamisk og konstant foranderlig proces: nye containere flytter rundt i systemet, maskiner starter og stopper osv. Kubernetes tager dog alt dette i betragtning ).
Når Kubernetes er konfigureret, er tidsomkostningerne for at implementere og drive en tjeneste lidt anderledes end prisen for at implementere og drive ti tjenester (faktisk er det næsten det samme for 100 tjenester). Tilføj til dette containere som en pakkemekanisme, der tilskynder til flersproget implementering, og du har et væld af nye applikationer implementeret i form af mikrotjenester skrevet på forskellige sprog - præcis den slags miljø, som et servicenet er så velegnet til.
Så vi kommer til svaret på spørgsmålet om, hvorfor ideen om et servicenet er blevet populært nu: den homogenitet, som Kubernetes leverer til tjenester, gælder direkte for de operationelle udfordringer, som et servicenet står over for. Du pakker proxyerne ind i beholdere, giver Kubernetes opgaven med at klistre dem, hvor det kan, og voila! Som et resultat får du et servicenet, mens al mekanikken i dets implementering administreres af Kubernetes. (I hvert fald set i fugleperspektiv. Selvfølgelig er der mange nuancer i denne proces.)
For at opsummere det: Grunden til, at servicemasker er blevet populære nu, og for ikke ti år siden, er, at Kubernetes og Docker ikke kun er steget markant brug for i det, efter at have forenklet implementeringen af applikationer som sæt af flersprogede mikrotjenester, men også væsentligt reduceret omkostninger for dets drift, tilvejebringelse af mekanismer til implementering og understøttelse af sidevogns proxy-flåder.
Hvorfor er der så meget snak om service mesh?
Advarsel: I dette afsnit gør jeg brug af alle former for antagelser, formodninger, opdigtninger og intern viden.
Søg efter "service mesh", og du vil støde på et væld af genanvendt lavt kalorieindhold, mærkelige projekter og et kalejdoskop af forvrængning, der er et ekkokammer værdigt. Enhver fancy ny teknologi gør dette, men i tilfælde af et servicenet er problemet særligt akut. Hvorfor?
Nå, en del af det er min skyld. Jeg har arbejdet hårdt på at promovere Linkerd og servicenetværket hver chance jeg får gennem utallige blogindlæg og artikler som denne. Men jeg er ikke så stærk. For virkelig at besvare dette spørgsmål er vi nødt til at tale lidt om den overordnede situation. Og det er umuligt at tale om det uden at nævne et projekt: er et open source-servicemesh udviklet i fællesskab af Google, IBM og Lyft.
(De tre virksomheder har meget forskellige roller: Lyfts involvering ser ud til kun at være i navnet; de er forfattere af Envoy, men bruger eller deltager ikke i Istios udvikling. IBM er involveret i og bruger Istios udvikling. Google er aktivt involveret i Istios udvikling. udvikling, men bruger det faktisk ikke, så vidt jeg kan se.)
Istio-projektet er bemærkelsesværdigt for to ting. For det første er der den enorme marketingindsats, som især Google lægger for at promovere det. Jeg vil vurdere, at de fleste, der kender til service mesh-konceptet i dag, først lærte om det gennem Istio. Den anden ting er, hvor dårligt modtaget Istio blev. I denne sag er jeg naturligvis en interesseret part, men at forsøge at forblive så objektiv som muligt, kan jeg stadig ikke hjælpe , ikke særlig karakteristisk (dog ikke unikt: systemd kommer til at tænke på, ...) til et Open Source-projekt.
(I praksis ser Istio ud til at have problemer ikke kun med kompleksitet og UX, men også med ydeevne. F.eks. I en tredjepartsundersøgelse fandt forskerne situationer, hvor Istios halelatens var 100 gange højere end Linkerds, såvel som ressourceudsultede situationer, hvor Linkerd fortsatte med at fungere med succes, mens Istio holdt op med at fungere fuldstændigt.)
Bortset fra mine teorier om, hvorfor dette skete, tror jeg, at den overvældende begejstring omkring servicenetværket er forklaret af Googles deltagelse. Nemlig en kombination af følgende tre faktorer:
- Googles påtrængende promovering af Istio;
- en tilsvarende misbilligende, kritisk holdning til projektet;
- Kubernetes' seneste meteoriske stigning i popularitet, hvis minder stadig er friske.
Tilsammen skaber disse faktorer et forbløffende, iltfrit miljø, hvor evnen til rationel dømmekraft er svækket, og kun den mærkelige variation er tilbage. .
Fra Linkerds perspektiv er dette... hvad jeg vil beskrive som en blandet velsignelse. Jeg mener, det er fantastisk, at service mesh er kommet ind i mainstream på en måde, som det ikke gjorde i 2016, da Linkerd først startede, og det var virkelig svært at få folk til at være opmærksomme på projektet. Nu er der ikke noget sådant problem! Men den dårlige nyhed er, at servicemesh-landskabet er så forvirrende i dag, at det er næsten umuligt at forstå, hvilke projekter der faktisk hører til i servicemesh-kategorien (endsige at forstå, hvilket der er bedst egnet til en bestemt use case). Dette er bestemt en dealbreaker for alle (og der er helt sikkert nogle tilfælde, hvor Istio eller et andet projekt er bedre egnet end Linkerd, da sidstnævnte stadig ikke er en universel løsning).
På Linkerds side har vores strategi været at ignorere støjen, fortsætte med at fokusere på at løse reelle samfundsproblemer og i det væsentlige vente på, at hypen forsvinder. I sidste ende vil hypen aftage, og vi kan fortsætte med at arbejde roligt.
I mellemtiden skal vi alle have lidt tålmodighed.
Vil et servicenet være nyttigt for mig, en ydmyg softwareingeniør?
Følgende spørgeskema vil hjælpe dig med at besvare dette spørgsmål:
Er du udelukkende involveret i implementering af forretningslogik? I dette tilfælde vil servicenettet ikke være nyttigt for dig. Det vil sige, at du selvfølgelig kan være interesseret i det, men ideelt set bør servicenettet ikke direkte påvirke noget i dit miljø. Bliv ved med at arbejde med det, du bliver betalt for at gøre.
Støtter du platformen hos en virksomhed, der bruger Kubernetes? Ja, i dette tilfælde har du brug for et servicenet (medmindre du selvfølgelig bruger K8'er bare til at køre en monolit eller batchbehandling - men så vil jeg gerne spørge, hvorfor du har brug for K8'er). Du vil sandsynligvis ende med en masse mikrotjenester skrevet af forskellige mennesker. De interagerer alle med hinanden og er bundet ind i et virvar af runtime-afhængigheder, og du skal finde en måde at håndtere det hele på. Brug af Kubernetes giver dig mulighed for at vælge et servicenet "til dig selv." For at gøre dette skal du gøre dig bekendt med deres muligheder og funktioner og besvare spørgsmålet om, hvorvidt nogle af de tilgængelige projekter passer til dig (jeg anbefaler at starte din forskning med Linkerd).
Er du en platformsvirksomhed hos en virksomhed, der IKKE bruger Kubernetes, men bruger mikrotjenester? I dette tilfælde vil et servicenet være nyttigt for dig, men dets brug vil være ikke-trivielt. Selvfølgelig kan du efterligne work service mesh ved at placere en masse proxyer, men en vigtig fordel ved Kubernetes er implementeringsmodellen: Manuel vedligeholdelse af disse proxyer vil kræve meget mere tid, kræfter og omkostninger.
Er du ansvarlig for platformen i en virksomhed, der arbejder med monolitter? I dette tilfælde har du sandsynligvis ikke brug for et servicenet. Hvis du arbejder med monolitter (eller endda samlinger af monolitter), der har veldefinerede og sjældent skiftende interaktionsmønstre, så vil et servicenet ikke have meget at tilbyde dig. Så du kan bare ignorere det og håbe på, at det forsvinder som en ond drøm...
Konklusion
Sandsynligvis bør servicenet stadig ikke kaldes "den mest hypede teknologi i verden" - denne tvivlsomme ære tilhører sandsynligvis Bitcoin eller AI. Hun er formentlig i top fem. Men hvis du skærer igennem lagene af støj, bliver det klart, at servicenettet bringer reelle fordele til dem, der bygger applikationer på Kubernetes.
Jeg vil gerne have dig til at prøve Linkerd - installere det på en Kubernetes-klynge (eller endda Minikube på en bærbar computer) , og du kan selv se, hvad jeg taler om.
FAQ
— Hvis jeg ignorerer servicenettet, vil det så forsvinde?
— Jeg må skuffe dig: servicenet er med os i lang tid.
- Men jeg VIL IKKE bruge servicenet!
- Jamen, det er ikke nødvendigt! Bare læs mit spørgeskema ovenfor for at forstå, om du i det mindste bør sætte dig ind i dets grundlæggende.
— Er det ikke gode gamle ESB/mellemvarer med en ny sauce?
— Service mesh omhandler operationel logik, ikke semantisk. enterprise service bus (). Vedligeholdelse af denne adskillelse hjælper servicenettet med at undgå den samme skæbne.
— Hvordan adskiller et servicemesh sig fra API-gateways?
- Der er en million artikler om dette emne. Bare Google det.
— Envoy er et servicenet?
- Nej, Envoy er ikke et servicenet, det er en proxyserver. Det kan bruges til at organisere en service mesh (og meget mere - det er en generel proxy). Men i sig selv er det ikke et servicenet.
— Network Service Mesh er et servicenet?
- Nej. På trods af navnet er dette ikke et servicenet (hvordan kan du lide marketingmirakler?).
— Vil et servicemesh hjælpe med mit beskedkøbaserede reaktive asynkrone system?
- Nej, servicenet hjælper dig ikke.
— Hvilket servicenet skal jeg bruge?
— , logik for burhøns.
- Artiklen stinker! / Forfatteren er velkommen!
— Del venligst linket til det med alle dine venner, så de kan se det!
Tak
Som du måske har gættet ud fra titlen, var denne artikel inspireret af Jay Kreps' fantastiske afhandling "" Jeg mødte Jay for ti år siden, da jeg interviewede ham på Linked In, og han har været en inspiration for mig lige siden.
Selvom jeg kan lide at kalde mig selv en "Linkerd-udvikler", er virkeligheden, at jeg mere er en vedligeholder af filen README.md på et projekt. Linkerd arbejdes der på i dag , , mennesker, og dette projekt ville ikke være sket uden deltagelse af et vidunderligt fællesskab af bidragydere og brugere.
Og til sidst en særlig tak til skaberen af Linkerd, (primus inter pares), der sammen med mig for mange år siden dykkede hovedkulds ned i alt det her postyr med servicenet.
PS fra oversætteren
Læs også på vores blog:
- «";
- «";
- «";
- «";
- «'.
Kilde: www.habr.com