Bem. overs.: forfatteren af denne artikel (Luc Perkins) — udvikleradvokat i organisationen CNCF, der er hjemsted for Open Source-projekter som Linkerd, SMI (Service Mesh Interface) og Kuma (for øvrigt, har du også overvejet, hvorfor Istio ikke er på denne liste?..). I endnu et forsøg på at bringe en bedre forståelse af det trendy hype kaldet 'service mesh' til DevOps-fællesskabet, nævner han 16 karakteristiske funktioner, som sådanne løsninger tilbyder.
I dag — et af de varmeste emner inden for softwareudvikling (og med rette!). Jeg finder denne teknologi utroligt lovende og drømmer om at være vidne til dens udbredelse (naturligvis når det giver mening). Ikke desto mindre er den stadig omgivet af en aura af mystik for de fleste mennesker. Selv dem, der er godt bekendt med den, har ofte svært ved at formulere dens fordele og hvad den egentlig indebærer (inklusive mig selv). I denne artikel vil jeg forsøge at ændre på dette ved at opremse forskellige brugsituationer for 'service mesh'*.
* Bemærk: her og i det følgende vil oversættelsen 'service mesh' anvendes for den stadig nye term service mesh.
Men først vil jeg gerne komme med et par bemærkninger:
- Jeg har aldrig arbejdet med service meshes og har ikke brugt dem uden for projekter, der blev startet for min egen uddannelse. På den anden side, var det mig, der skrev en masse dokumentation for den interne service mesh i Twitter i 2015 (på det tidspunkt blev det ikke engang kaldt 'service mesh') og deltager i udviklingen af hjemmesiden og dokumentationen for , så det betyder da noget.
- Min liste er vejledende og ufuldstændig. Det er helt muligt, at der findes brugsituationer, jeg ikke kender til, og med tiden vil der sikkert opstå nye muligheder, i takt med at teknologien udvikler sig og dens popularitet vokser.
- Samtidig understøtter langt fra alle eksisterende implementationer af service mesh alle de nævnte brugsituationer. Derfor bør mine udsagn som 'service mesh kan...' læses som 'nogle, og muligvis alle, populære implementationer af service mesh kan...'.
- Rækkefølgen af eksemplerne har ikke nogen betydning.
Kort liste:
- serviceopdagelse;
- kryptering;
- autentificering og autorisering;
- belastningsbalancering;
- circuit breaking;
- automatisering af skalering;
- kanariske implementeringer;
- blågrønne implementeringer;
- sundhedstjek;
- load shedding;
- trafikspejling;
- isolation;
- begrænsning af forespørgsler, genforsøg og timeouts;
- telemetri;
- revision;
- visualisering.
1. Opdagelse af tjenester
TL;DR: Tilslut dig andre tjenester i netværket med enkle navne.
Tjenester skal kunne "finde" hinanden automatisk med meningsfulde navne – for eksempel, service.api.production, pets/staging eller cockroach. Cloud-miljøer adskiller sig ved deres elasticitet, og bag ét navn kan der gemme sig mange instanser af en tjeneste. Det er tydeligt, at det i en sådan situation er fysisk umuligt at hardkode alle IP-adresser.
Desuden, når en tjeneste finder en anden, skal den kunne sende forespørgsler til denne tjeneste uden at frygte, at de ender ved en inaktiv instans. Med andre ord skal service mesh overvåge tilgængeligheden af alle instanser af tjenester og holde en liste over værter så aktuel som muligt.
Hver service mesh implementerer sin egen metode til serviceopdagelse. I øjeblikket er den mest udbredte metode at delegere til eksterne processer som Kubernetes DNS. Tidligere brugte vi i Twitter et navngivningssystem . Derudover muliggør teknologien service mesh fremkomsten af brugerdefinerede navngivningsmekanismer (selvom jeg endnu ikke har set nogen implementering af SM med en sådan funktionalitet).
2. Kryptografi
TL;DR: Fjern ukrypteret trafik mellem tjenester, og lad denne proces være automatiseret og skalerbar.
Det er rart at vide, at ondsindede aktører ikke kan trænge ind i dit interne netværk. Firewall fungerer glimrende til dette formål. Men hvad sker der, hvis en hacker alligevel får adgang? Kan de gøre hvad som helst med den interne tjenestetrafik? Lad os håbe, det ikke sker. For at forhindre et sådant scenarie skal der implementeres et netværk med nul tillid (zero-trust), hvor al trafik mellem tjenester er krypteret. De fleste moderne service-meshes opnår dette gennem gensidig (mutual TLS, mTLS). I nogle tilfælde fungerer mTLS i hele skyer og klustre (jeg tror, interplanetarisk kommunikation en dag vil være organiseret på samme måde).
Selvfølgelig er mTLS service mesh ikke obligatoriskHver tjeneste kan selv sørge for sin egen TLS, men det betyder, at man skal finde en måde at generere certifikater på, distribuere dem til tjenestens værter, inkludere kode i applikationen, der vil indlæse disse certifikater fra filer. Og glem ikke at opdatere disse certifikater med jævne mellemrum. Tjenestenetværk automatiserer mTLS ved hjælp af systemer som , som i øvrigt automatiserer processen med at udstede og rotere certifikater.
3. Authentication og autorisering
TL;DR: Bestem, hvem der er initiativtageren til anmodningen, og fastlæg, hvad de har tilladelse til at gøre, før anmodningen når tjenesten.
Tjenester ønsker ofte at vide, hvem hvem der udfører anmodningen (autentikation), og ved hjælp af denne information afgør, hvad hvad denne enhed har tilladelse til at gøre (autorisation). I dette tilfælde kan stedet for pronomenet „hvem“ dække over:
- Andre tjenester. Dette kaldes „peer-autentifikation“. For eksempel ønsker tjenestenat få adgang til tjenesten
web. Tjenestenetværk løser normalt sådanne problemer via mTLS: certifikater fungerer her som den nødvendige identifikation.dbNogle brugere - mennesker. Dette kaldes „anmodningsautentifikation“. For eksempel ønsker brugeren - haxor69 at købe en ny lampe. Tjenestenetværk tilbyder forskellige mekanismer, såsomJSON Web Tokens.
Mange af os har gjort dette i applikationskoden. En anmodning kommer ind, vi ser i tabellen, finder brugeren og sammenligner adgangskoden, derefter kontrollerer vi kolonnen .Når vi har fastlagt, hvor anmodningen kommer fra, skal vi bestemme, hvad denne enhed har tilladelse til at gøre. Nogle service mesh’er tillader, at grundlæggende politikker (om hvem og hvad der kan gøres) defineres i YAML-filer eller i kommandolinjen, mens andre tilbyder integration med frameworks som
brugere. Det endelige mål er at få dine tjenester til at acceptere enhver anmodning, og trygt antage, at de kommer fra en pålidelig kilde,permissionsog at handlingen er tilladt.
4. Load balancing TL;DR: Fordel belastningen over instanserne af tjenesten efter et bestemt mønster. og действие это разрешено.
4. Балансировка нагрузки
TL;DR: Распределяйте нагрузку по экземплярам сервиса по определенному шаблону.
En "service" i en service-sekt kan ofte bestå af mange identiske instanser. For eksempel består servicen i dag af 5 kopier, cache men i morgen kan antallet stige til 11. Forespørgsler, der sendes til cache, skal distribueres i henhold til et bestemt mål. For eksempel at minimere forsinkelsen eller maksimere sandsynligheden for at ramme en fungerende instans. Algoritmen round-robin bruges oftest, men der findes mange andre — for eksempel vægtede (weighted) forespørgsler (hvor man kan vælge præfererede mål), ring (ring) hashing (brug af konsekvent hashing til upstream-værter) eller metoden med færrest forespørgsler (hvor præference gives til instansen med færrest forespørgsler).
Klassiske load balancere har også andre funktioner, såsom HTTP caching og beskyttelse mod DDoS, men de er ikke relevante for east-west trafik (dvs. trafik, der flyder inden for datacentret ― bem. red.) (typisk anvendelsesområde for service mesh). Selvfølgelig er det ikke nødvendigt at bruge service mesh til load balancing, men det giver mulighed for at definere og kontrollere balancepolitikker for hver service fra et centralt kontrolplan, hvilket fjerner behovet for at køre og konfigurere separate load balancere i netværksstakken.
5. Circuit Breaking
TL;DR: Stop trafikken til den problematiske service og kontroller skaden i værste scenarier.
Hvis en service af en eller anden grund ikke kan håndtere trafikken, giver service mesh flere muligheder for at løse problemet (andre muligheder vil blive beskrevet i de relevante afsnit). Circuit breaking er den mest strenge metode til at frakoble servicen fra trafikken. Men det giver ikke mening i sig selv — der skal være en backup plan. Der kan være backpressure () på de tjenester, der håndterer forespørgsler (bare husk at konfigurere din service mesh til dette!), eller for eksempel kan status-siden farves rød og brugerne omdirigeres til en alternativ side med en "nedbrudt hval" ("Twitter is down").
Service mesh tillader ikke kun at definere, hvornår der vil blive frakoblet og hvad Dette efterfølges. I dette tilfælde kan "når" inkludere enhver kombination af de angivne parametre: det samlede antal anmodninger over en given periode, antal parallelle forbindelser, pending-anmodninger, aktive genforsøg osv.
Du vil næppe ønske at misbruge circuit breaking, men det er rart at vide, at der er en backupplan i en nødsituation.
6. Autoskalering
TL;DR: Øg eller reducer antallet af serviceinstanser afhængigt af de angivne kriterier.
Service mesh'er er ikke planlæggere, så de udfører ikke skalering automatisk. Men de kan levere information, som planlæggere kan træffe beslutninger ud fra. Da service mesh'er har adgang til al trafik mellem tjenesterne, besidder de omfattende oplysninger om, hvad der sker: hvilke tjenester der oplever problemer, hvilke der næsten ikke er belastet (ressourcerne bruges unødigt) osv.
For eksempel skalerer Kubernetes tjenester baseret på brugen af CPU og hukommelse af pods (se vores rapport "" - red.)", men hvis du beslutter at foretage skalering baseret på en hvilken som helst anden måling (i vores tilfælde relateret til trafik), vil der være behov for en særlig metrik. Vejledningen viser, hvordan man gør dette ved hjælp af , og , men selve processen er ret kompliceret. Vi ville ønske, at service mesh kunne forenkle det ved blot at lade os definere betingelser som "øge antallet af serviceinstanser auth, hvis antallet af anmodninger, der venter på at blive udført, overstiger tærskelværdien i et minut".
7. Canary-udrulninger
TL;DR: Test nye funktioner eller versioner af tjenesten på et delmængde af brugerne.
Lad os sige, at du udvikler et SaaS-produkt og planlægger at lancere en ny, fantastisk version. Du har testet den i staging, og den har kørt fremragende. Men der er alligevel visse bekymringer om dens adfærd under reale forhold. Med andre ord er det nødvendigt at teste den nye version med rigtige opgaver, uden at risikere brugernes tillid. Canary-udrulninger er perfekte til dette. De giver mulighed for at vise den nye funktion til en bestemt undergruppe af brugere. Denne undergruppe kan bestå af de mest loyale brugere, dem der arbejder med gratisversionen af produktet, eller brugere, der har udtrykt ønsker om at være
Service meshes realiserer dette ved at angive kriterier for, hvem der skal se hvilken version af applikationen, og rute trafikken i overensstemmelse hermed. For selve tjenesterne ændrer der sig dog ikke noget. Version 1.0 af tjenesten mener, at alle anmodninger kommer fra brugere, der netop skal se den, mens version 1.1 har det samme syn på sine brugere. I mellemtiden kan du ændre procentdelen af trafikken mellem den gamle og den nye version ved at omdirigere et stigende antal brugere til den nye, hvis den fungerer stabilt og dine
8. Blå-grønne udrulninger
TL;DR: Udrul den nye, fantastiske funktion, men vær klar til straks at rulle alt tilbage.
Formålet er at rulle den nye "blå" tjeneste ud ved at starte den parallelt med den gamle, "grønne". Hvis alt går glat, og den nye tjeneste klarer sig godt, kan den gamle langsomt blive deaktiveret. (Desværre vil denne nye "blå" tjeneste en dag også få samme skæbne som den "grønne" og forsvinde...) Blå-grønne udrulninger adskiller sig fra kanariske ved, at den nye funktion dækker alle brugere (i modsætning til en del); meningen her er at have en "backup-havn" klar, hvis noget går galt.
Service mesh tilbyder en meget bekvem måde at teste den "blå" service på og hurtigt skifte til den fungerende "grønne" i tilfælde af problemer. Ikke at nævne, at de samtidig giver en masse information (se punktet "Telemetri" nedenfor) om arbejdet med den "blå", som hjælper med at forstå, om den er klar til fuld udnyttelse.
Bem. overs.: Læs mere om forskellige implementeringsstrategier i Kubernetes (inklusive de nævnte canary, blue/green og andre) i .
9. Sundhedstjek
TL;DR: Hold øje med, hvilke instanser af tjenester der fungerer, og reager på dem, som ikke længere gør.
Sundhedstjek (health check) hjælper med at afgøre, om instanserne af tjenesten er klar til at modtage og behandle trafik. For eksempel kan et sundhedstjek for HTTP-tjenester se ud som en GET-anmodning til en endpoint /health. Svar 200 OK vil betyde, at instansen er sund, enhver anden respons vil betyde, at den ikke er klar til at modtage trafik. Service mesh giver mulighed for at specificere både metoden til at kontrollere driftsikkerheden og den frekvens, hvormed disse tjek udføres. Denne information kan derefter bruges til andre formål - f.eks. til belastningsbalancering og circuit breaking.
Dermed er sundhedstjek ikke et selvstændigt brugsområde, men anvendes som regel for at opnå andre mål. Afhængigt af resultaterne af health checks kan der være behov for eksterne (i forhold til andre mål for service meshes) handlinger: for eksempel at opdatere en status-side, oprette en issue på GitHub eller udfylde en JIRA-ticket. Og service mesh tilbyder en bekvem mekanisme til at automatisere det hele.
10. Lastnedkastning (load shedding)
TL;DR: Omfordel trafikken som respons på en midlertidig stigning i brugen.
Hvis en tjeneste bliver overbelastet med trafik, kan du midlertidigt omdirigere noget af denne trafik til et andet sted (dvs. "afgive", "omdirigere" (shed) den derhen). For eksempel til en reserve-tjeneste eller datacenter, eller til den vedholdende Emne. Som et resultat vil tjenesten fortsætte med at behandle en del af forespørgslerne i stedet for at falde helt sammen og stoppe med at behandle alle. At afbryde belastningen er at foretrække frem for at bryde kæden, men det er stadig uønsket at misbruge det. Det hjælper med at forhindre kaskadefejl, som får downstream-tjenester til at bryde sammen.
11. Parallelisering/kloning af trafik
TL;DR: Send én anmodning til flere steder samtidig.
Nogle gange er der behov for at sende en anmodning (eller et udvalg af anmodninger) til flere tjenester samtidig. Et typisk eksempel er at sende en del af produktions-trafikken til staging-tjenesten. Den primære webserver i produktionen sender en anmodning til den underliggende tjeneste products.production og kun til den. Og service mesh kopierer intelligent denne anmodning og sender den videre til products.staging, noget som webserveren slet ikke er klar over.
Endnu et relateret anvendelsesscenarie for service mesh, som kan implementeres oven på parallelisering af trafik, er . Det indebærer at sende de samme anmodninger til forskellige versioner af tjenesten og undersøge, om alle versioner opfører sig ens. Jeg har endnu ikke set en implementering af service mesh med et integreret system til regressionstest som , men selve ideen virker lovende.
12. Isolation
TL;DR: Opdel din service mesh i mini-netværk.
Også kendt som segmentering, er isolation kunsten at dele service mesh op i logisk adskilte segmenter, der intet ved om hinanden. Isolation minder lidt om at skabe virtuelle private netværk. Den grundlæggende forskel er, at du stadig kan drage fordel af alle fordelene ved service mesh (som f.eks. serviceopdagelse), men med øget sikkerhed. For eksempel, hvis en angriber formår at trænge ind i en tjeneste i en af undernetværkene, kan han ikke se, hvilke tjenester der kører i de andre undernetværk, eller opfange deres trafik.
Desuden kan fordelene også være organisatoriske. Det kan være, at du ønsker at opdele tjenesterne i undernetværk afhængigt af virksomhedens struktur og frigøre udviklerne fra den kognitive byrde, der følger med at skulle holde hele service mesh i tankerne.
13. Behandlingshastighedsbegrænsning, gentagelser og tidsgrænser
TL;DR: Du skal ikke længere inkludere presserende opgaver for håndtering af anmodninger i kodebasen.
Alle disse ting kunne betragtes som separate brugssager, men jeg har valgt at samle dem, fordi de deler en fælles egenskab: de overtager opgaverne vedrørende livscyklussen for anmodninger, som normalt håndteres af applikationsbiblioteker. Hvis du udvikler en webserver i Ruby on Rails (ikke integreret med service mesh), der foretager anmodninger til backend-tjenester gennem , skal applikationen selv beslutte, hvad den skal gøre, hvis N anmodninger mislykkes. Det er også nødvendigt at finde ud af, hvor meget trafik disse tjenester kan håndtere, og 'hardcode' disse parametre ved hjælp af et specifikt bibliotek. Derudover skal applikationen beslutte, hvornår det er tid til at give op og lade anmodningen udløbe (ved timeout). For at ændre nogen af de nævnte parametre skal webserveren stoppes, omkonfigureres og genstartes.
At overføre disse opgaver til service mesh betyder ikke kun, at udviklerne af tjenesterne ikke længere skal tænke på dem, men også at de kan betragtes mere globalt. Hvis der bruges en kompleks kæde af tjenester, for eksempel A → B → C → D → E, skal hele livscyklussen for anmodningen overvejes. Hvis målet er at forlænge timeouts i tjeneste C, giver det mening at gøre dette hele vejen igennem i stedet for at gøre det delvist: ved at opdatere koden for tjenesten og vente på, at pull requesten bliver accepteret og CI-systemet deployer den opdaterede tjeneste.
14. Telemetri
TL;DR: Indsaml al nødvendig (og ikke helt nødvendig) information fra tjenester.
Telemetri er et overordnet begreb, der omfatter metrikker, distribueret sporingsdata og logs. Service mesh tilbyder mekanismer til at indsamle og behandle alle tre typer data. Her bliver det lidt uklart, da antallet af mulige varianter er for stort. Til indsamling af metrikker findes der og andre værktøjer, til indsamling af logs kan man bruge , , og andre. (for eksempel ClickHouse med vores til K8s — bemærk fra oversætteren), til distribueret sporingsdata findes der osv. Hver service mesh kan understøtte nogle værktøjer og ikke andre. Det vil være interessant at se, om projektet kan sikre en vis konvergens.
I dette tilfælde er fordelen ved service mesh-teknologi, at sidecar-containere i princippet kan indsamle alle de nævnte data fra deres tjenester. Med andre ord får du et samlet system til indsamling af telemetri, og service mesh kan behandle alle disse oplysninger på forskellige måder. For eksempel:
- at tail'e logs fra en given tjeneste i CLI;
- at overvåge antallet af anmodninger fra service mesh's overvågningspanel;
- at indsamle distribuerede spor og sende dem til et system som Jaeger.
Opmærksomhed, subjektiv vurdering: Generelt set er telemetri det område, hvor en stærk indblanding fra service mesh er uønsket. At samle grundlæggende oplysninger og overvåge nogle 'guldmetrics' som procentdelen af succesfulde anmodninger og forsinkelser er acceptabelt, men lad os håbe, at vi ikke bliver vidner til opkomsten af sådanne Frankenstein-stakke, der prøver at erstatte specialiserede systemer, hvoraf nogle allerede har bevist deres værdi og er godt dokumenterede.
15. Revision
TL;DR: Den, der glemmer historiske lektioner, er dømt til at gentage dem.
Revision er kunsten at observere vigtige hændelser i systemet. I tilfælde af service mesh kan det betyde at spore, hvem der har gjort anmodninger til bestemte endpoints for specifikke tjenester, eller hvor mange gange et bestemt sikkerhedsrelateret event er sket den seneste måned.
Det er klart, at revision er meget tæt forbundet med telemetri. Forskellen er dog, at telemetri normalt associeres med ting som ydeevne og teknisk robusthed, mens revision kan vedrøre juridiske og andre spørgsmål, der går ud over den strengt tekniske sfære (for eksempel overholdelse af GDPR – Den generelle databeskyttelsesforordning i EU).
16. Visualisering
TL;DR: Leve React.js – en uendelig kilde til fantastiske grænseflader.
Måske er der en mere passende term, men jeg kender den ikke. Jeg mener bare den grafiske repræsentation af service mesh eller dens enkelte komponenter. Disse visualiseringer kan inkludere indikatorer som gennemsnitlige forsinkelser, oplysninger om konfigurationen af sidecar-containere, resultater fra sundhedstjek og alarmer.
At arbejde i en serviceorienteret miljø er forbundet med en betydeligt større kognitiv belastning sammenlignet med Hans Majestæt Monolitten. Derfor bør den kognitive belastning reduceres for enhver pris. Et banalt grafisk interface til service mesh, hvor man kan klikke på en knap for at få det ønskede resultat, kan være afgørende for denne technologies vækst i popularitet.
Ikke inkluderet på listen
Oprindeligt havde jeg til hensigt at inkludere et par ekstra brugsscenarier på listen, men besluttede derefter at lade være. Her er de sammen med årsagerne til min beslutning:
- Multi-datacenter. Efter min mening er dette ikke så meget et brugsscenario, men et snævert og specifikt anvendelsesområde for service mesh eller et bestemt sæt funktioner som serviceopdagelse.
- Ingress og egress. Dette er et relateret område, men jeg har begrænset mig (måske kunstigt) til brugsscenariet "Øst-vest trafik". Ingress og egress fortjener en særskilt artikel.
Konklusion
Det var alt for nu! Igen, denne liste er meget betinget og sandsynligvis ikke fuldstændig. Hvis du mener, at jeg har overset noget eller lavet en fejl, er du velkommen til at kontakte mig på Twitter (). Venligst overhold gode manerer.
P.S. fra oversætteren
Som grundlag for hovedillustrationen til artiklen er et billede fra artiklen "" (forfatter — Gregory MacKinnon) blevet brugt. Det viser, hvordan en del af funktionaliteten fra applikationerne (grøn farve) er overgået til service mesh, som sørger for forbindelserne imellem dem (blå farve).
Læs også på vores blog:
- «»;
- «»;
- «».
Kilde: habr.com
