Notera. transl.: Servicenät är ett fenomen som ännu inte har en stabil översättning till ryska (för mer än 2 år sedan föreslog vi alternativet "nät för tjänster", och lite senare började några kollegor aktivt främja kombinationen "servicesil"). Ständigt samtal om denna teknik har lett till en situation där marknadsföring och tekniska komponenter är för tätt sammanflätade. Detta underbara material från en av författarna till den ursprungliga termen är avsett att ge klarhet för ingenjörer och andra.
Serie från
Inledning
Om du är en mjukvaruingenjör som arbetar någonstans i backend-systemsutrymmet, har termen "servicenätverk" antagligen redan blivit fast inarbetad i ditt sinne under de senaste åren. Tack vare ett konstigt sammanträffande tar den här frasen över branschen mer och mer, och hypen och kampanjerbjudanden som är förknippade med den växer som en snöboll som flyger nedför och visar inga tecken på att sakta ner.
Servicenät föddes i det grumliga, partiska vattnet i det molninfödda ekosystemet. Tyvärr betyder detta att mycket av kontroversen kring det sträcker sig från "lågkaloriprat" till - för att använda en teknisk term - rent nonsens. Men om du skär igenom allt brus kommer du att upptäcka att servicenätet har en mycket verklig, definierad och viktig funktion.
I det här inlägget ska jag försöka göra just det: tillhandahålla en ärlig, djupgående, ingenjörsfokuserad guide till servicenät. Jag tänker inte bara svara på frågan: "Vad det är?", - men också "För vad?"Och "Varför nu?". Slutligen ska jag försöka beskriva varför (enligt min mening) just den här tekniken har orsakat en sådan galen uppståndelse, vilket är en intressant historia i sig.
Vem är jag?
Hej alla! Mitt namn är . Jag är en av skaparna — det allra första servicenätprojektet och projektet som är skyldig till termens utseende servicenät som sådan (förlåt killar!). (Notera övers.: Förresten, vid gryningen av denna terms utseende, för mer än 2,5 år sedan, översatte vi redan det tidiga materialet från samma författare med titeln ". ") Jag leder också är en startup som skapar coola servicemesh-saker som Linkerd och .
Du kan nog gissa att jag har en väldigt partisk och subjektiv åsikt i denna fråga. Jag kommer dock att försöka hålla partiskhet till ett minimum (med undantag för ett avsnitt: "Varför pratas det så mycket om servicenät?", - där jag fortfarande kommer att dela mina förutfattade meningar). Jag kommer också att göra mitt bästa för att göra den här guiden så objektiv som möjligt. För specifika exempel kommer jag i första hand att förlita mig på Linkerds erfarenhet, samtidigt som jag pekar på skillnader (om några) som jag känner till i implementeringen av andra typer av servicenät.
Okej, dags att gå vidare till godsakerna.
Vad är ett servicenät?
Trots all hype är strukturen på servicenätet ganska enkel. Det här är bara ett gäng användarutrymmesproxies som finns "bredvid" tjänsterna (vi pratar lite om vad "nästa" är senare), plus en uppsättning kontrollprocesser. Fullmakterna kallas kollektivt dataplan, och kontrollprocesserna kallas kontrollplan. Dataplanet avlyssnar samtal mellan tjänster och gör "alla möjliga olika saker" med dem; Kontrollplanet koordinerar följaktligen proxyns beteende och ger åtkomst för dig, dvs. operatör, till API, vilket gör att nätverket kan manipuleras och mätas som en helhet.
Vad är detta för sorts proxy? Detta är en lager 7-medveten TCP-proxy (dvs. "ta hänsyn till" lager 7 i OSI-modellen) som HAProxy och NGINX. Du kan välja en proxy efter eget tycke; Linkerd använder en Rust-proxy, enkelt namngiven . Vi sätter ihop det specifikt för servicenät. Andra maskor föredrar andra fullmakter (Envoy är ett vanligt val). Men att välja en proxy är bara en fråga om implementering.
Vad gör dessa proxyservrar? Uppenbarligen proxy-samtal till och från tjänster (strängt taget fungerar de som proxyservrar och omvända fullmakter, och hanterar både inkommande och utgående samtal). Och de implementerar en funktionsuppsättning som fokuserar på samtal между tjänster. Detta fokus på trafik mellan tjänster är det som skiljer en servicemesh-proxy från till exempel API-gateways eller ingressproxyer (de senare fokuserar på samtal som kommer in i klustret från omvärlden). (Notera. transl.: För en jämförelse av befintliga Ingress-kontroller för Kubernetes, av vilka många använder den redan nämnda Envoy, se .)
Så vi har sorterat ut dataplanet. Kontrollplanet är enklare: det är en uppsättning komponenter som tillhandahåller all mekanik som dataplanet behöver för att fungera på ett koordinerat sätt, inklusive tjänsteupptäckt, utfärdande av TLS-certifikat, metrisk aggregering, etc. Dataplanet informerar kontrollplanet om dess beteende; i sin tur tillhandahåller kontrollplanet ett API som låter dig ändra och övervaka beteendet för dataplanet som helhet.
Nedan är ett diagram över styrplanet och dataplanet i Linkerd. Som du kan se innehåller kontrollplanet flera olika komponenter, inklusive en Prometheus-instans som samlar in mätvärden från proxyservrar, samt andra komponenter som t.ex. destination (tjänstupptäckt), identity (certifikatutfärdare, CA) och public-api (slutpunkter för webb och CLI). Däremot är dataplanet en enkel länkad proxy bredvid applikationsinstansen. Detta är bara ett logiskt diagram; I en verklig implementering kan du ha tre repliker av varje kontrollplanskomponent och hundratals eller tusentals proxyservrar i dataplanet.
(De blå rektanglarna i det här diagrammet symboliserar gränserna för Kubernetes-poddar. Du kan se att behållarna med linkerd-proxy är i samma pod som applikationsbehållarna. Detta schema är känt som sidvagnscontainer.)
Service mesh-arkitektur har flera viktiga implikationer. För det första, eftersom uppgiften för en proxy är att avlyssna samtal mellan tjänster, är ett servicenät bara meningsfullt om din applikation skapades för en viss uppsättning tjänster. Maska kan man använd med monoliter, men detta är helt klart överflödigt för en enda proxys skull, och dess funktionalitet är sannolikt inte efterfrågad.
En annan viktig konsekvens är att servicenätet kräver enorm antal fullmakter. Faktum är att Linkerd kopplar en linkerd-proxy till varje instans av varje tjänst (andra implementeringar lägger till en proxy till varje nod/värd/virtuell maskin. Det är mycket i alla fall). Sådan aktiv användning av fullmakter medför i sig ett antal ytterligare komplikationer:
- Proxyer i dataplanet måste vara snabb, eftersom det för varje samtal finns ett par anrop till proxyn: ett på klientsidan, ett på serversidan.
- Det bör också vara fullmakter små и lättvikt. Var och en kommer att förbruka minnes- och CPU-resurser, och denna förbrukning kommer att växa linjärt med applikationen.
- Du behöver en mekanism för att distribuera och uppdatera ett stort antal proxyservrar. Att göra det manuellt är inte ett alternativ.
I allmänhet ser ett servicenät ut så här (åtminstone ur fågelperspektiv): du distribuerar ett gäng proxyservrar för användarutrymme som "gör något" med intern trafik mellan tjänsten och använder ett kontrollplan för att övervaka och hantera dem.
Nu är det dags att ställa frågan "Varför?"
Vad är ett servicenät till för?
De som först stötte på idén om ett servicenät kunde förlåtas för att de kände sig lite oroliga. Service mesh-designen innebär att den inte bara kommer att öka latensen i applikationen utan också konsumera resurser och kommer att lägga till ett gäng nya mekanismer i infrastrukturen. Först sätter du upp ett servicenät och sedan plötsligt behöver du serva hundratals (om inte tusentals) proxyservrar. Frågan är vem som gör detta frivilligt?
Svaret på denna fråga har två delar. För det första kan transaktionskostnaderna i samband med att distribuera dessa proxyservrar reduceras avsevärt tack vare vissa förändringar som sker i ekosystemet (mer om detta senare).
För det andra är en enhet som denna faktiskt ett utmärkt sätt att introducera ytterligare logik i systemet. Inte bara för att ett servicenät kan lägga till mycket ny funktionalitet, utan också för att det kan göras utan att störa ekosystemet. Faktum är att hela servicenätmodellen är baserad på denna premiss: i ett multiservicesystem, oavsett vad göra enskilda tjänster, trafik mellan dem är den idealiska punkten för att lägga till funktionalitet.
Till exempel, i Linkerd (som i de flesta mesh) är funktionaliteten främst fokuserad på HTTP-anrop, inklusive HTTP/2 och gRPC*. Funktionaliteten är ganska rik - den kan delas in i tre klasser:
- Funktioner relaterade till pålitlighet. Upprepade förfrågningar, timeouts, kanariefågelinflygning (trafikuppdelning/omdirigering) etc.
- Funktioner relaterade till övervakning. Aggregering av framgångsfrekvenser, förseningar och begärandevolymer för varje tjänst eller individuell vägbeskrivning; konstruktion av topologiska kartor över tjänster m.m.
- Funktioner relaterade till säkerhet. Ömsesidig TLS, passerkontroll m.m.
* Ur Linkerds synvinkel skiljer sig gRPC praktiskt taget inte från HTTP/2: den använder bara protobuf i nyttolasten. Ur en utvecklares synvinkel är de två sakerna naturligtvis olika.
Många av dessa mekanismer fungerar på begäran nivå (därav "L7 proxy"). Till exempel, om Foo-tjänsten gör ett HTTP-anrop till Bar-tjänsten, kan linkerd-proxyn på Foo-sidan utföra intelligent lastbalansering och dirigera samtal från Foo till Bar-instanser baserat på den observerade latensen; den kan upprepa begäran om det behövs (och om det är idempotent); den kan spela in svarskoden och timeout, etc. På samma sätt kan linkerd-proxy på Bar-sidan avvisa en begäran om den inte är tillåten eller om begäransgränsen överskrids; kan registrera en fördröjning från sin sida osv.
Proxies kan "göra något" på anslutningsnivå också. Till exempel kan linkerd-proxy på Foo-sidan initiera en TLS-anslutning, och linkerd-proxy på Bar-sidan kan avsluta den, och båda sidor kan verifiera varandras TLS-certifikat*. Detta ger inte bara kryptering mellan tjänster, utan också ett kryptografiskt säkert sätt att identifiera tjänster: Foo och Bar kan "bevisa" att de är den de säger att de är.
* "Mutual of a friend" betyder att klientcertifikatet också verifieras (ömsesidig TLS). I "klassisk" TLS, till exempel mellan en webbläsare och en server, verifieras vanligtvis endast en sidas certifikat (servern).
Oavsett om de fungerar på begäran eller anslutningsnivå är det viktigt att betona att alla servicenätfunktioner är det operativ karaktär. Linkerd kan inte transformera nyttolastens semantik - till exempel lägga till fält i ett JSON-fragment eller göra ändringar i protobuf. Vi kommer att prata om denna viktiga funktion senare när vi pratar om ESB och middleware.
Det här är uppsättningen funktioner som ett servicenät erbjuder. Frågan uppstår: varför inte implementera dem direkt i applikationen? Och varför bry sig om en proxy överhuvudtaget?
Varför servicenät är en bra idé
Även om funktionerna hos ett servicenät är spännande, ligger dess kärnvärde faktiskt inte i dess funktioner. Till slut vi Burk implementera dem direkt i applikationen (vi kommer att se senare att detta var ursprunget till tjänsten mesh). För att försöka sammanfatta det i en mening är värdet av ett servicenät: den tillhandahåller funktioner som är avgörande för att köra modern serverprogramvara på ett konsekvent sätt över hela stacken och oberoende av applikationskod.
Låt oss analysera detta förslag.
«Funktioner som är avgörande för att köra modern serverprogramvara" Om du skapar en transaktionsserverapplikation som är ansluten till det offentliga Internet, accepterar förfrågningar från omvärlden och svarar på dem inom kort tid - till exempel en webbapplikation, en API-server och de allra flesta andra moderna applikationer - och om du implementerar det som en uppsättning tjänster som synkront interagerar med varandra, och om du ständigt uppgraderar den här programvaran, lägger till nya funktioner och om du tvingas hålla detta system i fungerande skick under modifieringsprocessen - i detta fall, grattis, du skapar modern servermjukvara. Och alla dessa fantastiska funktioner som anges ovan visar sig faktiskt vara avgörande för dig. Applikationen måste vara pålitlig, säker och du måste kunna observera vad den gör. Det är just dessa frågor som service mesh hjälper till att lösa.
(OK, föregående stycke inkluderar fortfarande min övertygelse att detta tillvägagångssätt är det moderna sättet att skapa servermjukvara. Andra föredrar att utveckla monoliter, "reaktiva mikrotjänster" och andra saker som inte faller under definitionen ovan. Dessa personer har förmodligen sina åsikten skiljer sig från min. I sin tur tycker jag att de är "fel" - även om servicenätet i alla fall inte är särskilt användbart för dem).
«Uniform för hela stapeln" Funktionaliteten som tillhandahålls av ett servicenät är inte bara verksamhetskritisk. De gäller för alla tjänster i applikationen, oavsett vilket språk de är skrivna på, vilket ramverk de använder, vem som skrev dem, hur de distribuerades och eventuella andra subtiliteter i deras utveckling och användning.
«Oberoende av applikationskod" Slutligen ger ett servicenät inte bara konsekvent funktionalitet över hela stacken, det gör det på ett sätt som inte kräver att applikationen redigeras. Den grundläggande basen för service mesh-funktionalitet, inklusive uppgifter för konfiguration, uppdatering, drift, underhåll, etc., ligger helt på plattformsnivå och är oberoende av applikationen. Applikationen kan ändras utan att påverka servicenätet. I sin tur kan tjänsten mesh ändras utan deltagande från applikationen.
Kort sagt, ett servicenät ger inte bara vital funktionalitet, utan gör det också på ett globalt, enhetligt och applikationsoberoende sätt. Och så, även om servicemesh-funktionalitet kan implementeras i servicekod (till exempel som ett bibliotek som ingår i varje tjänst), kommer detta tillvägagångssätt inte att ge den enhetlighet och oberoende som är så värdefull i fallet med ett servicenät.
Och allt du behöver göra är att lägga till ett gäng fullmakter! Jag lovar att vi snart kommer att titta på driftskostnaderna för att lägga till dessa fullmakter. Men låt oss först stanna upp och titta på denna idé om oberoende ur olika perspektiv. människor.
Vem hjälper servicenät?
Hur obekvämt det än kan vara, för att en teknik ska bli en viktig del av ekosystemet måste den accepteras av människor. Så vem är intresserad av servicenät? Vem drar nytta av dess användning?
Om du utvecklar modern servermjukvara kan du ungefär se ditt team som en grupp tjänsteägaresom tillsammans utvecklar och implementerar affärslogik, och plattformsägare, utveckla den interna plattformen på vilken dessa tjänster fungerar. I små organisationer kan det vara samma personer, men i takt med att företaget växer tenderar dessa roller att bli mer uttalade och till och med uppdelade i underroller... (Det finns mycket att säga här om devopsens föränderliga natur, den organisatoriska effekten av mikrotjänster etc.) n. Men låt oss nu ta dessa beskrivningar som givna).
Ur denna synvinkel är de tydliga förmånstagarna av servicenätet plattformsägarna. När allt kommer omkring är målet för plattformsteamet i slutändan att skapa en intern plattform där tjänsteägare kan implementera affärslogik och göra det på ett sätt som säkerställer att de är så oberoende som möjligt från de skumma detaljerna i verksamheten. Ett servicenät erbjuder inte bara funktioner som är avgörande för att uppnå detta mål, det gör det på ett sätt som i sin tur inte påtvingar tjänsteägare beroenden.
Tjänsteägare gynnas också, om än på ett mer indirekt sätt. Målet för tjänsteägaren är att vara så produktiv som möjligt för att implementera logiken i affärsprocessen, och ju mindre han behöver oroa sig för operativa frågor, desto bättre. Istället för att behöva ta itu med att implementera, säg, försök igen policyer eller TLS, kan de fokusera enbart på affärsmål och hoppas att plattformen tar hand om resten. Detta är en stor fördel för dem.
Det organisatoriska värdet av en sådan uppdelning mellan ägare av plattformar och tjänster kan inte överskattas. Jag tror att hon bidrar det viktigaste bidrag till värdet av servicenätet.
Vi lärde oss den här läxan när ett tidigt Linkerd-fan berättade varför de valde servicenät: eftersom det gjorde det möjligt för dem att "hålla den talande butiken till ett minimum." Här är några detaljer: killarna från ett stort företag migrerade sin plattform till Kubernetes. Eftersom applikationen hanterade känslig information ville de kryptera all kommunikation över klustren. Situationen komplicerades dock av närvaron av hundratals tjänster och hundratals utvecklingsteam. Utsikten att kontakta alla och övertyga dem om att inkludera TLS-support i sina planer gjorde dem inte alls glada. Efter att ha installerat Linkerd överförde de ansvar från utvecklare (ur vars synvinkel detta var onödigt problem) till plattformsspelare, för vilka detta var en högsta prioritet. Linkerd löste med andra ord inte så mycket ett tekniskt problem för dem som ett organisatoriskt problem.
Kort sagt, ett servicenät är mer en lösning, inte en teknisk, men sociotekniska Problem. (Tack för att introducera denna term.)
Kommer ett servicenät att lösa alla mina problem?
Ja. Jag menar nej!
Om du tittar på de tre klasserna av funktioner som beskrivs ovan – tillförlitlighet, säkerhet och observerbarhet – blir det tydligt att ett servicenät inte är en komplett lösning på något av dessa problem. Även om Linkerd kan skicka förfrågningar på nytt (om de vet att de är idempotenta), kan den inte fatta beslut om vad som ska returneras till användaren om tjänsten har misslyckats permanent - dessa beslut måste fattas av applikationen. Linkerd kan föra statistik över lyckade förfrågningar, men den kan inte titta på tjänsten och tillhandahålla dess interna mätvärden - applikationen måste ha sådana verktyg. Och även om Linkerd kan organisera mTLS, kräver fullfjädrade säkerhetslösningar mycket mer.
En delmängd av funktionerna i dessa områden som erbjuds av servicenätverket relaterar till plattformsfunktioner. Med detta menar jag funktioner som:
- Oberoende av affärslogik. Sättet på vilket anropshistogram mellan Foo och Bar är konstruerade är helt oberoende av Varför Foo ringer Bar.
- Svårt att implementera korrekt. I Linkerd parametreras omförsök med alla möjliga tjusiga saker som omförsöksbudgetar (försök budgetar igen), eftersom en osofistikerad, direkt strategi för att implementera sådana saker säkerligen kommer att leda till uppkomsten av en så kallad "lavin av förfrågningar" (försök storm igen) och andra problem som är karakteristiska för distribuerade system.
- Mest effektiv när den appliceras enhetligt. TLS-mekanismen är bara vettig om den appliceras överallt.
Eftersom dessa funktioner är implementerade på proxynivå (och inte på applikationsnivå), tillhandahåller servicenätet dem på платформы, inte applikationer. Det spelar alltså ingen roll vilket språk tjänsterna är skrivna på, vilka ramar de använder, vem som skrivit dem och varför. Proxies fungerar utanför alla dessa detaljer, och den grundläggande basen för denna funktionalitet, inklusive uppgifter för konfiguration, uppdatering, drift, underhåll, etc., ligger enbart på plattformsnivå.
Exempel på servicenätfunktioner
Sammanfattningsvis är ett servicenät inte en komplett lösning för tillförlitlighet, observerbarhet eller säkerhet. Omfattningen av dessa områden kräver deltagande av tjänsteägare, Ops/SRE-team och andra företagsenheter. Servicenätverket tillhandahåller endast en "slice" på plattformsnivå för vart och ett av dessa områden.
Varför har servicenät blivit populärt just nu?
Vid det här laget undrar du säkert: ok, om servicenätet är så bra, varför började vi inte distribuera miljontals proxyservrar i stacken för tio år sedan?
Det finns ett banalt svar på denna fråga: för tio år sedan byggde alla monoliter, och ingen behövde ett servicenät. Detta är sant, men enligt min mening missar det här svaret poängen. Redan för tio år sedan diskuterades och tillämpades konceptet med mikrotjänster som ett lovande sätt att bygga storskaliga system flitigt på företag som Twitter, Facebook, Google och Netflix. Den allmänna uppfattningen – åtminstone i de delar av branschen jag kom i kontakt med – var att mikrotjänster var ”rätt sätt” att bygga stora system, även om det var jävligt svårt.
Naturligtvis, även om det för tio år sedan fanns företag som drev mikrotjänster, satte de inte fullmakter överallt där de kunde för att bilda ett servicenät. Men om du tittar noga, gjorde de något liknande: många av dessa företag krävde användningen av ett speciellt internt bibliotek för nätverkskommunikation (kallas ibland ett tjockt klientbibliotek, fett klientbibliotek).
Netflix hade Hysterix, Google hade Stubby, Twitter hade Finagle-biblioteket. Finagle var till exempel obligatoriskt för varje ny tjänst på Twitter. Den hanterade både klient- och serversidan av anslutningar, tillät upprepade förfrågningar, stödde förfrågningsdirigering, lastbalansering och mätning. Det gav ett konsekvent lager av tillförlitlighet och observerbarhet över hela Twitter-stacken, oavsett vad tjänsten gjorde. Naturligtvis fungerade det bara för JVM-språk och baserades på en programmeringsmodell som måste användas för hela applikationen. Men dess funktionalitet var nästan densamma som servicenätets. (Faktum är att den första versionen av Linkerd helt enkelt var Finagle insvept i proxy-form.)
För tio år sedan fanns det alltså inte bara mikrotjänster, utan även speciella proto-service-mesh-bibliotek som löste samma problem som service mesh löser idag. Själva servicenätet fanns dock inte då. Det fick bli ett skift till innan hon dök upp.
Och det är här det djupare svaret ligger, gömt i en annan förändring som har skett under de senaste 10 åren: kostnaden för att distribuera mikrotjänster har sjunkit dramatiskt. De ovan nämnda företagen som använde mikrotjänster för tio år sedan – Twitter, Netflix, Facebook, Google – var företag av enorm omfattning och enorma resurser. De hade inte bara behovet utan också förmågan att bygga, distribuera och driva stora mikrotjänster-baserade applikationer. Energin och ansträngningen som Twitter-ingenjörer lägger ner på att gå från ett monolitiskt till ett mikrotjänster är fantastiskt. (För att vara rättvis, så är det faktum att det lyckades.) Den här typen av infrastrukturella manövrar var då omöjliga för mindre företag.
Spola framåt till nuet. Det finns startups idag där förhållandet mellan mikrotjänster och utvecklare är 5:1 (eller till och med ), och vad mer, de klarar av dem framgångsrikt! Om en startup på 5 personer enkelt kan driva 50 mikrotjänster, så har något helt klart minskat kostnaden för implementeringen av dem.
1500 mikrotjänster i Monzo; varje linje är en föreskriven nätverksregel som tillåter trafik
Den dramatiska minskningen av kostnaderna för att driva mikrotjänster är resultatet av en process: containers växande popularitet и orkestratorer. Detta är just det djupa svaret på frågan om vad som bidrog till uppkomsten av servicenätet. Samma teknik gjorde både servicenät och mikrotjänster attraktiva: Kubernetes och Docker.
Varför? Nåväl, Docker löser ett stort problem - förpackningsproblemet. Genom att paketera en applikation och dess (icke-nätverk) runtime-beroenden i en container, förvandlar Docker applikationen till en utbytbar enhet som kan lagras och köras var som helst. Samtidigt förenklar det driften avsevärt flerspråkig Stack: Eftersom en behållare är en atomär enhet för utförande, för driftsättning och operativa ändamål, spelar det ingen roll vad som finns inuti, vare sig det är en JVM-, Node-, Go-, Python- eller Ruby-applikation. Du bara startar det och det är allt.
Kubernetes tar allt till nästa nivå. Nu när det finns massor av "saker att köra" och massor av maskiner att köra dem på, finns det ett behov av ett verktyg som kan korrelera dem med varandra. I vid bemärkelse ger du Kubernetes många containrar och många maskiner, och det kartlägger dem mot varandra (det här är naturligtvis en dynamisk och ständigt föränderlig process: nya containrar flyttar runt i systemet, maskiner startar och stannar , etc. Kubernetes tar dock hänsyn till allt detta ).
När Kubernetes väl har konfigurerats skiljer sig tidskostnaden för att distribuera och driva en tjänst lite från kostnaden för att distribuera och driva tio tjänster (i själva verket är den nästan densamma för 100 tjänster). Lägg till detta behållare som en förpackningsmekanism som uppmuntrar flerspråkig implementering, och du har en mängd nya applikationer implementerade i form av mikrotjänster skrivna på olika språk - precis den typ av miljö som ett servicenät är så väl lämpat för.
Så vi kommer till svaret på frågan om varför idén med ett servicenät har blivit populärt nu: homogeniteten som Kubernetes tillhandahåller för tjänster gäller direkt de operativa utmaningarna som ett servicenät står inför. Du paketerar fullmakterna i behållare, ger Kubernetes uppgiften att sätta fast dem varhelst den kan, och voila! Som ett resultat får du ett servicenät, medan all mekanik för dess utplacering hanteras av Kubernetes. (Åtminstone ur fågelperspektiv. Naturligtvis finns det många nyanser i denna process.)
För att sammanfatta det: anledningen till att servicenät har blivit populära nu, och för inte tio år sedan, är att Kubernetes och Docker inte bara har ökat markant behöver i den, efter att ha förenklat implementeringen av applikationer som uppsättningar av flerspråkiga mikrotjänster, men också avsevärt minskat kostar för dess drift, tillhandahållande av mekanismer för att distribuera och stödja sidovagns-proxyflottor.
Varför pratas det så mycket om servicenät?
Varning: I det här avsnittet använder jag mig av alla typer av antaganden, gissningar, påhitt och insiderinformation.
Gör en sökning efter "servicenät" och du kommer att stöta på massor av återvunnet lågkaloriinnehåll, konstiga projekt och ett kalejdoskop av distorsion värdig en ekokammare. Alla tjusiga ny teknik gör detta, men i fallet med ett servicenät är problemet särskilt akut. Varför?
Nåväl, en del av det är mitt fel. Jag har arbetat hårt för att marknadsföra Linkerd och servicenätet varje chans jag får genom otaliga blogginlägg och artiklar som den här. Men jag är inte så stark. För att verkligen svara på denna fråga måste vi prata lite om den övergripande situationen. Och det är omöjligt att prata om det utan att nämna ett projekt: är ett tjänstenät med öppen källkod utvecklat gemensamt av Google, IBM och Lyft.
(De tre företagen har mycket olika roller: Lyfts engagemang tycks endast vara i namnet; de är författare till Envoy, men använder eller deltar inte i Istios utveckling. IBM är involverad i och använder Istios utveckling. Google är aktivt involverad i Istios utveckling. utveckling, men använder den faktiskt inte så vitt jag kan säga.)
Istio-projektet är anmärkningsvärt för två saker. För det första är det den enorma marknadsföringsinsats som särskilt Google lägger på att marknadsföra det. Jag skulle uppskatta att de flesta som känner till servicenätkonceptet idag först lärde sig om det genom Istio. Den andra saken är hur dåligt mottagen Istio blev. I den här frågan är jag självklart en intresserad part, men att försöka förbli så objektiv som möjligt kan jag fortfarande inte hjälpa , inte särskilt distinkt (men inte unik: systemd kommer att tänka på, ...) för ett Open Source-projekt.
(I praktiken verkar Istio ha problem inte bara med komplexitet och UX, utan även med prestanda. T.ex. I en tredje parts studie fann forskare situationer där Istios svanslatens var 100 gånger högre än Linkerds, samt resurssnåla situationer där Linkerd fortsatte att fungera framgångsrikt medan Istio slutade fungera helt.)
Bortsett från mina teorier om varför detta hände, tror jag att den överväldigande spänningen kring servicenätet förklaras av Googles deltagande. Nämligen en kombination av följande tre faktorer:
- Googles påträngande marknadsföring av Istio;
- en motsvarande ogillande, kritisk inställning till projektet;
- Kubernetes senaste snabba ökning i popularitet, vars minnen fortfarande är färska.
Tillsammans skapar dessa faktorer en förbluffande, syrefri miljö där förmågan till rationell bedömning är försvagad, och bara den konstiga sorten finns kvar. .
Ur Linkerds perspektiv är detta...vad jag skulle beskriva som en blandad välsignelse. Jag menar, det är bra att servicemesh har kommit in i mainstream på ett sätt som det inte gjorde 2016 när Linkerd först startade och det var verkligen svårt att få folk att uppmärksamma projektet. Nu finns det inget sådant problem! Men de dåliga nyheterna är att servicenätlandskapet är så förvirrande idag att det är nästan omöjligt att förstå vilka projekt som faktiskt hör hemma i servicenätkategorin (låt vara att förstå vilket som är bäst lämpat för ett visst användningsfall). Detta är definitivt en dealbreaker för alla (och det finns definitivt vissa fall där Istio eller ett annat projekt är bättre lämpat än Linkerd, eftersom det senare fortfarande inte är en universell lösning).
På Linkerds sida har vår strategi varit att ignorera bruset, fortsätta att fokusera på att lösa verkliga samhällsproblem och i princip vänta på att hypen försvinner. I slutändan kommer hajpen att avta och vi kan fortsätta jobba lugnt.
Under tiden måste vi alla ha lite tålamod.
Kommer ett servicenät att vara användbart för mig, en ödmjuk mjukvaruingenjör?
Följande frågeformulär hjälper dig att besvara denna fråga:
Är du enbart involverad i att implementera affärslogik? I det här fallet kommer servicenätet inte att vara användbart för dig. Det vill säga, självklart kan du vara intresserad av det, men helst bör servicenätet inte direkt påverka någonting i din miljö. Fortsätt jobba med det du får betalt för att göra.
Stöder du plattformen på ett företag som använder Kubernetes? Ja, i det här fallet behöver du ett servicenät (om du förstås inte använder K8s bara för att köra en monolit eller batch-bearbetning - men då skulle jag vilja fråga varför du behöver K8s). Du kommer sannolikt att få många mikrotjänster skrivna av olika människor. De interagerar alla med varandra och är bundna till en virvel av runtime-beroenden, och du måste hitta ett sätt att hantera allt. Genom att använda Kubernetes kan du välja ett servicenät "för dig själv". För att göra detta, bekanta dig med deras kapacitet och funktioner och svara på frågan om något av de tillgängliga projekten är lämpliga för dig (jag rekommenderar att du börjar din forskning med Linkerd).
Är du ett plattformsföretag på ett företag som INTE använder Kubernetes utan använder mikrotjänster? I det här fallet kommer ett servicenät att vara användbart för dig, men dess användning kommer att vara icke-trivial. Såklart du kan imitera work service mesh genom att placera ett gäng proxyservrar, men en viktig fördel med Kubernetes är distributionsmodellen: manuellt underhåll av dessa proxyservrar kommer att kräva mycket mer tid, ansträngning och kostnader.
Är du ansvarig för plattformen i ett företag som jobbar med monoliter? I det här fallet behöver du förmodligen inte ett servicenät. Om du arbetar med monoliter (eller till och med samlingar av monoliter) som har väldefinierade och sällan föränderliga interaktionsmönster, kommer ett servicenät att ha lite att erbjuda dig. Så du kan helt enkelt ignorera det och hoppas att det försvinner som en ond dröm...
Slutsats
Förmodligen bör servicenät fortfarande inte kallas "världens mest hypade teknik" - denna tvivelaktiga ära tillhör förmodligen Bitcoin eller AI. Hon är förmodligen bland de fem bästa. Men om du skär igenom lagren av buller blir det tydligt att servicenätet ger verkliga fördelar för dem som bygger applikationer på Kubernetes.
Jag skulle vilja att du testar Linkerd - installera den på ett Kubernetes-kluster (eller till och med Minikube på en bärbar dator) , och du kan själv se vad jag pratar om.
FAQ
— Om jag ignorerar servicenätet, kommer det att försvinna?
— Jag måste göra dig besviken: servicenätet är med oss länge.
– Men jag VILL INTE använda servicenät!
– Nja, det är inte nödvändigt! Läs bara mitt frågeformulär ovan för att förstå om du åtminstone bör bekanta dig med dess grunder.
— Är inte detta gamla goda ESB/mellanvara med en ny sås?
— Service mesh handlar om operationell logik, inte semantisk. företagsservicebuss (). Att bibehålla denna separation hjälper servicenätet att undvika samma öde.
— Hur skiljer sig ett servicenät från API-gateways?
– Det finns en miljon artiklar om detta ämne. Googla bara.
— Envoy är ett servicenät?
– Nej, Envoy är inte ett servicenät, det är en proxyserver. Den kan användas för att organisera ett servicenät (och mycket mer - det är en proxy för allmänt bruk). Men i sig är det inget servicenät.
— Network Service Mesh är ett servicenät?
- Nej. Trots namnet är detta inte ett servicenät (hur gillar du marknadsföringsmirakel?).
— Kommer ett servicenät att hjälpa till med mitt meddelandeköbaserade reaktiva asynkrona system?
– Nej, servicenät hjälper dig inte.
— Vilket servicenät ska jag använda?
- , enkel.
– Artikeln suger! / Författaren är välkommen!
— Dela länken till den med alla dina vänner så att de kan se den!
Kvitteringar
Som du kanske har gissat från titeln, var den här artikeln inspirerad av Jay Kreps fantastiska avhandling "" Jag träffade Jay för tio år sedan när jag intervjuade honom på Linked In och han har varit en inspiration för mig sedan dess.
Även om jag gillar att kalla mig en "Linkerd-utvecklare", är verkligheten att jag är mer av en underhållare av filen README.md på ett projekt. Linkerd arbetar på idag , , människor, och det här projektet skulle inte ha hänt utan deltagandet av en underbar gemenskap av bidragsgivare och användare.
Och till sist, ett speciellt tack till skaparen av Linkerd, (primus inter pares), som tillsammans med mig för många år sedan dök handlöst ner i allt detta tjafs med servicenät.
PS från översättaren
Läs även på vår blogg:
- «";
- «";
- «";
- «";
- «".
Källa: will.com