Merk. overs.: Tjenestenett er et fenomen som ennå ikke har en stabil oversettelse til russisk (for mer enn 2 år siden foreslo vi alternativet "nettverk for tjenester", og litt senere begynte noen kolleger å aktivt fremme kombinasjonen "tjenestesikt"). Konstant snakk om denne teknologien har ført til en situasjon der markedsføring og tekniske komponenter er for tett sammenvevd. Dette fantastiske materialet fra en av forfatterne av den originale termen er ment å gi klarhet for ingeniører og andre.
Tegneserie fra
Innledning
Hvis du er en programvareingeniør som jobber et sted i backend-systemer, har begrepet "service mesh" sannsynligvis allerede blitt godt forankret i tankene dine i løpet av de siste par årene. Takket være en merkelig tilfeldighet tar denne setningen mer og mer over bransjen, og hypen og kampanjetilbudene knyttet til den vokser som en snøball som flyr nedoverbakke og viser ingen tegn til å bremse.
Tjenestenett ble født i det grumsete, partiske vannet i det skybaserte økosystemet. Dessverre betyr dette at mye av kontroversen rundt det spenner fra "snakk med lite kalorier" til - for å bruke et teknisk begrep - direkte tull. Men hvis du skjærer gjennom all støyen, vil du oppdage at servicenettet har en veldig reell, definert og viktig funksjon.
I dette innlegget skal jeg prøve å gjøre nettopp det: gi en ærlig, dyptgående, ingeniørfokusert guide til servicenettverk. Jeg skal ikke bare svare på spørsmålet: "Hva det er?", - men også "Hvorfor?"Og "Hvorfor nå?". Til slutt skal jeg prøve å skissere hvorfor (etter min mening) denne teknologien har skapt en så vanvittig oppsikt, som er en interessant historie i seg selv.
Hvem er jeg?
Hei alle sammen! Mitt navn er . Jeg er en av skaperne — det aller første service mesh-prosjektet og prosjektet som er skyld i begrepets utseende servicenett som sådan (beklager folkens!). (Merk overs.: Forresten, ved begynnelsen av utseendet til dette begrepet, for mer enn 2,5 år siden, oversatte vi allerede det tidlige materialet til samme forfatter med tittelen "".) Jeg leder også er en oppstart som lager kule service mesh-ting som Linkerd og .
Du kan sikkert gjette at jeg har en veldig partisk og subjektiv mening om dette spørsmålet. Jeg vil imidlertid prøve å holde partiskhet til et minimum (med unntak av en seksjon: "Hvorfor snakkes det så mye om servicenettverk?", - hvor jeg fortsatt vil dele mine forutinntatte ideer). Jeg vil også gjøre mitt beste for å gjøre denne veiledningen så objektiv som mulig. For spesifikke eksempler vil jeg først og fremst stole på Linkerds erfaring, samtidig som jeg påpeker forskjeller (hvis noen) som jeg kjenner til i implementeringen av andre typer tjenestenettverk.
Ok, på tide å gå videre til godsakene.
Hva er et servicenettverk?
Til tross for all hypen, er strukturen til tjenestenettverket ganske enkelt. Dette er bare en haug med proxy-tjenere som ligger "ved siden av" tjenestene (vi snakker litt om hva "neste" er senere), pluss et sett med kontrollprosesser. Fullmaktene kalles samlet dataplan, og kontrollprosessene kalles kontrollfly. Dataflyet fanger opp samtaler mellom tjenester og gjør «alle mulige forskjellige ting» med dem; Kontrollplanet koordinerer følgelig oppførselen til proxyen og gir deg tilgang, dvs. operatør, til API, slik at nettverket kan manipuleres og måles som en helhet.
Hva slags proxy er dette? Dette er en TCP-proxy som er klar over lag 7 (dvs. "tar i betraktning" lag 7 i OSI-modellen) som HAProxy og NGINX. Du kan velge en proxy etter eget ønske; Linkerd bruker en Rust-proxy, enkelt navngitt . Vi setter den sammen spesielt for service mesh. Andre masker foretrekker andre fullmakter (Envoy er et vanlig valg). Men å velge en proxy er bare et spørsmål om implementering.
Hva gjør disse proxy-serverne? Det er klart at de proxy-anrop til og fra tjenester (strengt tatt fungerer de som proxyer og omvendte proxyer, og håndterer både innkommende og utgående anrop). Og de implementerer et funksjonssett som fokuserer på samtaler между tjenester. Dette fokuset på trafikk mellom tjenester er det som skiller en tjenestemesh-proxy fra for eksempel API-gatewayer eller inngående proxyer (sistnevnte fokuserer på anrop som kommer inn i klyngen fra omverdenen). (Merk. overs.: For en sammenligning av eksisterende Ingress-kontrollere for Kubernetes, hvorav mange bruker den allerede nevnte Envoy, se .)
Så vi har sortert ut dataplanet. Kontrollplanet er enklere: det er et sett med komponenter som gir all mekanikken som dataflyet trenger for å operere på en koordinert måte, inkludert tjenesteoppdagelse, utstedelse av TLS-sertifikater, metrisk aggregering osv. Dataplanet informerer kontrollplanet om dens oppførsel; på sin side gir kontrollplanet et API som lar deg endre og overvåke oppførselen til dataplanet som helhet.
Nedenfor er et diagram over kontrollplanet og dataplanet i Linkerd. Som du kan se inkluderer kontrollplanet flere forskjellige komponenter, inkludert en Prometheus-instans som samler inn beregninger fra proxy-servere, samt andre komponenter som f.eks. destination (tjenesteoppdagelse), identity (sertifikatmyndighet, CA) og public-api (endepunkter for web og CLI). Derimot er dataplanet en enkel linkerd-proxy ved siden av applikasjonsforekomsten. Dette er bare et logisk diagram; I en virkelig distribusjon kan du ha tre replikaer av hver kontrollplankomponent og hundrevis eller tusenvis av proxyer i dataplanet.
(De blå rektanglene i dette diagrammet symboliserer grensene til Kubernetes pods. Du kan se at beholderne med linkerd-proxy er i samme pod som applikasjonsbeholderne. Dette opplegget er kjent som sidevogn container.)
Service mesh-arkitektur har flere viktige implikasjoner. For det første, siden oppgaven til en proxy er å avlytte samtaler mellom tjenester, gir et tjenestenett bare mening hvis applikasjonen din ble opprettet for et bestemt sett med tjenester. Mesh man kan bruk med monolitter, men dette er klart overflødig av hensyn til én enkelt proxy, og funksjonaliteten er neppe etterspurt.
En annen viktig konsekvens er at tjenestenettverket krever enorm antall fullmakter. Faktisk knytter Linkerd en linkerd-proxy til hver forekomst av hver tjeneste (andre implementeringer legger til en proxy til hver node/vert/virtuell maskin. Det er mye uansett). Slik aktiv bruk av fullmakter har i seg selv en rekke tilleggskomplikasjoner:
- Proxyer i dataplanet må være fort, siden det for hvert anrop er et par anrop til proxyen: en på klientsiden, en på serversiden.
- Også fullmektiger bør være liten и lett. Hver vil forbruke minne- og CPU-ressurser, og dette forbruket vil vokse lineært med applikasjonen.
- Du trenger en mekanisme for å distribuere og oppdatere et stort antall proxyer. Å gjøre det manuelt er ikke et alternativ.
Generelt ser et tjenestenettverk slik ut (i det minste fra et fugleperspektiv): du distribuerer en haug med proxy-tjenere for brukerrom som "gjør noe" med intern trafikk mellom tjenestene, og bruker et kontrollplan for å overvåke og administrere dem.
Nå er det på tide å stille spørsmålet "Hvorfor?"
Hva er et servicenett til?
De som først møtte ideen om et servicenettverk, kunne bli tilgitt for å føle seg litt nervøse. Service mesh-designet betyr at det ikke bare vil øke latensen i applikasjonen, men også forbruke ressurser og vil legge til en haug med nye mekanismer i infrastrukturen. Først setter du opp et servicenettverk, og så finner du plutselig at du trenger å betjene hundrevis (om ikke tusenvis) av proxyer. Spørsmålet er hvem som vil gjøre dette frivillig?
Svaret på dette spørsmålet har to deler. For det første kan transaksjonskostnadene forbundet med å distribuere disse proxyene reduseres betydelig takket være noen endringer som skjer i økosystemet (mer om dette senere).
For det andre er en enhet som dette faktisk en fin måte å introdusere ekstra logikk i systemet på. Ikke bare fordi et servicenettverk kan legge til mye ny funksjonalitet, men også fordi det kan gjøres uten å forstyrre økosystemet. Faktisk er hele service mesh-modellen basert på dette premisset: i et multiservice-system, uansett hva gjøre individuelle tjenester, trafikk mellom dem er det ideelle punktet for å legge til funksjonalitet.
For eksempel, i Linkerd (som i de fleste meshes) er funksjonaliteten først og fremst fokusert på HTTP-anrop, inkludert HTTP/2 og gRPC*. Funksjonaliteten er ganske rik - den kan deles inn i tre klasser:
- Funksjoner knyttet til pålitelighet. Gjentatte forespørsler, tidsavbrudd, kanari-tilnærming (trafikkdeling/omdirigering), etc.
- Funksjoner knyttet til overvåkning. Aggregering av suksessrater, forsinkelser og forespørselsvolumer for hver tjeneste eller individuelle veibeskrivelser; konstruksjon av topologiske kart over tjenester mv.
- Funksjoner knyttet til sikkerhet. Gjensidig TLS, adgangskontroll m.m.
* Fra Linkerds synspunkt er gRPC praktisk talt ikke forskjellig fra HTTP/2: den bruker bare protobuf i nyttelasten. Fra en utviklers synspunkt er de to tingene selvfølgelig forskjellige.
Mange av disse mekanismene fungerer på forespørselsnivå (derav "L7 proxy"). For eksempel, hvis Foo-tjenesten foretar et HTTP-kall til Bar-tjenesten, kan linkerd-proxyen på Foo-siden utføre intelligent lastbalansering og rute anrop fra Foo til Bar-forekomster basert på den observerte ventetiden; den kan gjenta forespørselen om nødvendig (og hvis den er idempotent); den kan registrere svarkoden og timeout, etc. På samme måte kan linkerd-proxy på Bar-siden avvise en forespørsel hvis den ikke er tillatt eller forespørselsgrensen overskrides; kan registrere en forsinkelse fra sin side, etc.
Fullmakter kan "gjøre noe" på tilkoblingsnivå også. For eksempel kan linkerd-proxy på Foo-siden starte en TLS-tilkobling, og linkerd-proxy på Bar-siden kan avslutte den, og begge sider kan verifisere hverandres TLS-sertifikater*. Dette gir ikke bare kryptering mellom tjenester, men også en kryptografisk sikker måte å identifisere tjenester på: Foo og Bar kan «bevise» at de er den de sier de er.
* "Mutual of a friend" betyr at klientsertifikatet også er verifisert (gjensidig TLS). I "klassisk" TLS, for eksempel mellom en nettleser og en server, verifiseres vanligvis sertifikatet til kun én side (serveren).
Enten de opererer på forespørsels- eller tilkoblingsnivå, er det viktig å understreke at alle service mesh-funksjoner er det operativt karakter. Linkerd er ikke i stand til å transformere semantikken til nyttelasten - for eksempel å legge til felt i et JSON-fragment eller gjøre endringer i protobuf. Vi skal snakke om denne viktige funksjonen senere når vi snakker om ESB og mellomvare.
Dette er settet med funksjoner som et tjenestenett tilbyr. Spørsmålet oppstår: hvorfor ikke implementere dem direkte i applikasjonen? Og hvorfor bry seg med en proxy i det hele tatt?
Hvorfor service mesh er en god idé
Selv om egenskapene til et servicenettverk er spennende, ligger ikke kjerneverdien i funksjonene. Til slutt vi Kan implementere dem direkte i applikasjonen (vi vil se senere at dette var opphavet til tjenestenettverket). For å prøve å oppsummere det i én setning, er verdien av et servicenettverk: den gir funksjoner som er avgjørende for å kjøre moderne serverprogramvare på en konsistent måte over hele stabelen og uavhengig av applikasjonskode.
La oss analysere dette forslaget.
«Funksjoner som er avgjørende for å kjøre moderne serverprogramvare" Hvis du oppretter en transaksjonsserverapplikasjon som er koblet til det offentlige Internett, aksepterer forespørsler fra omverdenen og svarer på dem innen kort tid - for eksempel en nettapplikasjon, en API-server og de aller fleste andre moderne applikasjoner - og hvis du implementerer det som et sett med tjenester som synkront samhandler med hverandre, og hvis du hele tiden oppgraderer denne programvaren, legger til nye funksjoner, og hvis du blir tvunget til å holde dette systemet i orden under endringsprosessen - i denne case, gratulerer, du lager moderne serverprogramvare. Og alle disse flotte funksjonene oppført ovenfor viser seg faktisk å være kritiske for deg. Applikasjonen må være pålitelig, sikker, og du må kunne observere hva den gjør. Det er akkurat disse spørsmålene som service mesh hjelper til med å løse.
(OK, forrige avsnitt inkluderer fortsatt min tro på at denne tilnærmingen er den moderne måten å lage serverprogramvare på. Andre foretrekker å utvikle monolitter, "reaktive mikrotjenester" og andre ting som ikke faller inn under definisjonen gitt ovenfor. Disse menneskene har sannsynligvis sine mening er forskjellig fra min. På sin side tror jeg at de er "feil" - selv om tjenestenettverket i alle fall ikke er veldig nyttig for dem).
«Uniform for hele stabelen" Funksjonaliteten som tilbys av et servicenettverk er ikke bare oppdragskritisk. De gjelder for alle tjenester i applikasjonen, uavhengig av hvilket språk de er skrevet i, hvilket rammeverk de brukes, hvem som skrev dem, hvordan de ble distribuert, og eventuelle andre finesser i utviklingen og bruken av dem.
«Uavhengig av applikasjonskode" Til slutt gir et servicenettverk ikke bare konsistent funksjonalitet over hele stabelen, det gjør det på en måte som ikke krever at applikasjonen må redigeres. Det grunnleggende grunnlaget for service mesh-funksjonalitet, inkludert oppgaver for konfigurasjon, oppdatering, drift, vedlikehold, etc., ligger utelukkende på plattformnivå og er uavhengig av applikasjonen. Applikasjonen kan endres uten å påvirke tjenestenettverket. I sin tur kan tjenestenettverket endres uten deltakelse fra applikasjonen.
Kort sagt, et servicenett gir ikke bare viktig funksjonalitet, men gjør det også på en global, enhetlig og applikasjonsuavhengig måte. Og så, selv om tjenestemesh-funksjonalitet kan implementeres i tjenestekode (for eksempel som et bibliotek inkludert i hver tjeneste), vil ikke denne tilnærmingen gi enhetligheten og uavhengigheten som er så verdifull i tilfellet med et tjenestenettverk.
Og alt du trenger å gjøre er å legge til en haug med proxyer! Jeg lover at vi snart skal se på driftskostnadene forbundet med å legge til disse proxyene. Men la oss først stoppe og se på denne ideen om uavhengighet fra forskjellige perspektiver. mennesker.
Hvem hjelper service mesh?
Hvor upraktisk det enn kan være, for at en teknologi skal bli en viktig del av økosystemet, må den aksepteres av folk. Så hvem er interessert i service mesh? Hvem drar nytte av bruken?
Hvis du utvikler moderne serverprogramvare, kan du grovt sett tenke på teamet ditt som en gruppe tjenesteeiere, som sammen utvikler og implementerer forretningslogikk, og plattformeiere, utvikle den interne plattformen som disse tjenestene opererer på. I små organisasjoner kan dette være de samme personene, men etter hvert som selskapet vokser, har disse rollene en tendens til å bli mer uttalte og til og med delt inn i underroller... (Det er mye å si her om devopsens skiftende natur, den organisatoriske virkningen av mikrotjenester osv.) n. Men la oss nå ta disse beskrivelsene som gitt).
Fra dette synspunktet er de klare mottakerne av tjenestenettverket plattformeierne. Tross alt, til syvende og sist er målet til plattformteamet å skape en intern plattform der tjenesteeiere kan implementere forretningslogikk og gjøre det på en måte som sikrer at de er så uavhengige som mulig fra de skumle detaljene i driften. Ikke bare tilbyr et tjenestenettverk funksjoner som er avgjørende for å oppnå dette målet, det gjør det på en måte som igjen ikke pålegger tjenesteeiere avhengigheter.
Tjenesteeiere kommer også til gode, men på en mer indirekte måte. Målet til tjenesteeieren er å være så produktiv som mulig med å implementere logikken i forretningsprosessen, og jo mindre han trenger å bekymre seg for operasjonelle problemer, jo bedre. I stedet for å måtte forholde seg til å implementere, for eksempel, prøve retningslinjer på nytt eller TLS, kan de fokusere utelukkende på forretningsmål og håpe at plattformen tar seg av resten. Dette er en stor fordel for dem.
Den organisatoriske verdien av en slik deling mellom eierne av plattformer og tjenester kan ikke overvurderes. Jeg tror hun bidrar hoved~~POS=TRUNC bidrag til verdien av tjenestenettet.
Vi lærte denne leksjonen da en tidlig Linkerd-fan fortalte oss hvorfor de valgte service mesh: fordi det tillot dem å "holde den snakkende butikken til et minimum." Her er noen detaljer: gutta fra ett stort selskap migrerte plattformen sin til Kubernetes. Siden applikasjonen håndterte sensitiv informasjon, ønsket de å kryptere all kommunikasjon på tvers av klyngene. Situasjonen ble imidlertid komplisert av tilstedeværelsen av hundrevis av tjenester og hundrevis av utviklingsteam. Utsiktene til å kontakte alle og overbevise dem om å inkludere TLS-støtte i planene deres gjorde dem ikke glade i det hele tatt. Etter å ha installert Linkerd, overførte de ansvar fra utviklere (fra det synspunktet dette var unødvendig trøbbel) til plattformspillere, for hvem dette var en toppprioritet. Linkerd løste med andre ord ikke så mye et teknisk problem for dem som et organisatorisk.
Kort sagt, et servicenett er mer en løsning, ikke en teknisk, men sosioteknisk Problemer. (Takk skal du ha for å introdusere dette begrepet.)
Vil et servicenett løse alle problemene mine?
Ja. Jeg mener, nei!
Hvis du ser på de tre funksjonsklassene som er skissert ovenfor – pålitelighet, sikkerhet og observerbarhet – blir det klart at et servicenettverk ikke er en komplett løsning på noen av disse problemene. Mens Linkerd kan utstede forespørsler på nytt (hvis den vet at de er idempotente), er den ikke i stand til å ta avgjørelser om hva som skal returneres til brukeren hvis tjenesten har sviktet permanent - disse avgjørelsene må tas av applikasjonen. Linkerd kan føre statistikk over vellykkede forespørsler, men den er ikke i stand til å se på tjenesten og gi dens interne beregninger - applikasjonen må ha slike verktøy. Og selv om Linkerd er i stand til å organisere mTLS, krever fullverdige sikkerhetsløsninger mye mer.
En undergruppe av funksjonene i disse områdene som tilbys av tjenestenettverket, er relatert til plattformfunksjoner. Med dette mener jeg funksjoner som:
- Uavhengig av forretningslogikk. Måten anropshistogrammer mellom Foo og Bar er konstruert på er helt uavhengig av Hvorfor Foo ringer Bar.
- Vanskelig å implementere riktig. I Linkerd er gjenforsøk parametrisert med alle slags fancy ting som gjenforsøksbudsjetter (prøv budsjetter på nytt), siden en usofistikert, direkte tilnærming til å implementere slike ting helt sikkert vil føre til fremveksten av et såkalt «skred av forespørsler» (forsøk storm på nytt) og andre problemer som er karakteristiske for distribuerte systemer.
- Mest effektiv når den påføres jevnt. TLS-mekanismen gir bare mening hvis den brukes overalt.
Siden disse funksjonene er implementert på proxy-nivå (og ikke på applikasjonsnivå), gir tjenestenettverket dem på plattform, ikke applikasjoner. Dermed spiller det ingen rolle hvilket språk tjenestene er skrevet på, hvilke rammer de bruker, hvem som har skrevet dem og hvorfor. Proxyer opererer utenfor alle disse detaljene, og det grunnleggende grunnlaget for denne funksjonaliteten, inkludert oppgaver for konfigurasjon, oppdatering, drift, vedlikehold, etc., ligger utelukkende på plattformnivå.
Eksempler på service mesh-funksjoner
For å oppsummere er ikke et servicenettverk en komplett løsning for pålitelighet, observerbarhet eller sikkerhet. Omfanget av disse områdene krever deltakelse fra tjenesteeiere, Ops/SRE-team og andre selskapsenheter. Tjenestenettverket gir bare en "slice" på plattformnivå for hvert av disse områdene.
Hvorfor har service mesh blitt populært akkurat nå?
Nå lurer du sikkert på: ok, hvis tjenestenettverket er så bra, hvorfor begynte vi ikke å distribuere millioner av proxyer i stabelen for ti år siden?
Det er et banalt svar på dette spørsmålet: for ti år siden bygde alle monolitter, og ingen trengte et servicenett. Dette er sant, men etter min mening går dette svaret glipp av poenget. Selv for ti år siden ble konseptet med mikrotjenester som en lovende måte å bygge store systemer på mye diskutert og brukt i selskaper som Twitter, Facebook, Google og Netflix. Den generelle oppfatningen – i hvert fall i de delene av bransjen jeg kom i kontakt med – var at mikrotjenester var den «riktige måten» å bygge store systemer på, selv om det var jævla vanskelig.
Selv om det for ti år siden var selskaper som drev mikrotjenester, satte de selvfølgelig ikke fullmakter overalt de kunne for å danne et servicenettverk. Men hvis du ser nøye etter, gjorde de noe lignende: mange av disse selskapene krevde bruk av et spesielt internt bibliotek for nettverkskommunikasjon (noen ganger kalt et tykt klientbibliotek, fett klientbibliotek).
Netflix hadde Hysterix, Google hadde Stubby, Twitter hadde Finagle-biblioteket. Finagle, for eksempel, var obligatorisk for hver nye tjeneste på Twitter. Den håndterte både klient- og serversiden av tilkoblinger, tillot gjentatte forespørsler, støttet forespørselsruting, lastbalansering og måling. Det ga et konsistent lag av pålitelighet og observerbarhet over hele Twitter-stakken, uavhengig av hva tjenesten gjorde. Det fungerte selvfølgelig bare for JVM-språk og var basert på en programmeringsmodell som måtte brukes for hele applikasjonen. Imidlertid var funksjonaliteten nesten den samme som tjenestenettverket. (Faktisk var den første versjonen av Linkerd ganske enkelt Finagle pakket inn i proxy-form.)
For ti år siden var det altså ikke bare mikrotjenester, men også spesielle proto-service-mesh-biblioteker som løste de samme problemene som service mesh løser i dag. Selve tjenestenettverket eksisterte imidlertid ikke da. Det måtte ett skift til før hun dukket opp.
Og det er her det dypere svaret ligger, skjult i en annen endring som har skjedd de siste 10 årene: kostnadene ved å distribuere mikrotjenester har falt dramatisk. Selskapene nevnt ovenfor som brukte mikrotjenester for ti år siden – Twitter, Netflix, Facebook, Google – var selskaper av enorm skala og enorme ressurser. De hadde ikke bare behovet, men også muligheten til å bygge, distribuere og drifte store mikrotjenester-baserte applikasjoner. Energien og innsatsen som Twitter-ingeniører legger ned i å gå fra en monolittisk til en mikroservicetilnærming er fantastisk. (For å være rettferdig, så er det faktum at det lyktes.) Slike infrastrukturelle manøvrer var da umulige for mindre selskaper.
Spol frem til nåtiden. Det er oppstart i dag hvor forholdet mellom mikrotjenester og utviklere er 5:1 (eller til og med ), og dessuten takler de dem med hell! Hvis en 5-personers oppstart enkelt kan drive 50 mikrotjenester, så har noe klart redusert kostnadene ved implementeringen.
1500 mikrotjenester i Monzo; hver linje er en foreskrevet nettverksregel som tillater trafikk
Den dramatiske reduksjonen i kostnadene ved drift av mikrotjenester er resultatet av én prosess: økende popularitet for containere и orkestratorer. Dette er nettopp det dype svaret på spørsmålet om hva som bidro til fremveksten av tjenestenettet. Den samme teknologien gjorde både tjenestenettverk og mikrotjenester attraktive: Kubernetes og Docker.
Hvorfor? Vel, Docker løser ett stort problem - emballasjeproblemet. Ved å pakke en applikasjon og dens (ikke-nettverk) kjøretidsavhengigheter inn i en container, gjør Docker applikasjonen til en utskiftbar enhet som kan hostes og kjøres hvor som helst. Samtidig forenkler det driften betraktelig flerspråklig Stabel: Fordi en beholder er en atomisk enhet for utførelse, for distribusjon og operasjonelle formål, spiller det ingen rolle hva som er inni, enten det er en JVM-, Node-, Go-, Python- eller Ruby-applikasjon. Du bare starter den og det er det.
Kubernetes tar alt til neste nivå. Nå som det er tonnevis av "ting å kjøre" og tonnevis av maskiner å kjøre dem på, er det behov for et verktøy som kan korrelere dem med hverandre. I vid forstand gir du Kubernetes mange containere og mange maskiner, og det kartlegger dem opp mot hverandre (selvfølgelig er dette en dynamisk og stadig skiftende prosess: nye containere beveger seg rundt i systemet, maskiner starter og stopper , osv. Kubernetes tar imidlertid hensyn til alt dette ).
Når Kubernetes er konfigurert, er tidskostnaden for å distribuere og drifte én tjeneste litt forskjellig fra kostnaden for å distribuere og drifte ti tjenester (faktisk er det nesten det samme for 100 tjenester). Legg til dette beholdere som en pakkemekanisme som oppmuntrer til flerspråklig implementering, og du har en rekke nye applikasjoner implementert i form av mikrotjenester skrevet på forskjellige språk – akkurat den typen miljø som et tjenestenett er så godt egnet for.
Så vi kommer til svaret på spørsmålet om hvorfor ideen om et servicenettverk har blitt populært nå: homogeniteten som Kubernetes tilbyr tjenester gjelder direkte for de operasjonelle utfordringene et servicenettverk står overfor. Du pakker proxyene inn i containere, gir Kubernetes oppgaven med å feste dem hvor det kan, og vips! Som et resultat får du et servicenettverk, mens all mekanikk for utplasseringen administreres av Kubernetes. (I hvert fall fra et fugleperspektiv. Selvfølgelig er det mange nyanser i denne prosessen.)
For å oppsummere: grunnen til at tjenestenett har blitt populært nå, og for ikke ti år siden, er at Kubernetes og Docker ikke bare har økt betydelig trenge i den, etter å ha forenklet implementeringen av applikasjoner som sett med flerspråklige mikrotjenester, men også betydelig redusert kostnader for driften, og gir mekanismer for å distribuere og støtte sidevogns proxy-flåter.
Hvorfor er det så mye snakk om service mesh?
Advarsel: I denne delen bruker jeg alle slags antakelser, formodninger, oppspinn og innsideinformasjon.
Gjør et søk etter "service mesh" og du vil komme over massevis av resirkulert lavkaloriinnhold, rare prosjekter og et kaleidoskop av forvrengning som er verdig et ekkokammer. Enhver fancy ny teknologi gjør dette, men i tilfelle av et servicenettverk er problemet spesielt akutt. Hvorfor?
Vel, en del av det er min feil. Jeg har jobbet hardt for å promotere Linkerd og tjenestenettverket hver sjanse jeg får gjennom utallige blogginnlegg og artikler som denne. Men jeg er ikke så sterk. For å virkelig svare på dette spørsmålet, må vi snakke litt om den generelle situasjonen. Og det er umulig å snakke om det uten å nevne ett prosjekt: er et åpen kildekode-tjenestenett utviklet i fellesskap av Google, IBM og Lyft.
(De tre selskapene har svært forskjellige roller: Lyfts engasjement ser ut til å være kun i navn; de er forfattere av Envoy, men bruker eller deltar ikke i Istios utvikling. IBM er involvert i og bruker Istios utvikling. Google er aktivt involvert i Istios utvikling. utvikling , men bruker det faktisk ikke så vidt jeg kan fortelle.)
Istio-prosjektet er kjent for to ting. For det første er det den enorme markedsføringsinnsatsen som Google, spesielt, legger ned for å markedsføre det. Jeg vil anslå at de fleste som kjenner til service mesh-konseptet i dag først lærte om det gjennom Istio. Den andre tingen er hvor dårlig mottatt Istio ble. I denne saken er jeg åpenbart en interessert part, men å prøve å forbli så objektiv som mulig kan jeg fortsatt ikke hjelpe , ikke veldig særegen (men ikke unik: systemd kommer til tankene, ...) for et åpen kildekode-prosjekt.
(I praksis ser det ut til at Istio har problemer ikke bare med kompleksitet og brukeropplevelse, men også med ytelse. F.eks. I en tredjepartsstudie fant forskere situasjoner der Istios halelatens var 100 ganger høyere enn Linkerds, samt ressurssultne situasjoner der Linkerd fortsatte å fungere vellykket mens Istio sluttet å virke helt.)
Ser vi bort fra mine teorier om hvorfor dette skjedde, tror jeg at den overveldende spenningen rundt tjenestenettverket er forklart av Googles deltakelse. Nemlig en kombinasjon av følgende tre faktorer:
- Googles påtrengende promotering av Istio;
- en tilsvarende misbilligende, kritisk holdning til prosjektet;
- den siste meteoriske økningen i popularitet til Kubernetes, hvor minnene fortsatt er ferske.
Sammen skaper disse faktorene et fordummende, oksygenfritt miljø der evnen til rasjonell dømmekraft er svekket, og bare den rare variasjonen gjenstår. .
Fra Linkerds perspektiv er dette ... det jeg vil beskrive som en blandet velsignelse. Jeg mener, det er flott at service mesh har kommet inn i mainstream på en måte som det ikke gjorde i 2016 da Linkerd først startet, og det var veldig vanskelig å få folk til å ta hensyn til prosjektet. Nå er det ikke noe slikt problem! Men den dårlige nyheten er at servicenett-landskapet er så forvirrende i dag at det er nesten umulig å forstå hvilke prosjekter som faktisk hører hjemme i kategorien servicenettverk (for ikke å snakke om å forstå hvilket som er best egnet for en bestemt brukstilfelle). Dette er definitivt en dealbreaker for alle (og det er definitivt noen tilfeller der Istio eller et annet prosjekt er bedre egnet enn Linkerd, siden sistnevnte fortsatt ikke er en universell løsning).
På Linkerds side har vår strategi vært å ignorere støyen, fortsette å fokusere på å løse reelle fellesskapsproblemer, og egentlig vente til hypen forsvinner. Til syvende og sist vil hypen avta og vi kan fortsette å jobbe rolig.
I mellomtiden må vi alle smøre oss med litt tålmodighet.
Vil et servicenettverk være nyttig for meg, en ydmyk programvareingeniør?
Følgende spørreskjema vil hjelpe deg med å svare på dette spørsmålet:
Er du utelukkende involvert i implementering av forretningslogikk? I dette tilfellet vil ikke tjenestenettverket være nyttig for deg. Det vil si, selvfølgelig kan du være interessert i det, men ideelt sett bør ikke tjenestenettverket direkte påvirke noe i miljøet ditt. Fortsett å jobbe med det du får betalt for å gjøre.
Støtter du plattformen hos et selskap som bruker Kubernetes? Ja, i dette tilfellet trenger du et servicenettverk (med mindre du selvfølgelig bruker K8s bare for å kjøre en monolitt eller batchbehandling - men da vil jeg spørre hvorfor du trenger K8s). Du vil sannsynligvis ende opp med mange mikrotjenester skrevet av forskjellige mennesker. De samhandler alle med hverandre og er knyttet til et virvar av kjøretidsavhengigheter, og du må finne en måte å håndtere alt på. Ved å bruke Kubernetes kan du velge et tjenestenettverk "for deg selv." For å gjøre dette, gjør deg kjent med deres evner og funksjoner og svar på spørsmålet om noen av de tilgjengelige prosjektene passer for deg (jeg anbefaler å starte forskningen med Linkerd).
Er du et plattformselskap i et selskap som IKKE bruker Kubernetes, men som bruker mikrotjenester? I dette tilfellet vil et tjenestenett være nyttig for deg, men bruken vil være ikke-triviell. Selvfølgelig kan du imitere work service mesh ved å plassere en haug med proxyer, men en viktig fordel med Kubernetes er distribusjonsmodellen: manuelt vedlikehold av disse proxyene vil kreve mye mer tid, krefter og kostnader.
Har du ansvar for plattformen i et selskap som jobber med monolitter? I dette tilfellet trenger du sannsynligvis ikke et servicenettverk. Hvis du jobber med monolitter (eller til og med samlinger av monolitter) som har veldefinerte og sjeldent skiftende interaksjonsmønstre, vil et servicenettverk ha lite å tilby deg. Så du kan bare ignorere det og håpe at det forsvinner som en vond drøm...
Konklusjon
Sannsynligvis bør servicenettverk fortsatt ikke kalles "den mest hypede teknologien i verden" - denne tvilsomme æren tilhører sannsynligvis Bitcoin eller AI. Hun er sannsynligvis blant de fem beste. Men hvis du skjærer gjennom lagene med støy, blir det klart at tjenestenettverket gir reelle fordeler for de som bygger applikasjoner på Kubernetes.
Jeg vil at du skal prøve Linkerd - installere den på en Kubernetes-klynge (eller til og med Minikube på en bærbar datamaskin) , og du kan selv se hva jeg snakker om.
FAQ
— Hvis jeg ignorerer tjenestenettverket, vil det forsvinne?
— Jeg må skuffe deg: Service mesh er med oss lenge.
– Men jeg VIL IKKE bruke servicenetting!
– Vel, det er ikke nødvendig! Bare les spørreskjemaet ovenfor for å forstå om du i det minste bør gjøre deg kjent med det grunnleggende.
— Er ikke dette gode gamle ESB/mellomvare med ny saus?
— Tjenestenettverk omhandler operasjonell logikk, ikke semantisk. bedriftstjenestebuss (). Ved å opprettholde denne separasjonen hjelper tjenestenettverket å unngå samme skjebne.
— Hvordan skiller et tjenestenettverk seg fra API-gatewayer?
— Det er en million artikler om dette emnet. Bare Google det.
— Utsending er et tjenestenettverk?
– Nei, Envoy er ikke et servicenettverk, det er en proxy-server. Den kan brukes til å organisere et tjenestenettverk (og mye mer - det er en proxy for generell bruk). Men i seg selv er det ikke et servicenettverk.
— Network Service Mesh er et servicenettverk?
- Nei. Til tross for navnet er ikke dette et servicenettverk (hvordan liker du markedsføringsmirakler?).
— Vil et servicenettverk hjelpe med mitt meldingskøbaserte reaktive asynkrone system?
– Nei, servicenett hjelper deg ikke.
— Hvilket servicenett skal jeg bruke?
- , ingen brainer.
– Artikkelen suger! / Forfatteren er velkommen!
— Del lenken til den med alle vennene dine slik at de kan se den!
Anerkjennelser
Som du kanskje har gjettet ut fra tittelen, var denne artikkelen inspirert av Jay Kreps' fantastiske avhandling "" Jeg møtte Jay for ti år siden da jeg intervjuet på Linked In, og han har vært en inspirasjon for meg siden.
Selv om jeg liker å kalle meg en "Linkerd-utvikler", er realiteten at jeg er mer en vedlikeholder av README.md-filen på et prosjekt. Det jobbes med Linkerd i dag , , mennesker, og dette prosjektet ville ikke ha skjedd uten deltakelsen fra et fantastisk fellesskap av bidragsytere og brukere.
Og til slutt, en spesiell takk til skaperen av Linkerd, (primus inter pares), som sammen med meg for mange år siden dykket hodestups ned i alt dette oppstyret med servicenetting.
PS fra oversetter
Les også på bloggen vår:
- «";
- «";
- «";
- «";
- «'.
Kilde: www.habr.com