Merk. overs.: Forfatteren av denne artikkelen (Luc Perkins) er en utvikleradvokat ved CNCF-organisasjonen, som er hjemsted for slike Open Source-prosjekter som Linkerd, SMI (Service Mesh Interface) og Kuma (har du forresten også lurt på hvorfor Istio er ikke på denne listen? .). Nok en gang prøver han å gi DevOps-fellesskapet en bedre forståelse av den trendy hypen kalt «service mesh», og lister opp 16 karakteristiske funksjoner som slike løsninger gir.
I dag ― et av de heteste emnene innen programvareteknikk (og med rette!). Jeg synes denne teknologien er utrolig lovende og vil gjerne se den tatt i bruk (når det er fornuftig, selvfølgelig). Imidlertid er det fortsatt omgitt av en aura av mystikk for de fleste. Samtidig kan også de som Velkjente med det er det ofte vanskelig å formulere fordelene og nøyaktig hva det er (inkludert yours truly). I denne artikkelen vil jeg prøve å rette opp situasjonen ved å liste opp ulike brukssaker "servicemasker"*.
* Merk overs.: her og videre i artikkelen vil nøyaktig denne oversettelsen (“service mesh”) brukes for det fortsatt nye begrepet service mesh.
Men først vil jeg komme med noen kommentarer:
- Jeg har aldri jobbet med servicemasker eller brukt dem utenom prosjekter startet for min egen utdanning. På den annen side var det jeg som skrev en haug med dokumentasjon for Twitters interne service mesh i 2015 (det ble ikke engang kalt "service mesh" da) og deltok i utviklingen av nettsiden og dokumentasjonen for , så det betyr noe.
- Listen min er omtrentlig og ufullstendig. Det kan godt være brukstilfeller som er ukjente for meg, og nye alternativer vil sannsynligvis oppstå over tid etter hvert som teknologien utvikler seg og dens popularitet vokser.
- Samtidig støtter ikke alle eksisterende servicemesh-implementeringer alle de oppførte brukstilfellene. Derfor bør mine uttalelser som "service mesh kan ..." leses som "individuelle, og kanskje alle populære service mesh-implementeringer kan ...".
- Rekkefølgen på eksemplene gjør ingen forskjell.
Kort liste:
- tjeneste oppdagelse;
- kryptering;
- autentisering og autorisasjon;
- lastbalansering;
- kretsbrudd;
- autoskalering;
- utplasseringer av kanarifugler;
- blågrønne utplasseringer;
- helsesjekk;
- belastningsreduksjon;
- trafikkspeiling;
- isolasjon;
- begrensning av frekvens, gjenforsøk og tidsavbrudd;
- telemetri;
- revidere;
- visualisering.
1. Tjenesteoppdagelse
TL;DR: Koble til andre tjenester på nettverket med enkle navn.
Tjenester skal kunne "finne" hverandre automatisk ved å bruke passende navn - for eksempel, service.api.production, pets/staging eller cassandra. Skymiljøer er elastiske, og et enkelt navn kan skjule mange forekomster av en tjeneste. Det er klart at i en slik situasjon er det fysisk umulig å hardkode alle IP-adresser.
I tillegg, når en tjeneste finner en annen, bør den kunne sende forespørsler til den tjenesten uten frykt for at de vil ende opp ved inngangen til den ødelagte forekomsten. Med andre ord må tjenestenettverket overvåke helsen til alle tjenesteinstanser og holde listen over verter så oppdatert som mulig.
Hvert tjenestenettverk implementerer tjenesteoppdagelsesmekanismen annerledes. For øyeblikket er den vanligste måten å delegere til eksterne prosesser som Kubernetes DNS. Tidligere på Twitter brukte vi et navnesystem til dette formålet . I tillegg gjør service mesh-teknologi det mulig for egendefinerte navnemekanismer å dukke opp (selv om jeg ennå ikke har sett noen SM-implementering med slik funksjonalitet).
2. Kryptering
TL;DR: Bli kvitt ukryptert trafikk mellom tjenester og gjør denne prosessen automatisert og skalerbar.
Det er hyggelig å vite at angripere ikke kan trenge inn i det interne nettverket ditt. Brannmurer gjør en god jobb med dette. Men hva skjer hvis en hacker kommer inn? Vil han kunne gjøre hva han vil med intern trafikk? La oss håpe at dette ikke skjer likevel. For å forhindre dette scenariet bør du implementere et zero-trust-nettverk der all trafikk mellom tjenester er kryptert. De fleste moderne servicenett oppnår dette gjennom gjensidig (gjensidig TLS, mTLS). I noen tilfeller fungerer mTLS i hele skyer og klynger (jeg tror interplanetarisk kommunikasjon en dag vil bli arrangert på samme måte).
Selvfølgelig for mTLS service mesh valgfri. Hver tjeneste kan ta seg av sin egen TLS, men dette betyr at du må finne en måte å generere sertifikater på, distribuere dem på tvers av tjenesteverter og inkludere kode i applikasjonen som skal laste disse sertifikatene fra filer. Ja, ikke glem å fornye disse sertifikatene med jevne mellomrom. Tjenestenettverk automatiserer mTLS med systemer som , som igjen automatiserer prosessen med å utstede og rotere sertifikater.
3. Autentisering og autorisasjon
TL;DR: Fastslå hvem som er rekvirenten og definer hva de har lov til å gjøre før forespørselen i det hele tatt når tjenesten.
Tjenester ønsker ofte å vite som utfører forespørselen (autentisering), og ved hjelp av denne informasjonen bestemmer at en gitt enhet har lov til å gjøre (autorisasjon). I dette tilfellet kan pronomenet "hvem" skjule:
- Andre tjenester. Dette kalles "autentisering" likemann" For eksempel service
webønsker å få tilgang til tjenestendb. Tjenestenett løser vanligvis slike problemer ved å bruke mTLS: sertifikater fungerer i dette tilfellet som den nødvendige identifikatoren. - Noen menneskelige brukere. Dette kalles "autentisering" be om" For eksempel bruker
haxor69ønsker å kjøpe ny lampe. Tjenestenett gir ulike mekanismer, f.eks. .Mange av oss har gjort dette i applikasjonskode. En forespørsel kommer inn, vi ser gjennom tabellen
users, finn brukeren og sammenlign passordet, og sjekk deretter kolonnenpermissionsetc. Når det gjelder et servicenettverk, skjer dette før forespørselen i det hele tatt når tjenesten.
Når vi har etablert hvem forespørselen kom fra, må vi finne ut hva denne enheten har lov til å gjøre. Noen tjenestenettverk lar deg angi grunnleggende retningslinjer (om hvem som kan gjøre hva) som YAML-filer eller på kommandolinjen, mens andre tilbyr integrasjon med rammeverk som . Det endelige målet er at tjenestene dine godtar enhver forespørsel, forutsatt at den kommer fra en pålitelig kilde и denne handlingen er tillatt.
4. Lastbalansering
TL;DR: Fordel belastningen på tvers av tjenesteforekomster i henhold til et spesifikt mønster.
En "tjeneste" innenfor en tjenesteseksjon består veldig ofte av mange identiske instanser. For eksempel i dag tjenesten cache består av 5 eksemplarer, og i morgen kan antallet øke til 11. Forespørsler sendes til cache, må fordeles i samsvar med et bestemt formål. For eksempel, minimer latens eller maksimer sannsynligheten for å komme til en fungerende forekomst. Den mest brukte algoritmen er Round-robin, men det er mange andre - for eksempel den vektede metoden (vektet) spørringer (du kan velge foretrukne mål), ring (ringe) hashing (bruker konsistent hashing på tvers av oppstrømsverter) eller minste forespørselsmetode (foretrekket gis til forekomsten med færrest forespørsler).
Klassiske balansere har andre funksjoner, som HTTP-caching og DDoS-beskyttelse, men de er lite relevante for øst-vest-trafikk (det vil si for trafikk som flyter innenfor et datasenter - ca. transl.) (typisk scope of service mesh). Selvfølgelig er det ikke nødvendig å bruke et servicenettverk for lastbalansering, men det lar deg angi og kontrollere balanseringspolicyer for hver tjeneste fra et sentralisert kontrolllag, og dermed eliminere behovet for å kjøre og konfigurere separate lastbalansere i nettverksstakken. .
5. Kretsbrudd
TL;DR: Stopp trafikken til den problematiske tjenesten og kontroller skadene i verste fall.
Hvis tjenesten av en eller annen grunn ikke kan takle trafikken, gir tjenestenettverket flere alternativer for å løse dette problemet (andre vil bli diskutert i de aktuelle avsnittene). Kretsbrudd er det mest alvorlige alternativet for å koble en tjeneste fra trafikk. Men i seg selv gir det ikke mening - en backupplan er nødvendig. Mottrykk kan gis () til tjenester som sender forespørsler (bare ikke glem å konfigurere tjenestenettverket for dette!), eller for eksempel å farge statussiden rød og omdirigere brukere til en annen versjon av siden med en "fallende hval" ("Twitter er ned").
Tjenestenett lar deg ikke bare definere hvor nedleggelse vil følge og at dette vil følge. I dette tilfellet kan "når" inkludere en hvilken som helst kombinasjon av spesifiserte parametere: totalt antall forespørsler for en viss periode, antall parallelle tilkoblinger, ventende forespørsler, aktive gjenforsøk osv.
Du vil sannsynligvis ikke misbruke kretsbrudd, men det er fint å vite at du har en reserveplan i nødstilfeller.
6. Autoskalering
TL;DR: Øk eller reduser antall tjenesteforekomster avhengig av de angitte kriteriene.
Tjenestemasker er ikke planleggere, så det gjør de ikke bære ut skalere deg selv. De kan imidlertid gi informasjon om hvilke planleggere som vil basere sine beslutninger. Siden tjenestemasker har tilgang til all trafikk mellom tjenester, har de omfattende informasjon om hva som skjer: hvilke tjenester som opplever problemer, hvilke tjenester som er svært lett belastet (kapasiteten som er tildelt dem er bortkastet), etc.
For eksempel skalerer Kubernetes tjenester basert på pods CPU og minnebruk (se vår rapport""- ca. oversett.), men hvis du bestemmer deg for å skalere basert på en annen beregning (i vårt tilfelle trafikkrelatert), trenger du en spesiell beregning. Ledelse viser hvordan du gjør dette med , и , men selve prosessen er ganske komplisert. Vi vil at tjenestenettverket skal forenkle dette ved å la oss enkelt sette betingelser som "øke antall tjenesteforekomster auth, hvis antallet ventende forespørsler overskrider terskelen innen et minutt."
7. Kanarie-utplasseringer
TL;DR: Test nye funksjoner eller tjenesteversjoner på en undergruppe av brukere.
La oss si at du utvikler et SaaS-produkt og har tenkt å rulle ut en kul ny versjon av det. Du testet det i iscenesettelse og det fungerte bra. Men det er fortsatt visse bekymringer om oppførselen hennes under reelle forhold. Du må med andre ord teste den nye versjonen på reelle problemer uten å risikere brukertillit. Kanarie-utplasseringer er gode for dette. De lar deg demonstrere en ny funksjon for en undergruppe av brukere. Dette undersettet kan bestå av de mest lojale brukerne eller de som jobber med gratisversjonen av produktet, eller brukere som har uttrykt et ønske om å være «forsøkskaniner».
Tjenestenettverk implementerer dette ved å la deg spesifisere kriterier som bestemmer hvem som skal se hvilken versjon av applikasjonen, og dirigere trafikk deretter. Men ingenting endres for tjenestene selv. Versjon 1.0 av tjenesten mener at alle forespørsler kommer fra brukere som burde se den, og versjon 1.1 mener det samme for sine brukere. I mellomtiden kan du endre prosentandelen av trafikken mellom den gamle og nye versjonen, og omdirigere et økende antall brukere til den nye hvis den fungerer stabilt og "marsvinene" gir klarsignal.
8. Blågrønne utplasseringer
TL;DR: Rull ut en kul ny funksjon, men vær forberedt på å umiddelbart ta alt tilbake.
som betyr er å rulle ut en ny «blå» tjeneste, og lansere den parallelt med den gamle, «grønne». Hvis alt går greit og den nye tjenesten fungerer bra, kan den gamle gradvis deaktiveres. (Akk, en dag vil denne nye "blå" tjenesten gjenta skjebnen til den "grønne" og forsvinne...) Blågrønne utplasseringer skiller seg fra kanarifuglene ved at den nye funksjonen dekker alle på en gang brukere (ikke del); Poenget her er å ha en "trygg havn" klar i tilfelle noe skulle gå galt.
Tjenestenett gir en veldig praktisk måte å teste en "blå" tjeneste og umiddelbart bytte til en fungerende "grønn" i tilfelle problemer. For ikke å nevne det faktum at de underveis gir mye informasjon (se "Telemetri" nedenfor) om arbeidet til den "blå", som hjelper til med å forstå om den er klar for full drift.
Merk. overs.: Du kan lese mer om ulike distribusjonsstrategier i Kubernetes (inkludert den nevnte kanarifuglen, blå/grønn og andre) i .
9. Helsesjekk
TL;DR: Hold styr på hvilke tjenesteforekomster som er funksjonelle og svar på de som ikke lenger er funksjonelle.
Helsesjekk (helsesjekk) hjelper med å avgjøre om tjenesteforekomster er klare til å akseptere og behandle trafikk. For eksempel, når det gjelder HTTP-tjenester, kan en helsesjekk se ut som en GET-forespørsel til endepunktet /health... Svar 200 OK vil bety at instansen er sunn, hvilken som helst annen - at den ikke er klar til å motta trafikk. Tjenestemasker lar deg spesifisere både måten funksjonalitet skal kontrolleres på og hvor ofte denne kontrollen skal utføres. Denne informasjonen kan deretter brukes til andre formål – for eksempel til lastbalansering og kretsbrudd.
Helsesjekking er således ikke en frittstående brukssak, men brukes vanligvis for å oppnå andre mål. Avhengig av resultatene av helsesjekker kan det også være nødvendig med handlinger utenfor andre tjenestenettmål: for eksempel å oppdatere statussiden, opprette et problem på GitHub eller fylle ut en JIRA-billett. Og service mesh tilbyr en praktisk mekanisme for å automatisere alt dette.
10. Belastning
TL;DR: Omdiriger trafikk som svar på en midlertidig økning i bruk.
Hvis en bestemt tjeneste er overbelastet med trafikk, kan du midlertidig omdirigere noe av denne trafikken til et annet sted (det vil si "dump", "overfør" (skur) ham der). For eksempel til en backuptjeneste eller datasenter, eller til en permanent emne. Som et resultat vil tjenesten fortsette å behandle noen forespørsler i stedet for å krasje og slutte å behandle alt helt. Belastning er å foretrekke fremfor å bryte kretsen, men det er fortsatt ikke tilrådelig å misbruke den. Det bidrar til å forhindre overlappende feil som fører til at nedstrømstjenester krasjer.
11. Trafikkparallellisering/speiling
TL;DR: Send én forespørsel til flere steder samtidig.
Noen ganger er det behov for å sende en forespørsel (eller et visst utvalg av forespørsler) til flere tjenester samtidig. Et typisk eksempel er å sende deler av produksjonstrafikken til en iscenesettelsestjeneste. Hovedproduksjonswebserveren sender en forespørsel til nedstrømstjenesten products.production og bare til ham. Og tjenestenettverket kopierer denne forespørselen intelligent og sender den til products.staging, som webserveren ikke en gang er klar over.
En annen relatert servicemesh-brukssak som kan implementeres på toppen av trafikkparallellisering er . Det innebærer å sende de samme forespørslene til ulike versjoner av tjenesten og sjekke om alle versjoner oppfører seg likt. Jeg har ennå ikke kommet over en service mesh-implementering med et integrert regresjonstestsystem som , men selve ideen virker lovende.
12. Isolasjon
TL;DR: Bryt opp tjenestenettverket ditt i mininettverk.
Også kjent som segmenteringIsolasjon er kunsten å dele et tjenestenett i logisk distinkte segmenter som ikke vet noe om hverandre. Isolasjon er litt som å lage virtuelle private nettverk. Den grunnleggende forskjellen er at du fortsatt kan nyte alle fordelene med et tjenestenettverk (som tjenesteoppdagelse), men med ekstra sikkerhet. For eksempel, hvis en angriper er i stand til å penetrere en tjeneste på ett undernett, vil han ikke kunne se hvilke tjenester som kjører på andre undernett eller avskjære trafikken deres.
I tillegg kan fordelene også være organisatoriske. Det kan være lurt å subnette tjenestene dine basert på bedriftens struktur og avlaste utviklere for den kognitive belastningen ved å ha hele tjenestenettverket i tankene.
13. Be om hastighetsbegrensning, nye forsøk og tidsavbrudd
TL;DR: Du trenger ikke lenger å inkludere de grove forespørselsadministrasjonsoppgavene i kodebasen din.
Alle disse tingene kan betraktes som separate brukstilfeller, men jeg bestemte meg for å kombinere dem på grunn av en felles funksjon: de overtar oppgavene for livssyklusadministrasjon av forespørselen som vanligvis håndteres av applikasjonsbiblioteker. Hvis du utvikler en webserver i Ruby on Rails (ikke integrert med et servicemesh) som sender forespørsler til backend-tjenester via , vil applikasjonen måtte bestemme hva som skal gjøres hvis N forespørsler mislykkes. Du må også finne ut hvor mye trafikk disse tjenestene vil være i stand til å behandle og hardkode disse parameterne ved hjelp av et spesielt bibliotek. I tillegg må applikasjonen bestemme når det er på tide å gi opp og la forespørselen gå ut (basert på tidsavbrudd). Og for å endre noen av parameterne ovenfor, må webserveren stoppes, rekonfigureres og startes på nytt.
Å overføre disse oppgavene til et tjenestenett betyr ikke bare at tjenesteutviklere ikke trenger å tenke på dem, men også at de kan sees på en mer global måte. Hvis en kompleks kjede av tjenester brukes, for eksempel A -> B -> C -> D -> E, må hele livssyklusen til forespørselen tas i betraktning. Hvis oppgaven er å forlenge tidsavbrudd i tjeneste C, er det logisk å gjøre dette på en gang, og ikke i deler: ved å oppdatere tjenestekoden og vente til pull-forespørselen er akseptert og CI-systemet distribuerer den oppdaterte tjenesten.
14. Telemetri
TL;DR: Samle inn all nødvendig (og ikke helt) informasjon fra tjenester.
Telemetri er et generelt begrep som inkluderer beregninger, distribuert sporing og logger. Tjenestenett tilbyr mekanismer for innsamling og behandling av alle tre typer data. Det er her ting blir litt uklare fordi antallet mulige alternativer er for stort. For å samle beregninger er det og andre verktøy som kan brukes til å samle logger , , etc. (for eksempel ClickHouse med vår for K8s - ca. oversett.), for distribuert sporing er det og så videre. Hvert servicenettverk kan støtte noen verktøy og ikke andre. Det blir spennende å se om prosjektet kan gi en viss konvergens.
I dette tilfellet er fordelen med service mesh-teknologi at sidevognscontainere i prinsippet kan samle alle de ovennevnte dataene fra deres tjenester. Du har med andre ord et enkelt telemetriinnsamlingssystem til rådighet, og tjenestenettverket kan behandle all denne informasjonen på ulike måter. For eksempel:
- hale logger fra en bestemt tjeneste i CLI;
- overvåke volumet av forespørsler fra service mesh-dashbordet;
- samle distribuerte spor og videresende dem til et system som Jaeger.
Oppmerksomhet, subjektiv vurdering: Generelt sett er telemetri et område der sterk interferens fra tjenestenettverket er uønsket. Det er greit å samle grunnleggende informasjon og spore noen gyldne beregninger som suksessrate for forespørsel og ventetid, men la oss håpe vi ikke ser Frankenstein-stabler dukke opp som prøver å erstatte spesialiserte systemer, hvorav noen allerede har bevist seg selv og godt studert .
15. Revisjon
TL;DR: De som glemmer historiens lærdom er dømt til å gjenta dem.
Revisjon er kunsten å observere viktige hendelser i et system. Når det gjelder et tjenestenettverk, kan dette bety sporing av hvem som har sendt forespørsler til spesifikke endepunkter for spesifikke tjenester, eller hvor mange ganger en sikkerhetsrelatert hendelse har skjedd den siste måneden.
Det er klart at revisjon er veldig nært knyttet til telemetri. Forskjellen er at telemetri vanligvis forbindes med ting som produktivitet og teknisk integritet, mens revisjon kan forholde seg til juridiske og andre problemstillinger som går utover den strengt tekniske sfæren (for eksempel overholdelse av GDPR – EUs generelle forordning om databeskyttelse).
16. Visualisering
TL;DR: Lenge leve React.js - en uuttømmelig kilde til fancy grensesnitt.
Det finnes kanskje et bedre begrep, men jeg vet det ikke. Jeg mener ganske enkelt en grafisk representasjon av et tjenestenettverk eller noen av dets komponenter. Disse visualiseringene kan inkludere indikatorer som gjennomsnittlig ventetid, sidevognkonfigurasjonsinformasjon, helsesjekkresultater og varsler.
Å jobbe i et serviceorientert miljø innebærer en mye høyere kognitiv belastning sammenlignet med Hans Majestet Monolitten. Derfor bør kognitivt press reduseres for enhver pris. Et enkelt grafisk grensesnitt for et servicenettverk med muligheten til å klikke på en knapp og få ønsket resultat kan være avgjørende for veksten av popularitet til denne teknologien.
Var ikke med på listen
Jeg hadde opprinnelig tenkt å inkludere noen flere brukstilfeller i listen, men bestemte meg så for å la være. Her er de, sammen med begrunnelsen for min beslutning:
- Multidatasenter. Etter min mening er dette ikke så mye et brukstilfelle som et smalt og spesifikt bruksområde for tjenestenettverk eller et sett med funksjoner som tjenesteoppdagelse.
- Inn- og utgang. Dette er et beslektet område, men jeg har begrenset meg (kanskje kunstig) til brukssaken "øst-vest trafikk". Ingress og egress fortjener en egen artikkel.
Konklusjon
Det er alt for nå! Igjen, denne listen er veldig vilkårlig og mest sannsynlig ufullstendig. Hvis du tror jeg har gått glipp av noe eller har feilet noe, vennligst kontakt meg på Twitter (). Vennligst respekter anstendighetsreglene.
PS fra oversetter
Tittelillustrasjonen for artikkelen er basert på et bilde fra artikkelen ""(av Gregory MacKinnon). Den viser hvordan noe funksjonalitet fra applikasjoner (i grønt) har flyttet til et tjenestenettverk som gir sammenkoblinger mellom dem (i blått).
Les også på bloggen vår:
- «";
- «";
- «'.
Kilde: www.habr.com
