🥇Service mesh use cases

Bemærk. overs.: Forfatteren af denne artikel (Luc Perkins) er en udvikleradvokat hos CNCF-organisationen, som er hjemsted for sådanne Open Source-projekter som Linkerd, SMI (Service Mesh Interface) og Kuma (har du i øvrigt også undret dig over, hvorfor Istio er ikke på denne liste? .). Endnu en gang forsøger han at give DevOps-fællesskabet en bedre forståelse af den trendy hype, der kaldes "service mesh", opremser han 16 karakteristiske egenskaber, som sådanne løsninger giver.

I dag servicenet ― et af de hotteste emner inden for software engineering (og med rette!). Jeg synes, denne teknologi er utroligt lovende og vil gerne se den bredt vedtaget (når det giver mening, selvfølgelig). Det er dog stadig omgivet af en aura af mystik for de fleste mennesker. Samtidig er selv dem, der Kendt med det er det ofte svært at formulere dets fordele, og hvad det præcist er (inklusive yours truly). I denne artikel vil jeg forsøge at rette op på situationen ved at opremse forskellige brugssager "servicemasker"*.

* Bemærk oversættelse: her og længere i artiklen vil netop denne oversættelse ("service mesh") blive brugt om det stadig nye udtryk service mesh.

Men først vil jeg komme med et par kommentarer:

Jeg har aldrig arbejdet med servicemasker eller brugt dem uden for projekter startet til min egen uddannelse. På den anden side var det mig, der skrev en masse dokumentation til Twitters interne service mesh i 2015 (det hed ikke engang et "service mesh" dengang) og deltog i udviklingen af hjemmesiden og dokumentation for Linkerd, så det betyder noget.
Min liste er omtrentlig og ufuldstændig. Der kan meget vel være use cases, der er ukendte for mig, og nye muligheder vil sandsynligvis opstå over tid, efterhånden som teknologien udvikler sig og dens popularitet vokser.
Samtidig understøtter ikke alle eksisterende servicemesh-implementeringer alle de angivne use cases. Derfor skal mine udsagn som "service mesh can..." læses som "individuelle, og måske kan alle populære service mesh implementeringer...".
Rækkefølgen af eksemplerne gør ingen forskel.

Kort liste:

service opdagelse;
kryptering;
autentificering og autorisation;
belastningsbalancering;
kredsløbsbrud;
autoskalering;
kanarie-udlægninger;
blå-grønne implementeringer;
sundhedstjek;
belastningsreduktion;
trafik spejling;
isolering;
anmodningshastighedsbegrænsning, genforsøg og timeouts;
telemetri;
revidere;
visualisering.

1. Service opdagelse

TL;DR: Opret forbindelse til andre tjenester på netværket ved hjælp af simple navne.

Tjenester skal automatisk kunne "finde" hinanden ved at bruge passende navne - f.eks. service.api.production, pets/staging eller cassandra. Skymiljøer er elastiske, og et enkelt navn kan skjule mange forekomster af en tjeneste. Det er klart, at det i en sådan situation er fysisk umuligt at hardkode alle IP-adresser.

Plus, når en tjeneste finder en anden, bør den være i stand til at sende anmodninger til den pågældende tjeneste uden frygt for, at de ender ved input af dens ødelagte instans. Med andre ord skal servicenettet overvåge sundheden for alle serviceinstanser og holde listen over værter så opdateret som muligt.

Hvert servicemesh implementerer serviceopdagelsesmekanismen forskelligt. I øjeblikket er den mest almindelige måde at uddelegere til eksterne processer som DNS Kubernetes. Tidligere på Twitter brugte vi et navnesystem til dette formål Finagle. Derudover gør service mesh-teknologi det muligt for brugerdefinerede navngivningsmekanismer at dukke op (selvom jeg endnu ikke har set nogen SM-implementering med en sådan funktionalitet).

2. Kryptering

TL;DR: Slip af med ukrypteret trafik mellem tjenester og gør denne proces automatiseret og skalerbar.

Det er rart at vide, at angribere ikke kan trænge ind i dit interne netværk. Firewalls gør et godt stykke arbejde med dette. Men hvad sker der, hvis en hacker kommer ind? Vil han være i stand til at gøre, hvad han vil med intra-service trafik? Lad os håbe, at det ikke sker alligevel. For at forhindre dette scenarie bør du implementere et nul-tillidsnetværk, hvor al trafik mellem tjenester er krypteret. De fleste moderne servicenet opnår dette gennem gensidigt TLS (gensidig TLS, mTLS). I nogle tilfælde fungerer mTLS i hele skyer og klynger (jeg tror, at interplanetarisk kommunikation en dag vil blive arrangeret på samme måde).

Selvfølgelig til mTLS service mesh valgfri. Hver tjeneste kan tage sig af sin egen TLS, men det betyder, at du bliver nødt til at finde en måde at generere certifikater på, distribuere dem på tværs af tjenesteværter og inkludere kode i den applikation, der indlæser disse certifikater fra filer. Ja, glem ikke at forny disse certifikater med jævne mellemrum. Service meshes automatiserer mTLS med systemer som SPIFFE, som igen automatiserer processen med at udstede og rotere certifikater.

3. Godkendelse og autorisation

TL;DR: Fastlæg, hvem rekvirenten er, og definer, hvad de må gøre, før anmodningen overhovedet når frem til tjenesten.

Tjenester ønsker ofte at vide der udfører anmodningen (godkendelse), og ved hjælp af disse oplysninger beslutter at en given enhed har lov til at gøre (autorisation). I dette tilfælde kan pronomenet "hvem" skjule:

Andre tjenester. Dette kaldes "godkendelse" jævnaldrende" For eksempel service web ønsker at få adgang til tjenesten db. Tjenestenet løser normalt sådanne problemer ved hjælp af mTLS: certifikater fungerer i dette tilfælde som den nødvendige identifikator.
Nogle menneskelige brugere. Dette kaldes "godkendelse" anmodning" For eksempel bruger haxor69 ønsker at købe en ny lampe. Servicenet giver forskellige mekanismer, f.eks. JSON web tokens.
Mange af os har gjort dette i applikationskode. En forespørgsel kommer ind, vi kigger bordet igennem users, find brugeren og sammenlign adgangskoden, og tjek derefter kolonnen permissions etc. I tilfælde af et servicenet sker dette, før anmodningen overhovedet når frem til tjenesten.

Når vi har fastslået, hvem anmodningen kom fra, skal vi bestemme, hvad denne enhed har tilladelse til at gøre. Nogle servicemasker giver dig mulighed for at indstille grundlæggende politikker (om hvem der kan gøre hvad) som YAML-filer eller på kommandolinjen, mens andre tilbyder integration med rammer som f.eks. Åbn Politikagent. Det ultimative mål er, at dine tjenester accepterer enhver anmodning, sikkert under forudsætning af, at den kommer fra en pålidelig kilde и denne handling er tilladt.

4. Lastbalancering

TL;DR: Fordel belastningen på tværs af serviceinstanser i henhold til et specifikt mønster.

En "Service" inden for en servicesektion består meget ofte af mange identiske instanser. For eksempel i dag tjenesten cache består af 5 eksemplarer, og i morgen kan deres antal stige til 11. Forespørgsler sendes til cache, skal fordeles i overensstemmelse med et bestemt formål. For eksempel for at minimere latens eller maksimere sandsynligheden for at komme til en fungerende instans. Den mest brugte algoritme er Round-robin, men der er mange andre - for eksempel den vægtede metode (vægtet) forespørgsler (du kan vælge foretrukne mål), ring (ring) hashing (ved at bruge konsistent hashing på tværs af upstream-værter) eller metode med mindst anmodning (foretrukket er den instans med de færreste anmodninger).

Klassiske balancere har andre funktioner, såsom HTTP-caching og DDoS-beskyttelse, men de er ikke særlig relevante for øst-vest trafik (det vil sige for trafik, der flyder inden for et datacenter - ca. transl.) (typisk omfang af service mesh). Det er selvfølgelig ikke nødvendigt at bruge et servicemesh til belastningsbalancering, men det giver dig mulighed for at indstille og kontrollere balanceringspolitikker for hver tjeneste fra et centraliseret kontrollag, og derved eliminere behovet for at køre og konfigurere separate belastningsbalancere i netværksstakken .

5. Kredsløbsbrud

TL;DR: Stop trafikken til den problematiske tjeneste og kontroller skaderne i værst tænkelige scenarier.

Hvis tjenesten af en eller anden grund ikke kan klare trafikken, giver servicenettet flere muligheder for at løse dette problem (andre vil blive diskuteret i de relevante afsnit). Circuit breaking er den mest alvorlige mulighed for at afbryde en tjeneste fra trafikken. Men i sig selv giver det ikke mening - en backup-plan er nødvendig. Modtryk kan være tilvejebragt (rygpres) til tjenester, der fremsætter anmodninger (bare glem ikke at konfigurere dit servicenet til dette!), eller for eksempel at farve statussiden rød og omdirigere brugere til en anden version af siden med en "faldende hval" ("Twitter er ned").

Servicenet giver dig ikke kun mulighed for at definere når nedlukning vil følge og at dette vil følge. I dette tilfælde kan "hvornår" omfatte enhver kombination af specificerede parametre: det samlede antal anmodninger for en bestemt periode, antallet af parallelle forbindelser, afventende anmodninger, aktive genforsøg osv.

Du vil sikkert ikke misbruge kredsløbsbrud, men det er rart at vide, at du har en backup-plan i tilfælde af en nødsituation.

6. Autoskalering

TL;DR: Forøg eller reducer antallet af tjenesteforekomster afhængigt af de angivne kriterier.

Tjenestenet er ikke skemalæggere, så det gør de ikke udføre skalerer dig selv. De kan dog give oplysninger om, hvilke planlæggere der vil basere deres beslutninger. Da servicemasker har adgang til al trafik mellem tjenesterne, har de omfattende information om, hvad der sker: Hvilke tjenester oplever problemer, hvilke tjenester er meget let belastede (den kapacitet, der er tildelt dem, er spildt) osv.

For eksempel skalerer Kubernetes tjenester baseret på pods' CPU og hukommelsesforbrug (se vores rapport"Autoskalering og ressourcestyring i Kubernetes"- ca. oversættelse), men hvis du beslutter dig for at skalere ud fra en hvilken som helst anden metrik (i vores tilfælde trafikrelateret), skal du bruge en speciel metrik. Ledelse sådan her viser hvordan man gør dette med udsending, Samme и Prometheus, men selve processen er ret kompliceret. Vi vil gerne have, at servicenettet forenkler dette ved at tillade os blot at sætte betingelser som "øge antallet af serviceforekomster auth, hvis antallet af afventende anmodninger overstiger tærsklen inden for et minut."

7. Kanariske indsættelser

TL;DR: Test nye funktioner eller serviceversioner på en undergruppe af brugere.

Lad os sige, at du udvikler et SaaS-produkt og har til hensigt at udrulle en cool ny version af det. Du testede det i iscenesættelse, og det fungerede godt. Men der er stadig visse bekymringer om hendes adfærd under virkelige forhold. Du skal med andre ord teste den nye version på reelle problemer uden at risikere brugertillid. Kanariske installationer er gode til dette. De giver dig mulighed for at demonstrere en ny funktion til en undergruppe af brugere. Denne undergruppe kan bestå af de mest loyale brugere eller dem, der arbejder med den gratis version af produktet, eller brugere, der har udtrykt et ønske om at være "marsvin".

Tjenestenet implementerer dette ved at give dig mulighed for at specificere kriterier, der bestemmer, hvem der skal se hvilken version af applikationen, og dirigere trafik i overensstemmelse hermed. Der ændres dog intet for selve tjenesterne. Version 1.0 af tjenesten mener, at alle anmodninger kommer fra brugere, der burde se den, og version 1.1 mener det samme for sine brugere. I mellemtiden kan du ændre trafikprocenten mellem den gamle og den nye version, og omdirigere et stigende antal brugere til den nye, hvis det fungerer stabilt, og dine "marsvin" giver grønt lys.

8. Blågrønne indsættelser

TL;DR: Udrul en cool ny funktion, men vær forberedt på straks at tage alt tilbage.

betydning blågrønne udrulninger er at udrulle en ny "blå" tjeneste, der lancerer den parallelt med den gamle, "grønne". Hvis alt går glat, og den nye tjeneste fungerer godt, kan den gamle gradvist deaktiveres. (Ak, en dag vil denne nye "blå" tjeneste gentage skæbnen for den "grønne" og forsvinde...) Blågrønne udrulninger adskiller sig fra de kanariske ved, at den nye funktion dækker alle på én gang brugere (ikke en del); Pointen her er at have en "sikker havn" klar, hvis noget går galt.

Servicenet tilbyder en meget praktisk måde at teste en "blå" tjeneste og øjeblikkeligt skifte til en fungerende "grøn" i tilfælde af problemer. For ikke at nævne det faktum, at de undervejs giver en masse information (se "Telemetri" nedenfor) om arbejdet med "den blå", som hjælper med at forstå, om den er klar til fuld drift.

Bemærk. overs.: Du kan læse mere om forskellige implementeringsstrategier i Kubernetes (inklusive den nævnte kanariefugl, blå/grøn og andre) i denne artikel.

9. Sundhedstjek

TL;DR: Hold styr på, hvilke serviceinstanser der er funktionelle og svar på dem, der ikke længere er funktionelle.

Sundhedstjek (sundhedstjek) hjælper med at beslutte, om serviceinstanser er klar til at acceptere og behandle trafik. For eksempel, i tilfælde af HTTP-tjenester, kan et sundhedstjek ligne en GET-anmodning til slutpunktet /health... Svar 200 OK vil betyde, at instansen er sund, enhver anden - at den ikke er klar til at modtage trafik. Tjenestenet giver dig mulighed for at angive både måden, hvorpå funktionaliteten skal kontrolleres, og den hyppighed, hvormed denne kontrol vil blive udført. Disse oplysninger kan så bruges til andre formål - for eksempel til belastningsafbalancering og kredsløbsafbrydelse.

Sundhedstjek er således ikke et enkeltstående use case, men bruges typisk til at nå andre mål. Afhængigt af resultaterne af sundhedstjek kan der også være behov for eksterne handlinger (i forhold til andre servicemesh-mål): for eksempel opdatering af statussiden, oprettelse af et problem på GitHub eller udfyldelse af en JIRA-billet. Og servicenet tilbyder en praktisk mekanisme til at automatisere alt dette.

10. Belastning

TL;DR: Omdiriger trafik som svar på en midlertidig stigning i brugen.

Hvis en bestemt tjeneste er overbelastet med trafik, kan du midlertidigt omdirigere noget af denne trafik til en anden placering (det vil sige "dump", "overfør" (skur) ham der). For eksempel til en backup-tjeneste eller datacenter eller til en permanent Tryk på emne. Som et resultat vil tjenesten fortsætte med at behandle nogle anmodninger i stedet for at gå ned og helt stoppe med at behandle alt. Belastningstab er at foretrække frem for at bryde kredsløbet, men det er stadig ikke tilrådeligt at misbruge det. Det hjælper med at forhindre cascading-fejl, der får downstream-tjenester til at gå ned.

11. Trafikparallelisering/spejling

TL;DR: Send én forespørgsel til flere steder på én gang.

Nogle gange er der behov for at sende en anmodning (eller et bestemt udvalg af anmodninger) til flere tjenester på én gang. Et typisk eksempel er at sende en del af produktionstrafikken til en iscenesættelsestjeneste. Hovedproduktionswebserveren sender en anmodning til downstream-tjenesten products.production og kun til ham. Og servicenettet kopierer denne anmodning intelligent og sender den til products.staging, som webserveren ikke engang er opmærksom på.

En anden relateret service mesh use case, der kan implementeres oven på trafik parallelisering er regressionstest. Det involverer at sende de samme anmodninger til forskellige versioner af tjenesten og kontrollere, om alle versioner opfører sig ens. Jeg er endnu ikke stødt på en service mesh-implementering med et integreret regressionstestsystem som Diffy, men selve ideen virker lovende.

12. Isolering

TL;DR: Bryd dit servicenet op i mini-netværk.

Også kendt som segmenteringIsolation er kunsten at opdele et servicenet i logisk adskilte segmenter, der ikke ved noget om hinanden. Isolation er lidt ligesom at skabe virtuelle private netværk. Den grundlæggende forskel er, at du stadig kan nyde alle fordelene ved et servicenetværk (som serviceopdagelse), men med ekstra sikkerhed. For eksempel, hvis en angriber er i stand til at trænge ind i en tjeneste på et undernet, vil han ikke være i stand til at se, hvilke tjenester der kører på andre undernet eller opsnappe deres trafik.

Derudover kan fordelene også være organisatoriske. Du ønsker måske at subnet dine tjenester baseret på din virksomheds struktur og aflaste udviklere for den kognitive belastning ved at skulle have hele tjenestenet i tankerne.

13. Anmod om hastighedsbegrænsning, genforsøg og timeouts

TL;DR: Du behøver ikke længere at inkludere de nøgne anmodningshåndteringsopgaver i din kodebase.

Alle disse ting kunne betragtes som separate use cases, men jeg besluttede at kombinere dem på grund af en fælles funktion: de overtager de opgaver, der typisk håndteres af applikationsbiblioteker. Hvis du udvikler en webserver i Ruby on Rails (ikke integreret med et servicemesh), der sender anmodninger til backend-tjenester via gRPC, skal applikationen beslutte, hvad den skal gøre, hvis N anmodninger mislykkes. Du bliver også nødt til at finde ud af, hvor meget trafik disse tjenester vil være i stand til at behandle og hardkode disse parametre ved hjælp af et særligt bibliotek. Derudover skal applikationen beslutte, hvornår det er tid til at give op og lade anmodningen udløbe (baseret på timeout). Og for at ændre nogen af ovenstående parametre, skal webserveren stoppes, omkonfigureres og startes igen.

At overføre disse opgaver til et servicemesh betyder ikke kun, at serviceudviklere ikke behøver at tænke på dem, men også at de kan ses på en mere global måde. Hvis der bruges en kompleks kæde af tjenester, f.eks. A -> B -> C -> D -> E, skal hele forespørgslens livscyklus tages i betragtning. Hvis opgaven er at forlænge timeouts i tjeneste C, er det logisk at gøre dette på én gang, og ikke i dele: ved at opdatere servicekoden og vente, indtil pull-anmodningen er accepteret, og CI-systemet implementerer den opdaterede tjeneste.

14. Telemetri

TL;DR: Indsaml alle de nødvendige (og ikke helt) oplysninger fra tjenester.

Telemetri er en generel term, der inkluderer metrikker, distribueret sporing og logfiler. Tjenestenet tilbyder mekanismer til indsamling og behandling af alle tre typer data. Det er her, tingene bliver lidt slørede, fordi antallet af mulige muligheder er for stort. For at indsamle metrics er der Prometheus og andre værktøjer, der kan bruges til at indsamle logfiler flydende, Loke, vektor etc. (for eksempel ClickHouse med vores bjælkehus til K8'ere - ca. oversættelse), for distribueret sporing er der Jaeger og så videre. Hvert servicenet understøtter muligvis nogle værktøjer og ikke andre. Det bliver spændende at se, om projektet kan Åbn Telemetri give en vis konvergens.

I dette tilfælde er fordelen ved service mesh-teknologi, at sidevognscontainere i princippet kan indsamle alle ovenstående data fra deres tjenester. Du har med andre ord et enkelt telemetriopsamlingssystem til din rådighed, og servicenettet kan behandle alle disse oplysninger på forskellige måder. For eksempel:

hale logs fra en bestemt tjeneste i CLI;
overvåge mængden af anmodninger fra service mesh-dashboardet;
indsamle distribuerede spor og videresende dem til et system som Jaeger.

Opmærksomhed, subjektiv bedømmelse: Generelt er telemetri et område, hvor stærk interferens fra servicenettet er uønsket. Det er fint at indsamle grundlæggende information og spore nogle gyldne metrics, som f.eks. anmodningssuccesrate og latens, men lad os håbe, at vi ikke ser Frankenstein-stacke dukke op, som forsøger at erstatte specialiserede systemer, hvoraf nogle allerede har bevist sig selv og godt undersøgt. .

15. Revision

TL;DR: De, der glemmer historiens lærdomme, er dømt til at gentage dem.

Auditering er kunsten at observere vigtige begivenheder i et system. I tilfælde af et servicemesh kan dette betyde sporing af, hvem der har fremsat anmodninger til specifikke slutpunkter for specifikke tjenester, eller hvor mange gange en sikkerhedsrelateret hændelse fandt sted i den sidste måned.

Det er klart, at revision er meget tæt forbundet med telemetri. Forskellen er, at telemetri normalt forbindes med ting som produktivitet og teknisk integritet, mens revision kan relatere til juridiske og andre forhold, der rækker ud over den strengt tekniske sfære (for eksempel overholdelse af GDPR - EU's generelle forordning om databeskyttelse).

16. Visualisering

TL;DR: Længe leve React.js - en uudtømmelig kilde til smarte grænseflader.

Der er måske et bedre udtryk, men jeg kender det ikke. Jeg mener simpelthen en grafisk repræsentation af et servicenet eller nogle af dets komponenter. Disse visualiseringer kan omfatte indikatorer som gennemsnitlige latenser, sidevognskonfigurationsoplysninger, sundhedstjekresultater og advarsler.

At arbejde i et serviceorienteret miljø involverer en meget højere kognitiv belastning sammenlignet med Hans Majestæt Monolitten. Derfor bør det kognitive pres reduceres for enhver pris. En simpel grafisk grænseflade til et servicenet med mulighed for at klikke på en knap og få det ønskede resultat kan være afgørende for væksten i populariteten af denne teknologi.

Var ikke med på listen

Jeg havde oprindelig til hensigt at inkludere et par flere use cases på listen, men besluttede så at lade være. Her er de, sammen med årsagerne til min beslutning:

Multi-datacenter. Efter min mening er dette ikke så meget et use case som et snævert og specifikt anvendelsesområde for servicemasker eller et sæt funktioner som service discovery.
Indgang og udgang. Dette er et beslægtet område, men jeg har begrænset mig (måske kunstigt) til "øst-vest trafik"-brugssagen. Indgang og udgang fortjener en separat artikel.

Konklusion

Det er alt for nu! Igen er denne liste meget vilkårlig og højst sandsynligt ufuldstændig. Hvis du mener, at jeg er gået glip af noget eller har fejlet noget, så kontakt mig venligst på Twitter (@luckerkins). Respekter venligst reglerne for anstændighed.

PS fra oversætteren

Titelillustrationen til artiklen er baseret på et billede fra artiklen "Hvad er et Service Mesh (og hvornår skal man bruge et)?"(af Gregory MacKinnon). Det viser, hvordan noget funktionalitet fra applikationer (i grønt) er flyttet til et servicenet, der giver sammenkoblinger mellem dem (i blåt).

Læs også på vores blog:

Kilde: www.habr.com