🥇Användningsfall för service mesh

Notera. transl.Författaren till den här artikeln (Luc Perkins) är utvecklarrepresentant på CNCF, hemvist för open source-projekt som Linkerd, SMI (Service Mesh Interface) och Kuma (har du förresten någonsin undrat varför Istio inte finns med på den här listan?...). I ett annat försök att ge DevOps-communityn en bättre förståelse för den trendiga hypen som kallas "service mesh" listar han 16 karakteristiska funktioner som sådana lösningar erbjuder.

I dag servicenät ― är ett av de hetaste ämnena inom mjukvaruutveckling (och med rätta!). Jag tycker att det är en otroligt lovande teknik och jag drömmer om att se den bli allmänt använd (när det är logiskt, förstås). Den har dock fortfarande en aura av mystik över sig för de flesta. Även de som Jag känner honom väl med det, har ofta svårt att formulera dess fördelar och vad det exakt är (inklusive er ödmjuke tjänare). I den här artikeln ska jag försöka korrigera situationen genom att lista olika användningsscenarier "servicenät"*.

* Översättarens anmärkning: från och med nu i den här artikeln kommer denna översättning ("service mesh") att användas för den fortfarande nya termen service mesh.

Men först vill jag göra några kommentarer:

Jag har aldrig arbetat med eller använt service meshes utanför projekt som jag genomfört för min egen utbildning. Å andra sidan skrev jag massor av dokumentation för Twitters interna service mesh 2015 (det kallades inte ens ett "service mesh" på den tiden) och bidrog till webbplatsen och dokumentationen för Linkerd, så det betyder något.
Min lista är preliminär och ofullständig. Det finns sannolikt användningsfall som jag inte känner till, och nya kommer sannolikt att dyka upp med tiden allt eftersom tekniken utvecklas och blir mer populär.
Samtidigt stöder inte alla befintliga service mesh-implementeringar alla listade användningsfall. Så mina uttalanden som "service mesh kan..." bör läsas som "vissa, och kanske alla, populära service mesh-implementeringar kan...".
Ordningen på exemplen spelar ingen roll.

Kort lista:

tjänsteupptäckt;
kryptering;
autentisering och auktorisering;
lastbalansering;
kretsbrytning;
autoskalning;
kanariefågelutplaceringar;
blågröna utplaceringar;
hälsokontroll;
avlastning;
trafikspegling;
isolering;
begränsning av begärandefrekvens, återförsök och timeouts;
telemetri;
granska;
visualisering.

1. Tjänsteupptäckt

TL;DR: Anslut till andra tjänster i nätverket med enkla namn.

Tjänster bör automatiskt kunna "hitta" varandra med hjälp av lämpliga namn - till exempel, service.api.production, pets/staging eller cassandraMolnmiljöer kännetecknas av sin elasticitet, och ett namn kan dölja flera tjänsteinstanser. Det är tydligt att det i en sådan situation är fysiskt omöjligt att hårdkoda alla IP-adresser.

Dessutom, när en tjänst hittar en annan, bör den kunna skicka förfrågningar till den tjänsten utan rädsla för att de hamnar vid inmatningen av dess trasiga instans. Med andra ord bör tjänstens mesh övervaka hälsan hos alla tjänsteinstanser och hålla listan över värdar så uppdaterad som möjligt.

Varje service mesh implementerar tjänsteidentifiering på olika sätt. För närvarande är det vanligaste sättet att delegera till externa processer som Kubernetes DNS. Tidigare använde vi på Twitter ett namnsystem för detta ändamål. FinagelDessutom gör service mesh-tekniken det möjligt att skapa anpassade namngivningsmekanismer (även om jag ännu inte har stött på någon SM-implementering med sådan funktionalitet).

2. Kryptering

TL;DR: Bli av med okrypterad trafik mellan tjänster och automatisera och skalbar den här processen.

Det är bra att veta att angripare inte kan ta sig in i ditt interna nätverk. Brandväggar gör ett bra jobb med att förhindra det. Men vad händer om en hackare tar sig in? Kommer de att kunna göra vad de vill med trafiken inom tjänsten? Låt oss hoppas att det inte händer. För att förhindra ett sådant scenario bör du implementera ett zero-trust-nätverk, där all trafik mellan tjänster är krypterad. De flesta moderna tjänstenätverk uppnår detta genom ömsesidiga ... TLS (ömsesidig TLS, mTLS). I vissa fall fungerar mTLS i hela moln och kluster (jag tror att interplanetär kommunikation en dag kommer att arrangeras på liknande sätt).

Naturligtvis, för mTLS-tjänstnätet frivilligVarje tjänst kan hantera sin egen TLS, men det innebär att hitta ett sätt att generera certifikat, distribuera dem mellan tjänstvärdar, inkludera kod i applikationen som laddar dessa certifikat från filer. Och glöm inte att förnya dessa certifikat med jämna mellanrum. Tjänstnät automatiserar mTLS med system som SPIFFE, vilket i sin tur automatiserar processen för att utfärda och rotera certifikat.

3. Autentisering och auktorisering

TL;DR: Fastställ vem som initierar begäran och definiera vad de har tillstånd att göra innan begäran ens når tjänsten.

Tjänster vill ofta veta, som gör en begäran (autentisering) och bestämmer sig med hjälp av denna information att detta subjekt har tillåtelse att göra (auktorisering). I detta fall kan pronomenet "vem" gömmas:

Andra tjänster. Detta kallas "autentisering peer'a"Till exempel tjänsten web vill ha tillgång till tjänsten dbTjänstnät löser vanligtvis sådana problem med hjälp av mTLS: certifikat fungerar i detta fall som den nödvändiga identifieraren.
Vissa mänskliga användare. Detta kallas "autentisering begäran"Till exempel, användaren haxor69 vill köpa en ny lampa. Servicenät tillhandahåller olika mekanismer, såsom JSON webbtoken.
Många av oss har gjort detta i vår applikationskod. En förfrågan kommer in, vi tittar på en tabell users, hitta användaren och jämför lösenordet, kontrollera sedan kolumnen permissions etc. När det gäller ett service mesh händer detta redan innan begäran når tjänsten.

När vi har fastställt vem begäran kom ifrån måste vi avgöra vad den sökande har tillåtelse att göra. Vissa servicenät låter dig ställa in grundläggande policyer (om vem som kan göra vad) som YAML-filer eller på kommandoraden, medan andra erbjuder integration med ramverk som Öppna Policy AgentSlutmålet är att era tjänster ska acceptera alla förfrågningar med förtroendet att de kommer från en betrodd källa. и Denna åtgärd är tillåten.

4. Lastbalansering

TL;DR: Fördela belastningen över tjänsteinstanser enligt ett specifikt mönster.

"Tjänst" i tjänsteavsnittet består ofta av många identiska kopior. Till exempel, idag tjänsten cache består av 5 exemplar, och imorgon kan deras antal öka till 11. Förfrågningar skickas till cache, bör distribueras enligt ett specifikt mål. Till exempel för att minimera latens eller för att maximera sannolikheten för att komma till en fungerande instans. Den vanligaste algoritmen är Round-robin-tjänstalgoritmen, men det finns många andra, såsom den viktade (viktad) frågor (du kan välja önskade mål), ring (ringa) hashing (använd konsekvent hashing för uppströmsvärdar) eller minsta möjliga fråga-metoden (preferens ges till instansen med färst antal frågor).

Klassiska lastbalanserare har andra funktioner, såsom HTTP-cachning och DDoS-skydd, men de är inte särskilt relevanta för öst-västlig trafik (den typiska tillämpningen av ett service mesh). Naturligtvis behöver du inte nödvändigtvis använda ett service mesh för lastbalansering, men det låter dig ställa in och kontrollera lastbalanseringspolicyer för varje tjänst från ett centraliserat kontrollplan, vilket eliminerar behovet av att köra och konfigurera separata lastbalanserare i nätverksstacken.

5. Kretsbrytning

TL;DR: Stoppa trafiken till den problematiska tjänsten och kontrollera skadan i värsta tänkbara scenarier.

Om tjänsten av någon anledning inte kan hantera trafiken, erbjuder tjänstens mesh flera alternativ för att lösa problemet (andra kommer att diskuteras i relevanta avsnitt). Kretsbrytning är det allvarligaste alternativet för att koppla bort tjänsten från trafiken. Det är dock inte meningsfullt i sig självt – en reservplan behövs. Mottryck kan tillhandahållas. (mottryck) till tjänster som gör förfrågningar (kom bara ihåg att konfigurera ditt tjänstenät för detta!), eller till exempel att färga statussidan röd och omdirigera användare till nästa version av sidan med den "fallande valen" ("Twitter är nere").

Servicenät låter dig inte bara avgöra, när en nedstängning kommer att följa och att kommer att följa. I det här fallet kan "när" inkludera valfri kombination av angivna parametrar: det totala antalet förfrågningar under en viss period, antalet parallella anslutningar, väntande förfrågningar, aktiva återförsök etc.

Du vill förmodligen inte överanvända kretsbrytare, men det är bra att veta att du har en reservplan i händelse av en nödsituation.

6. Autoskalning

TL;DR: Öka eller minska antalet tjänstinstanser baserat på angivna kriterier.

Servicenät är inte schemaläggare, så de gör det inte fullgöra skalning på egen hand. De kan dock ge information som planerare kan använda för att fatta beslut. Eftersom tjänstenät har tillgång till all trafik mellan tjänster har de en mängd information om vad som händer: vilka tjänster som upplever problem, vilka som är underutnyttjade (deras allokerade kapacitet slösas bort) etc.

Till exempel skalar Kubernetes tjänster baserat på poddarnas CPU- och minnesanvändning. (Se vår rapport)Autoskalning och resurshantering i Kubernetes" - cirka. översätt.), men om du väljer att skala baserat på något annat mätvärde (i vårt fall trafikrelaterat) behöver du ett dedikerat mätvärde. något liknande detta visar hur man gör detta med Sändebud, Samma и Prometheus, men själva processen är ganska komplex. Vi skulle vilja att servicenätet förenklade det, så att vi helt enkelt kunde ställa in villkor som "öka antalet serviceinstanser auth, om antalet förfrågningar som väntar på att köras överstiger tröskelvärdet i en minut."

7. Kanarieöarnas utplaceringar

TL;DR: Testa nya funktioner eller versioner av en tjänst på en delmängd av användare.

Låt oss säga att du bygger en SaaS-produkt och ska lansera en ny cool version. Du har testat den i staging, och den fungerar utmärkt. Men du har fortfarande vissa funderingar kring hur den kommer att bete sig i verkliga förhållanden. Med andra ord vill du testa den nya versionen på verkliga uppgifter utan att riskera dina användares förtroende. Canary-distributioner är utmärkta för detta. De låter dig demonstrera en ny funktion för en delmängd av användare. Denna delmängd kan vara dina mest lojala användare, eller de som använder gratisversionen av produkten, eller användare som har anmält sig frivilligt att vara "försökskaniner".

Tjänstnät gör detta genom att låta dig ange kriterier för vem som ser vilken version av din app och dirigera trafik därefter. Ingenting ändras för själva tjänsterna. Version 1.0 av en tjänst antar att alla förfrågningar kommer från användare som borde se den, och version 1.1 antar detsamma för sina användare. Samtidigt kan du ändra andelen trafik mellan den gamla och nya versionen, vilket omdirigerar ett växande antal användare till den nya om den är stabil och dina "försökskaniner" ger klartecken.

8. Blågröna utplaceringar

TL;DR: Lansera en cool ny funktion, men var beredd att återställa den omedelbart.

Betydelse blågröna utplaceringar är att lansera en ny "blå" tjänst, som körs parallellt med den gamla, "gröna". Om allt går smidigt och den nya tjänsten visar sig vara bra, kan den gamla gradvis stängas av. (Tyvärr kommer denna nya "blå" tjänst en dag också att drabbas av samma öde som den "gröna" och försvinna...) Blågröna implementeringar skiljer sig från kanarieblommor genom att den nya funktionen täcker på en gång användare (inte en del); poängen här är att ha en "backupport" redo om något går fel.

Tjänstenät erbjuder ett mycket bekvämt sätt att testa en "blå" tjänst och omedelbart byta till en fungerande "grön" tjänst vid problem. För att inte tala om att de också ger mycket information (se "Telemetri" nedan) om driften av den "blå" tjänsten, vilket hjälper till att förstå om den är redo för full drift.

Notera. transl.Du kan läsa mer om de olika implementeringsstrategierna i Kubernetes (inklusive den nämnda canary, blue/green och andra) i den här artikeln.

9. Hälsokontroll

TL;DR: Övervaka vilka tjänstinstanser som är felfria och åtgärda de som inte längre är felfria.

Hälsokontroll (hälsokontroll) hjälper till att avgöra om tjänsteinstanser är redo att acceptera och bearbeta trafik. Till exempel, när det gäller HTTP-tjänster, kan en hälsokontroll se ut som en GET-begäran till en slutpunkt. /healthSvar 200 OK betyder att instansen är felfri, alla andra - att den inte är redo att acceptera trafik. Med servicenät kan du ange både hur hälsan kontrolleras och hur ofta denna kontroll utförs. Denna information kan sedan användas för andra ändamål - till exempel för lastbalansering och kretsbrytning.

Hälsokontroller är således inte ett fristående användningsfall, utan används vanligtvis för att uppnå andra mål. Beroende på resultaten av hälsokontrollerna kan externa (i förhållande till andra mål för service mesh) åtgärder krävas: till exempel att uppdatera statussidan, skapa ett ärende på GitHub eller fylla i ett JIRA-ärende. Och service mesh erbjuder en bekväm mekanism för att automatisera allt detta.

10. Lastavkoppling

TL;DR: Omdirigera trafik som svar på en tillfällig användningstopp.

Om en tjänst är överbelastad med trafik kan du tillfälligt omdirigera en del av den trafiken till en annan plats (dvs. "släppa" eller "hälla" den) (skjul) (den finns där). Till exempel till en säkerhetskopieringstjänst eller ett datacenter, eller till en permanent tryck ämne. Som ett resultat kommer tjänsten att fortsätta att bearbeta vissa förfrågningar istället för att krascha och inte bearbeta någonting alls. Lastavstängning är att föredra framför kedjebrott, men det är fortfarande inte lämpligt att överanvända det. Det hjälper till att förhindra kaskadfel som orsakar att nedströmstjänster kraschar.

11. Parallellisering/spegling av trafik

TL;DR: Skicka en förfrågan till flera platser samtidigt.

Ibland finns det behov av att skicka en begäran (eller ett urval av begäranden) till flera tjänster samtidigt. Ett typiskt exempel är att skicka en del av produktionstrafiken till en staging-tjänst. Den huvudsakliga produktionswebbservern skickar en begäran till den efterföljande tjänsten. products.production och endast till den. Och tjänstens mesh kopierar intelligent denna begäran och skickar den till products.staging, vilket webbservern inte ens vet om.

Ett annat relaterat användningsfall för service mesh som kan implementeras utöver trafikparallellisering är regressionstestningDet innebär att skicka samma förfrågningar till olika versioner av en tjänst och kontrollera om alla versioner beter sig likadant. Jag har ännu inte sett en implementering av service mesh med ett integrerat regressionstestningssystem som Diffy, men själva idén verkar lovande.

12. Isolering

TL;DR: Dela upp ditt tjänstenätverk i mininätverk.

Även känd som segmentering, isolering är konsten att dela upp ett tjänstenät i logiskt separata segment som inte vet något om varandra. Isolering är lite som att skapa virtuella privata nätverk. Den viktigaste skillnaden är att du fortfarande får alla fördelar med ett tjänstenät (som tjänsteupptäckt), men med ökad säkerhet. Om en angripare till exempel lyckas penetrera en tjänst i ett delnät, kommer de inte att kunna se vilka tjänster som körs i andra delnät eller fånga upp deras trafik.

Det kan också finnas organisatoriska fördelar. Ni kanske vill dela upp tjänster i undernät baserat på er företagsstruktur och frigöra utvecklare från den kognitiva belastningen av att behöva hålla koll på hela tjänstenätet.

13. Begränsning av begärandefrekvens, återförsök och timeouts

TL;DR: Du behöver inte längre inkludera tidskrävande uppgifter för förfrågningshantering i din kodbas.

Alla dessa saker skulle kunna betraktas som separata användningsfall, men jag bestämde mig för att gruppera dem på grund av en sak de har gemensamt: de avlastar uppgifterna för hantering av förfrågningslivscykeln som vanligtvis hanteras av applikationsbibliotek. Om du bygger en Ruby on Rails webbserver (inte integrerad med service mesh) som gör förfrågningar till backend-tjänster via gRPC, måste applikationen själv bestämma vad den ska göra om N förfrågningar misslyckas. Den måste också räkna ut hur mycket trafik dessa tjänster kan hantera och hårdkoda dessa parametrar med hjälp av ett speciellt bibliotek. Dessutom måste applikationen bestämma när den ska ge upp och låta förfrågan bli felaktig (genom timeout). Och för att ändra någon av ovanstående parametrar måste webbservern stoppas, konfigureras om och startas om.

Att delegera dessa uppgifter till tjänstenätet innebär inte bara att tjänsteutvecklare inte behöver tänka på dem, utan också att de kan betraktas på ett mer globalt sätt. Om du har en komplex kedja av tjänster, säg A –> B –> C –> D –> E, måste du beakta hela livscykeln för en begäran. Om du behöver förlänga timeouts i tjänst C är det klokt att göra allt på en gång, snarare än att göra det i bitar: uppdatera tjänstkoden och vänta på att pull-begäran ska accepteras och att CI-systemet distribuerar den uppdaterade tjänsten.

14. Telemetri

TL;DR: Samla all nödvändig (och inte riktigt nödvändig) information från tjänster.

Telemetri är ett paraplybegrepp som omfattar mätvärden, distribuerad spårning och loggar. Tjänstenät erbjuder mekanismer för att samla in och bearbeta alla tre typer av data. Det är här det blir lite luddigt, eftersom antalet möjliga alternativ är för stort. För mätvärden finns det Prometheus och andra verktyg som kan användas för att samla in loggar flytande, Loke, vektor etc. (till exempel ClickHouse med vår timmerhus för K8s — översättarens anmärkning), för distribuerad spårning finns det Jaeger etc. Varje servicenätverk kan ha stöd för vissa verktyg och inte andra. Det ska bli intressant att se om projektet kan Öppen telemetri ge viss konvergens.

I det här fallet är fördelen med service mesh-teknik att sidecar-containrar i princip kan samla in all ovanstående data från sina tjänster. Med andra ord får du ett enda telemetri-insamlingssystem till ditt förfogande, och service mesh kan bearbeta all denna information på olika sätt. Till exempel:

svansloggar från en viss tjänst i CLI;
spåra förfrågningsvolymen från service mesh-instrumentpanelen;
samla in distribuerade spår och vidarebefordra dem till ett system som Jaeger.

Uppmärksamhet, subjektiv bedömning: Generellt sett är telemetri ett område där man inte vill ha mycket störningar från service mesh. Att samla in grundläggande information och spåra några "gyllene mätvärden" i farten, som framgångsfrekvens och latens, är okej, men låt oss hoppas att vi inte ser Frankenstein-stackar dyka upp som försöker ersätta specialiserade system, av vilka några redan är väl etablerade och väl förstådda.

15. Revision

TL;DR: De som glömmer historiens lärdomar är dömda att upprepa dem.

Revision är konsten att övervaka viktiga händelser i ett system. När det gäller ett tjänstenät kan detta innebära att spåra vem som har gjort förfrågningar till specifika slutpunkter för specifika tjänster, eller hur många gånger en viss säkerhetsrelaterad händelse har inträffat under den senaste månaden.

Det är tydligt att revision är mycket nära besläktad med telemetri. Skillnaden är att telemetri vanligtvis förknippas med saker som prestanda och teknisk lämplighet, medan revision kan avse juridiska och andra frågor som faller utanför det strikt tekniska området (till exempel efterlevnad av EU:s allmänna dataskyddsförordning).

16. Visualisering

TL;DR: Länge leve React.js, källan till konstiga gränssnitt.

Det kanske finns en bättre term, men jag vet inte vilken. Jag menar bara en grafisk representation av service mesh eller några av dess komponenter. Dessa visualiseringar kan inkludera indikatorer som genomsnittliga latenser, information om konfiguration av sidecar-containrar, resultat av hälsokontroller och aviseringar.

Att arbeta i en serviceinriktad miljö är förknippat med en mycket högre kognitiv belastning jämfört med Hans Majestät Monoliten. Därför bör den kognitiva belastningen minskas till varje pris. Ett enkelt grafiskt gränssnitt för tjänsten i kombination med möjligheten att klicka på en knapp och få önskat resultat kan vara avgörande för utvecklingen av denna teknik.

Var inte med i listan

Jag hade ursprungligen tänkt inkludera några fler användningsfall i listan, men bestämde mig sedan för att inte göra det. Här är de, tillsammans med skälen till mitt beslut:

MultidatacenterEnligt mig är detta inte så mycket ett användningsfall som en smal och specifik tillämpning av servicenät eller någon uppsättning funktioner som tjänsteupptäckt.
Ingång och utgångDetta är ett relaterat område, men jag har begränsat mig (kanske artificiellt) till användningsfallet "öst-västlig trafik". Ingång och utgång förtjänar en separat artikel.

Slutsats

Det var allt för nu! Återigen, den här listan är mycket villkorlig och troligtvis ofullständig. Om du tror att jag missat något eller gjort ett misstag, kontakta mig på Twitter (@lucperkins). Vänligen följ anständighetsreglerna.

PS från översättaren

Huvudillustrationen för artikeln är baserad på en bild från artikeln “Vad är ett servicenät (och när ska man använda ett)?"(av Gregory MacKinnon) Den visar hur en del av funktionaliteten från applikationerna (i grönt) har migrerat till servicenätet som tillhandahåller kopplingarna mellan dem (i blått).

Läs även på vår blogg:

Källa: will.com