Service Mesh: vad varje mjukvaruingenjör behöver veta om den mest hypeade teknologin

Obs. övers.: Service mesh — ett fenomen som ännu inte har en etablerad översättning till svenska (för över 2 år sedan föreslog vi termen „tjänstenät”, och senare började några kollegor aktivt promota kombinationen „tjänstfilter”). De ständiga diskussionerna kring denna teknik har lett till en situation där marknadsföring och teknisk aspekt har blivit alltför sammanvävda. Denna fantastiska artikel av en av skaparna av det ursprungliga begreppet syftar till att klargöra för ingenjörer och andra.

Comic by Sebastian Caceres

Introduktion

Om du är en mjukvaruingenjör som arbetar någonstans i närheten av backend-system, är termen „service mesh” troligtvis redan djupt rotad i ditt medvetande under de senaste åren. Tack vare en märklig slump av omständigheterna fångar denna fras alltmer uppmärksamhet i branschen, och hypen och de tillhörande reklamerna växer som en snöboll som rullar nerför en backe och visar inga tecken på att sakta ner.

Service mesh föddes i de grumliga, partiska vattnen i cloud native-ekosystemet. Tyvärr innebär detta att en stor del av den relaterade debatten varierar från „lågkalorisk prat” till — för att använda en teknisk term — ren galenskap. Men om man filtrerar bort alla buller kan man upptäcka att service mesh har en helt verklig, bestämd och viktig funktion.

I den här publikationen kommer jag att försöka göra just det: ge en ärlig, djupgående, ingenjörsorienterad vägledning om service mesh. Jag tänker svara på inte bara frågan: „Vad är det?”, — utan också „Varför?”, samt „Varför just nu?”. Slutligen kommer jag att försöka skissa på varför (enligt min mening) just denna teknik har orsakat sådan galen uppståndelse, vilket i sig är en intressant historia.

Vem är jag?

Hej allihopa! Jag heter William Morgan. Jag är en av skaparna av Linkerd — det första service mesh-projektet och projektet som ligger bakom att termen kom till service mesh som sådan (ursäkta, grabbar!). (För övrigt.: För att nämna, vid tidpunkten för detta termes uppkomst, för över 2,5 år sedan, översatte vi redan tidigt material av samma författare med titeln „Vad är service mesh och varför behöver jag det [för en molnapplikation med mikrotjänster]?».) Jag leder också Buoyant — en startup som skapar sådana coola service mesh-grejer som Linkerd och Dive.

Du kanske kan gissa att jag har en ganska partisk och subjektiv åsikt i denna fråga. Men jag ska försöka hålla tendensen till ett minimum (med undantag för en sektion: „Varför så många samtal om service mesh?“, — där jag ändå kommer att dela med mig av mina partiska idéer). Jag kommer också att göra mitt bästa för att göra den här guiden så objektiv som möjligt. När jag ger specifika exempel kommer jag huvudsakligen att förlita mig på erfarenheterna från Linkerd, samtidigt som jag pekar på kända skillnader (om sådana finns) i implementationen av andra typer av service mesh.

Okej, dags att gå över till det smakliga.

Vad är en service mesh?

Även om det finns mycket hype, är service mesh strukturellt ganska enkelt. Det är bara en uppsättning användarproxyer som ligger "nära" tjänsterna (vi kommer att diskutera vad "nära" betyder lite senare), plus en uppsättning hanteringsprocesser. Proxyerna kallas tillsammans för data plane, och hanteringsprocesserna kallas control plane. Data plane fångar upp anrop mellan tjänster och gör "olika saker" med dem; control plane koordinerar beteendet hos proxyerna och ger dig, det vill säga operatören, tillgång till API:et så att du kan manipulera nätverket och mäta det som en helhet.

Vad är dessa proxyer? Det är TCP-proxyer av kategorin „Layer 7-aware“ (dvs. som „tar hänsyn till“ lager 7 i OSI-modellen) såsom HAProxy och NGINX. Du kan välja proxy efter smak; Linkerd använder en proxy i Rust, enkelt kallad linkerd-proxy. Vi har byggt den speciellt för service mesh. Andra mesh-alternativ föredrar andra proxyer (Envoy är ett vanligt val). Men valet av proxy är bara en fråga om implementering.

Vad gör dessa proxyservrar? Självklart, de proxyar anrop till och från tjänster (strikt taget fungerar de både som proxy och omvänd proxy, vilket hanterar både inkommande och utgående anrop). Och de implementerar en uppsättning funktioner som fokuserar på anrop mellan tjänster. Denna fokusering på trafik mellan tjänster skiljer service mesh-proxyerna från, säg, API-gateways eller ingress-proxyer (de senare fokuserar på anrop som kommer in i klustret från omvärlden). (Obs. övers.: för en jämförelse av befintliga Ingress-kontrollerare för Kubernetes, många av vilka använder den redan nämnda Envoy, se denna artikel.)

Så, vi har förstått data plane. Control plane är enklare: det är en uppsättning komponenter som säkerställer all mekanik som behövs för att data plane ska fungera koordinerat, inklusive tjänstupptäckter, utfärdande av TLS-certifikat, aggregering av mätvärden, osv. Data plane informerar control plane om sitt beteende; i sin tur tillhandahåller control plane ett API som gör det möjligt att ändra och övervaka beteendet hos data plane som en enhet.

Nedan visas diagrammet för control plane och data plane i Linkerd. Som man kan se inkluderar control plane flera olika komponenter, inklusive en instans av Prometheus som samlar in mätvärden från proxyservrar, samt andra komponenter som destination (tjänstupptäckter), identity (certifikatutfärdare, CA) och public-api (ändpunkter för webben och CLI). I motsats till detta är data plane en enkel linkerd-proxy bredvid applikationsinstansen. Detta är bara ett logiskt diagram; i praktiken, vid distribution kan du ha tre repliker av varje komponent i control plane och hundratals eller tusentals proxies i data plane.

(De blå rektanglarna i detta diagram symboliserar gränserna för Kubernetes-poddar. Det är uppenbart att containrar med linkerd-proxy finns i samma podd som applikationscontainrar. En sådan konfiguration kallas för sidecar-container.)

Arkitekturen för service mesh har flera viktiga konsekvenser. För det första, eftersom proxyernas uppgift är att fånga anrop mellan tjänster, är service mesh meningsfullt endast om din applikation byggdes på en uppsättning tjänster. Mesh kan användas med monoliter, men det är uppenbart överflödigt för en enda proxy, och funktionaliteten kommer troligtvis inte att efterfrågas.

En annan viktig konsekvens är att service mesh kräver ett stort antal proxies. Faktum är att Linkerd kopplar linkerd-proxy till varje instans av varje tjänst (andra implementationer lägger till proxyer till varje nod/värd/virtuell maskin. I vilket fall som helst, det är inte lite). Denna aktiva användning av proxies i sig medför en rad ytterligare komplikationer:

1. Proxyn i data plane måste vara snabba, eftersom varje anrop innebär ett par anrop till proxyn: ett på klientsidan, ett på serversidan.
2. Proxyn måste också vara små och och lättviktiga.. Varje proxy kommer att konsumera minnes- och CPU-resurser, och denna konsumtion kommer att öka linjärt med applikationen.
3. Du kommer att behöva en mekanism för att distribuera och uppdatera ett stort antal proxyer. Att göra detta manuellt är inget alternativ.

Generellt ser en service mesh ut så här (minst sagt uppifrån och ned): du distribuerar en massa userspace-proxyer som "gör något" med intern, interservice trafik och använder control plane för att övervaka och hantera dem.

Det är dags att ställa frågan "Varför?"

Vad behöver en service mesh egentligen?

För dem som stöter på tanken om service mesh för första gången är det förståeligt att känna en lätt nervositet. Konstruktionen av en service mesh innebär att den inte bara kommer att öka fördröjningen i applikationen, utan också konsumerar resurser och lägger till en massa nya mekanismer i infrastrukturen. Först installerar du service mesh och plötsligt upptäcker du att du måste hantera hundratals (om inte tusentals) proxyer. Frågan är, vem vill göra det frivilligt?

Svaret på denna fråga består av två delar. För det första kan driftkostnaderna relaterade till distributionen av dessa proxyer avsevärt minskas tack vare vissa förändringar som sker i ekosystemet (mer om detta senare).

För det andra är en sådan enhet faktiskt ett utmärkt sätt att införa ytterligare logik i systemet. Och inte bara för att det går att lägga till många nya funktioner med hjälp av service mesh, utan också för att detta kan göras utan att störa ekosystemet. Faktum är att hela modellen för service mesh bygger på denna postulat: i ett flerservice-system, oavsett vad gör de enskilda tjänsterna, är trafiken mellan dem en perfekt punkt för att lägga till funktionalitet.

Till exempel i Linkerd (liksom i de flesta mesh-system) är funktionaliteten främst fokuserad på HTTP-anrop, inklusive HTTP/2 och gRPC*. Funktionaliteten är ganska riklig - den kan delas in i tre klasser:

1. Funktioner relaterade till tillförlitlighet. Återkoppling, tidsgränser, kanariefågelsmetoden (fördelning/omdirigering av trafik) etc.
2. Funktioner relaterade till övervakning.Aggregering av framgångsmått, fördröjningar och begärningsvolymer för varje tjänst eller specifika riktningar; byggande av topologiska kartor över tjänster etc.
3. Funktioner relaterade till säkerhet. Mutual TLS, åtkomstkontroll etc.

* Ur Linkerd-synpunkt skiljer sig gRPC praktiskt taget inte från HTTP/2: det är bara i nyttolasten som protobuf används. Ur en utvecklares perspektiv skiljer sig dessa två saker, förstås.

Många av dessa mekanismer fungerar på begärningsnivå (därav "L7-proxy"). Till exempel, om tjänsten Foo skickar ett HTTP-anrop till tjänsten Bar, kan linkerd-proxy på Foo-sidan utföra intelligent lastbalansering och dirigera anrop från Foo till instanser av Bar beroende på observerad latens; den kan repetera anropet vid behov (och om det är idempotent); den kan registrera svarskoden och väntetiden, osv. På liknande sätt kan linkerd-proxy på Bar-sidan avvisa anropet om det inte är tillåtet eller överskrider begärningsgränsen; den kan registrera latens från sin sida, osv.

Proxyn kan "göra något" även på anslutningsnivå. Till exempel kan linkerd-proxy på Foo-sidan initiera en TLS-anslutning, medan linkerd-proxy på Bar-sidan kan bryta den, och båda sidor kan kontrollera TLS-certifikaten för varandra*. Detta säkerställer inte bara kryptering mellan tjänster, utan även ett kryptografiskt säkert sätt att identifiera tjänster: Foo och Bar kan "bevisa" att de är de de säger sig vara.

* "Varandra" betyder att klientens certifikat också kontrolleras (ömsesidig TLS). I "klassisk" TLS, till exempel mellan en webbläsare och en server, kontrolleras vanligtvis endast certifikatet för den ena sidan (servern).

Oavsett om de arbetar på begärnings- eller anslutningsnivå är det viktigt att understryka att alla funktioner i service mesh är operativa i sin natur. Linkerd kan inte transformera semantiken i nyttolasten - till exempel lägga till fält i en JSON-fragment eller göra ändringar i protobuf. Denna viktiga aspekt kommer vi att diskutera senare när vi pratar om ESB och middleware.

Detta är funktionen som erbjuds av service mesh. Frågan uppstår: varför inte implementera dem direkt i applikationen? Och varför ens använda en proxy?

Varför service mesh är en bra idé

Även om funktionerna hos service mesh fångar fantasin ligger dess verkliga värde egentligen inte i funktionerna. I slutändan kan vi kan implementera dem direkt i applikationen (senare kommer vi att se att detta var ursprunget till service mesh). Om vi försöker sammanfatta denna tanke i en mening, så är värdet av service mesh följande: den tillhandahåller funktioner som är kritiskt viktiga för modern serverprogramvaras drift, enhetligt för hela stacken och oberoende av applikationskoden.

Låt oss analysera denna mening.

«Funktioner som är kritiskt viktiga för modern serverprogramvaras drift». Om du skapar en transaktionell serverapplikation som är kopplad till det offentliga internet, som tar emot begärningar från omvärlden och svarar på dem inom en kort tidsram — till exempel en webbapplikation, en API-server, eller faktiskt de flesta andra moderna applikationer — och om du implementerar den som en uppsättning tjänster som interagerar med varandra synkront, och om du ständigt uppgraderar denna programvara genom att lägga till nya funktioner, och om du tvingas hålla detta system fungerande under modifieringarna — då gratulerar jag dig, du sysslar med att skapa modern serverprogramvara. Och alla dessa fantastiska funktioner som nämns ovan visar sig faktiskt vara kritiskt viktiga för dig. Applikationen måste vara pålitlig, säker och du måste kunna övervaka vad den gör. Just dessa frågor hjälper service mesh att lösa.

(Okej, i den föregående stycket smög sig min övertygelse in om att detta tillvägagångssätt är ett modernt sätt att skapa serverprogramvara. Andra föredrar att utveckla monoliter, 'reaktiva mikrotjänster' och andra saker som inte faller under definitionen ovan. Dessa människor har förmodligen en åsikt som skiljer sig från min. Å sin sida anser jag att de 'har fel' — även om service mesh kanske inte är särskilt användbart för dem).

«Enhetligt för hela stacken». Funktioner som tillhandahålls av service mesh är inte bara kritiskt viktiga. De tillämpas på alla tjänster i applikationen oavsett vilket språk de är skrivna i, vilket ramverk som används, vem som har skrivit dem, hur de har distribuerats och av alla de andra nyanser i deras utveckling och användning.

«Oberoende av applikationskodenTill slut ger en service mesh inte bara enhetliga funktioner för hela stacken – den gör detta på ett sätt som inte kräver ändringar i applikationen. Den grundläggande funktionen hos en service mesh, inklusive uppgifter som konfiguration, uppdatering, drift, underhåll, etc., är helt och hållet på plattformsnivå och oberoende av applikationen. Applikationen kan förändras utan att påverka service meshen. Å sin sida kan service meshen förändras utan att applikationen behöver delta.

För att sammanfatta, service mesh ger inte bara livsviktiga funktioner, utan gör det på ett globalt, enhetligt och applikationsoberoende sätt. Och därför, även om funktionaliteten hos en service mesh kan implementeras i servicekoden (t.ex. som ett bibliotek som ingår i varje service), kommer den här metoden inte att ge den enhetlighet och oberoende som är så värdefulla i en service mesh.

Och allt som behövs för detta är att lägga till en massa proxys! Jag lovar, mycket snart kommer vi att granska de driftskostnader som är kopplade till att lägga till dessa proxys. Men först, låt oss stanna upp och se på denna idé om oberoende ur olika perspektiv. människor.

Vem drar nytta av service mesh?

Hur obekvämt det än må vara, för att en viss teknik ska bli en viktig del av ekosystemet, måste den antas av människor. Så vem är intresserad av service mesh? Vem vinner på att använda den?

Om du utvecklar modern serverprogramvara kan du föreställa dig ditt team som en grupp tjänsteägare, som tillsammans utvecklar och implementerar affärslogik, och plattformägare, som sysslar med att utveckla den interna plattformen på vilken dessa tjänster körs. I mindre organisationer kan det vara samma personer, men i takt med att företaget växer tenderar dessa roller att bli mer distinkta och delas till och med upp i underroller… (Det finns mycket att säga om den föränderliga naturen av DevOps, den organisatoriska påverkan av mikrotjänster, osv. Men låt oss för tillfället acceptera dessa beskrivningar som en givenhet.)

Från den här synvinkeln är plattformsägare de uppenbara vinnarna av service mesh. I slutändan är plattformsteamets mål att skapa en intern plattform där tjänsteägare kan implementera affärslogik på ett sätt som säkerställer deras maximal oberoende från de tråkiga detaljerna i driften. Service mesh erbjuder inte bara möjligheter som är kritiskt viktiga för att uppnå detta mål: den gör det på ett sätt som i sin tur inte ålägger några beroenden på tjänsteägarna.

Tjänsteägarna drar också nytta, om än på ett mer indirekt sätt. Målet för en tjänsteägare är att vara så produktiv som möjligt i implementeringen av affärsprocessens logik, och ju mindre de behöver oroa sig för driftsfrågor, desto bättre. Istället för att behöva hantera implementeringen av till exempel omfrågepolicyer eller TLS kan de fokusera helt och hållet på affärsuppgifterna och hoppas att plattformen tar hand om allt annat. För dem är detta en stor fördel.

Det organisatoriska värdet av en sådan uppdelning mellan plattforms- och tjänsteägare är svårt att överskatta. Jag anser att det bidrar huvud till värdet av service mesh.

Vi lärde oss denna läxa när en av de första anhängarna av Linkerd berättade för oss varför de valde service mesh: för att den gjorde att de kunde "minimera pratandet". Här är lite mer information: killarna från ett stort företag migrerade sin plattform till Kubernetes. Eftersom applikationen hanterade känslig information ville de kryptera all kommunikation i kluster. Men situationen försvårades av att det fanns hundratals tjänster och hundratals utvecklarteam. Utsikten att behöva kontakta alla och övertyga dem att inkludera stöd för TLS i sina planer gladde dem inte alls. Genom att installera Linkerd flyttade de ansvaret från utvecklarna (som tyckte att det var onödigt krångel) till plattformsägarna, för vilka detta var en högsta prioritet. Med andra ord löste Linkerd för dem inte bara en teknisk, utan även en organisatorisk utmaning.

Kort sagt är service mesh i högre grad en lösning på en icke-teknisk socioteknisk utmaning. (Tack Cindy Sridharan för att introducera detta begrepp.)

Kommer service mesh att lösa alla mina problem?

Ja. Alltså, nej!

När man tittar på de tre funktionernas klasser som nämnts ovan: tillförlitlighet, säkerhet och övervakning, blir det tydligt att service mesh inte är en fullständig lösning för något av dessa problem. Även om Linkerd kan skicka om förfrågningar (om den vet att de är idempotenta), kan den inte fatta beslut om vad som ska returneras till användaren om tjänsten har kraschat helt — sådana beslut måste applikationen fatta. Linkerd kan hålla statistik över framgångsrika förfrågningar, men den kan inte kika in i tjänsten och ge dess interna mått — sådana verktyg måste finnas i applikationen. Även om Linkerd kan organisera mTLS kräver verkliga lösningar inom säkerhet mycket mer.

Delmängden av funktioner inom dessa områden som erbjuds av service mesh tillhör plattformens funktioner. Med detta menar jag funktioner som:

1. Är oberoende av affärslogik. Sättet som histogram över anrop mellan Foo och Bar byggs upp på, beror helt och hållet inte på om varför Foo anropar Bar.
2. Det är svårt att implementera korrekt. I Linkerd parameteriseras omförsök med alla möjliga avancerade saker som återhämtningsbudgetar (retry budgets), eftersom en enkel rak metod för att implementera sådana saker säkerligen skulle leda till vad som kallas en "förfrågningslavin" (retry storm) och andra problem som är typiska för distribuerade system.
3. Är mest effektiva när de tillämpas enhetligt. TLS-mekanismen är meningsfull endast när den tillämpas överallt.

Eftersom dessa funktioner implementeras på proxy-nivå (och inte på applikationsnivå) tillhandahåller service mesh dem på plattformsnivå , och inte applikationsnivå. Således spelar det ingen roll vilket språk tjänsterna är skrivna i, vilket ramverk de använder, vem som har skrivit dem och varför. Proxyn fungerar bortom alla dessa detaljer, och den grundläggande grunden för denna funktionalitet, inklusive uppgifter kring konfiguration, uppdatering, drift, underhåll osv., ligger helt på plattformsnivå.Exempel på funktioner i service mesh

Exempel på funktioner för service mesh

Sammanfattningsvis vill jag säga att en service mesh inte är en komplett lösning för att säkerställa tillförlitlighet, övervakning eller säkerhet. Omfånget av dessa områden kräver nödvändig medverkan från tjänsteägare, Ops/SRE-team och andra aktörer inom företaget. Service mesh erbjuder endast ett "snitt" på plattformsnivå för var och en av dessa områden.

Varför har service mesh blivit populärt just nu?

Förmodligen undrar du just nu: okej, om service mesh är så bra, varför började vi inte rulla ut miljontals proxies 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 en service mesh. Det är sant, men enligt min mening går poängen förlorad i ett sådant svar. Redan för tio år sedan diskuterades och tillämpades konceptet med mikrotjänster som en lovande metod för att bygga stora system brett inom företag som Twitter, Facebook, Google och Netflix. Den allmänna uppfattningen - åtminstone inom de delar av branschen som jag haft kontakt med - var att mikrotjänster var det "rätta sättet" att skapa stora system, även om det var riktigt svårt.

Självklart, även om det för tio år sedan fanns företag som använde mikrotjänster, stoppade de inte in proxies överallt för att skapa en service mesh. Men om man ser noga på det, gjorde de något liknande: i många av dessa företag var det obligatoriskt att använda ett speciellt internt bibliotek för nätverkskommunikation (ibland kallat tjockklientbibliotek, fat client library).

Netflix hade Hysterix, Google hade Stubby, Twitter hade biblioteket Finagle. Finagle var till exempel obligatoriskt för varje ny tjänst på Twitter. Det hanterade både klient- och serverdelen av anslutningarna, tillät försök på nytt, stödde förfrågans routning, belastningsbalansering och mätning. Det erbjöd ett konsekvent lager av tillförlitlighet och övervakning för hela Twitter-stacken, oavsett vad tjänsten sysslade med. Självklart fungerade det bara för JVM-språk och byggde på den programmeringsmodell som var tvungen att användas för hela applikationen. Men dess funktionalitet var nästan densamma som för en service mesh. (Den första versionen av Linkerd var faktiskt bara Finagle, inpackad i en proxyform.)

Så för tio år sedan fanns det inte bara mikrotjänster, utan även speciella proto-service-mesh-bibliotek som löste samma problem som service mesh löser idag. Men det fanns ingen riktig service mesh då. En ytterligare förändring måste ske innan den kom till existens.

Och här ligger det djupare svaret, dolt i en annan förändring som inträffat under de senaste 10 åren: kostnaden för att deployera mikrotjänster har minskat dramatiskt. Företagen som nämndes tidigare, Twitter, Netflix, Facebook, Google, var enorma företag med stora resurser. De hade både behovet och möjligheten att skapa, deployera och driva stora applikationer baserade på mikrotjänster. Energin och ansträngningen som Twitter-ingenjörerna lade ner för att gå från monolitisk till mikrotjänstarkitektur är verkligen anmärkningsvärd. (Ärligt talat, precis som faktumet att det lyckades.) Den typen av infrastrukturella manövrar var då omöjliga för mindre företag.

Låt oss ta steget in i nutiden. Idag finns det startups där förhållandet mellan mikrotjänster och utvecklare är 5:1 (eller till och med 10:1), och dessutom klarar de sig bra med dem! Om en startup med 5 personer utan problem kan hantera 50 mikrotjänster, så måste något ha sänkt kostnaden för deras implementering.

1500 mikrotjänster i Monzo; varje rad är en angiven nätverksregel som tillåter trafik

Den dramatiska kostnadsminskningen för drift av mikrotjänster är resultatet av en process: ökad popularitet av containrar och orkestratorer. Det är i detta som det djupa svaret på frågan om vad som har bidragit till framväxten av service mesh ligger. Samma teknologi har gjort både service mesh och mikrotjänster attraktiva: Kubernetes och Docker.

Varför? Jo, Docker löser ett stort problem - paketproblemet. Genom att paketera applikationen och dess (icke-nätverks) runtime-beroenden i en container gör Docker applikationen till en utbytbar enhet som kan placeras och köras var som helst. Samtidigt förenklar det driften av flerspråkiga Stack: Eftersom containern är en atomär enhet för utförande, spelar det ingen roll vad som finns inuti för distributions- och driftsättningssyften, vare sig det är en applikation på JVM, Node, Go, Python eller Ruby. Du kör helt enkelt den, och det är allt.

Kubernetes tar allt till en ny nivå. Nu när det finns en massa "exekverbara saker" och flera maskiner där de kan köras, uppstår behovet av ett verktyg som kan matcha dem med varandra. I bred bemärkelse ger du Kubernetes många containrar och många maskiner, och den matchar dem (självklart är det en dynamisk och ständigt förändrande process: nya containrar rör sig genom systemet, maskiner startas och stängs av osv. Men Kubernetes tar hänsyn till allt detta).

Efter att ha konfigurerat Kubernetes skiljer tidskostnaderna för distribution och drift av en tjänst knappt från kostnaderna för distribution och drift av tio tjänster (egentligen är de praktiskt taget lika även för 100 tjänster). Lägg därtill containrar som en förpackningsmekanism som uppmuntrar flerspråkig implementering, så får du massor av nya applikationer som implementeras i form av mikrotjänster skrivna på olika språk - just den miljö som service mesh är så väl anpassad för.

Så vi har kommit till svaret på frågan om varför idén med service mesh blivit populär just nu: den enhetlighet som Kubernetes möjliggör för tjänster är direkt tillämplig på de driftsättningsuppgifter som står inför service mesh. Du paketerar proxy i containrar, ger Kubernetes uppgiften att fästa dem var som helst, och voila! Resultatet är en service mesh, där hela mekaniken för dess distribution drivs av Kubernetes. (Åtminstone från fågelperspektiv. Självklart finns det många nyanser i denna process.)

Sammanfattningsvis: orsaken till att service mesh blivit populär just nu snarare än för tio år sedan, är att Kubernetes och Docker inte bara har ökat behovet av det genom att förenkla implementeringen av applikationer som samlingar av flerspråkiga mikrotjänster, utan även avsevärt minskat kostnaderna för dess drift genom att erbjuda mekanismer för distribution och stöd för sidecar-proxyparker.

Varför talas det så mycket om service mesh?

Varning: i detta avsnitt lutar jag mig mot alla möjliga antaganden, tankar, spekulationer och intern information.

Genom att söka på frasen "service mesh" kommer du att stöta på en massa omarbetat lågkalorinnehåll, konstiga projekt och ett kalejdoskop av förvrängningar värdiga en ekokammare. Detta är typiskt för alla trendiga nya teknologier, men i fallet med service mesh är problemet särskilt uttalat. Varför?

Tja, delvis är det mitt fel. Jag har gjort allt jag kan för att främja Linkerd och service mesh vid varje tillfälle genom otaliga bloggposter och artiklar som denna. Men jag är inte så mäktig. För att faktiskt kunna svara på denna fråga är det nödvändigt att prata lite om den allmänna situationen. Och att prata om det går inte utan att nämna ett projekt: Istio — en öppen källkods service mesh, utvecklad av Google, IBM och Lyft tillsammans.

(Dessa tre företag har helt olika roller: Lyft's deltagande verkar mest vara ett namn; de är skaparna av Envoy, men använder varken Istio eller deltar i dess utveckling. IBM deltar i utvecklingen av Istio och använder det. Google är aktivt involverat i utvecklingen av Istio, men såvitt jag kan bedöma, faktiskt inte använder det.)

Projektet Istio är anmärkningsvärt av två anledningar. För det första är det de enorma marknadsföringsinsatserna som Google, i synnerhet, lägger ner på dess främjande. Enligt mina uppskattningar är majoriteten av de personer som idag känner till begreppet service mesh först medvetna om det tack vare Istio. Den andra anledningen är hur dåligt Istio har accepterats. I denna fråga är jag uppenbarligen partisk, men i mitt försök att förbli så objektiv som möjligt kan jag ändå inte notera väldigt negativ inställning, inte särskilt typisk (även om det inte är unikt: jag tänker på systemd, jämförelsen har gjorts redan flertalet gånger…) för ett Open Source-projekt.

(I praktiken verkar Istio ha problem inte bara med komplexitet och användarupplevelse, utan också med prestanda. Till exempel under prestandautvärdering av Linkerd, genomförd av en tredje part, upptäckte experter situationer där Istios svanslatens var 100 gånger högre än motsvarande siffra för Linkerd, samt situationer med resursbrist där Linkerd fortsatte att fungera framgångsrikt medan Istio helt slutade fungera.)

Låt mig lämna mina teorier om varför detta har hänt åt sidan; jag tror att det överdrivna intresset för service mesh förklaras av Googles involvering. Specifikt en kombination av följande tre faktorer:

1. den påträngande marknadsföringen av Istio från Google;
2. den negativa och kritiska inställningen till projektet;
3. den senaste snabba ökningen i popularitet för Kubernetes, vars minnen fortfarande är färska.

Tillsammans förenas dessa faktorer i en sorts bedövande, syrefattig miljö där förmågan till rationellt tänkande försvagas, och det kvarstår endast en underlig variation av tulpanmani..

Från Linkerds perspektiv skulle jag beskriva detta som en tvetydig välsignelse. Jag menar, det är fantastiskt att service mesh har blivit mainstream — vilket inte var fallet 2016, när Linkerd just hade dök upp och det verkligen var svårt att få omvärldens uppmärksamhet för projektet. Nu finns det inte det problemet! Men det negativa är att situationen kring service mesh idag är så förvirrande att det är praktiskt taget omöjligt att förstå vilka projekt som verkligen hör till kategorin service mesh (för att inte tala om att förstå vilket av dem som passar bäst för ett specifikt användningsfall). Detta hindrar definitivt alla (och i vissa fall passar Istio eller ett annat projekt bättre än Linkerd, eftersom det sistnämnda fortfarande inte är en universallösning).

Från Linkerds sida har vår strategi varit att ignorera ljudet, fortsätta fokusera på att lösa verkliga problem i samhället och i princip vänta på att hypen ska lägga sig. I slutändan kommer hajpen att avta, och vi kan fortsätta arbeta i lugn och ro.

Under tiden får vi alla uthärda en stund.

Kommer service mesh vara användbart för mig, en blygsam mjukvaruingenjör?

Svaret på denna fråga kan hjälpa till att avgöras av följande enkät:

Arbetar du enbart med implementering av affärslogik? I så fall kommer service mesh inte att vara till nytta för dig. Det vill säga, självklart kan du bli intresserad av det, men i idealfallet bör service mesh inte direkt påverka något i din miljö. Fortsätt arbeta med det du får betalt för.

Underhåller du en plattform inom ett företag som använder Kubernetes? Ja, i så fall behöver du service mesh (såvida du inte använder K8s bara för att köra en monolit eller för batchbearbetning — men då skulle jag vilja fråga varför du ens använder K8s). Det är troligt att du hamnar i en situation med många mikrotjänster skrivna av olika personer. Dessa interagerar med varandra och är sammanlänkade i ett knippe av runtime-beroenden, och du måste hitta ett sätt att hantera allt detta. Att använda Kubernetes gör att du kan välja en service mesh som passar dig. För att göra detta, bekanta dig med deras möjligheter och egenskaper och avgör om något av de befintliga projekten passar dig (jag rekommenderar att börja med Linkerd).

Arbetar du med en plattform i ett företag som INTE använder Kubernetes, men använder mikrotjänster? I så fall kommer service mesh att vara nyttig för dig, men att använda den kommer att vara en utmaning. Naturligtvis kan du imitera funktionen av service mesh genom att lägga upp en massa proxies, men en viktig fördel med Kubernetes är just distributionsmodellen: att underhålla dessa proxies manuellt kommer att kräva betydligt mer tid, ansträngning och kostnad.

Är du ansvarig för plattformen i ett företag som arbetar med monoliter? I så fall behöver du förmodligen inte någon service mesh. Om du arbetar med monoliter (eller till och med med uppsättningar av monoliter) som har väl definierade och sällan förändrade interaktionsmönster, kommer service mesh inte att kunna erbjuda dig mycket. Så du kan helt enkelt ignorera den och hoppas att den ska försvinna som en mardröm...

Slutsats

Kanske är det ändå inte rätt att kalla service mesh för "den mest hype-teknologin i världen" — den tveksamma hederstjänsten tillhör troligtvis bitcoin eller AI. Kanske är den bland de fem bästa. Men om man lyckas tränga igenom lagren av brus och oljud, blir det tydligt att service mesh faktiskt tillför verkligt värde för dem som bygger applikationer i Kubernetes.

Jag skulle vilja att du provade Linkerd – dess installation i en Kubernetes-kluster (eller till och med i Minikube på din bärbara dator) tar omkring 60 sekunder, och du kommer själv att få se vad jag pratar om.

FAQ

— Om jag ignorerar service mesh, försvinner den?
— Jag måste uppröra dig: service mesh är här för att stanna.

— Men jag VILL INTE använda service mesh!
— Då behöver du inte! Läs bara min enkät ovan för att avgöra om du bör bekanta dig med åtminstone grunderna.

— Är inte detta den gamla goda ESB/middleware i ny förpackning?
— Service mesh hanterar driftslogik, inte semantik. Detta var den största nackdelen med företagsservicenätet (ESB). Att bevara denna uppdelning hjälper service mesh att undvika samma öde.

— Hur skiljer sig service mesh från API-gateways?
— Det finns en miljon artiklar om detta. Bara googla.

— Är Envoy ett service mesh?
— Nej, Envoy är inte ett service mesh, det är en proxyserver. Den kan användas för att organisera service mesh (och mycket annat – det är en allroundproxy). Men i sig själv är den inte ett service mesh.

— Är Network Service Mesh ett service mesh?
— Nej. Trots namnet är det inte ett service mesh (hur kan marknadsföring lura oss?).

— Kommer service mesh hjälpa min reaktiva asynkrona system baserat på meddelandeköer?
— Nej, service mesh kommer inte att hjälpa.

— Vilket service mesh ska jag använda?
— Linkerd, det är uppenbart.

— Artikeln är skräp! / Författaren kan dra åt skogen!
— Var snäll och dela länken till den här med alla vänner så att de kan se det själva!

Tack.

Som du kanske har gissat från titeln, blev den här artikeln inspirerad av Jay Kreps fantastiska avhandling "The Log: What every software engineer should know about real-time data’s unifying abstraction". Jag träffade Jay för tio år sedan när jag intervjuade på LinkedIn, och sedan dess har han varit en inspiration för mig.

Även om jag älskar att kalla mig själv "Linkerd-utvecklare", är verkligheten den att jag snarare är en underhållare av README.md-filen i projektet. Många mycket, mycket, mycket män , arbetar med Linkerd idag, och detta projekt skulle inte ha lyckats utan det fantastiska bidragande och användarsamhället.

Och till sist ett stort tack till skaparen av Linkerd, Oliver Gould (primus inter pares), som för många år sedan dykt ner i denna service mesh-hysteri tillsammans med mig.

P.S. från översättaren

Läs även i vår blogg:

• «Vad är service mesh och varför behöver jag det [för en molnapplikation med mikrotjänster]?»;
• «Traefik 2.0: uppdatering av service mesh med TCP-stöd och ett nytt webbgränssnitt»;
• «Maesh — en ny enkel service mesh för Kubernetes från skaparna av Traefik»;
• «Tillbaka till mikrotjänster med Istio. Del 1»;
• «Conduit — en lättviktsservice mesh för Kubernetes».

Källa: habr.com