Service Mesh er et velkendt arkitekturdesignmønster til integration af mikroservices og overgang til cloud-infrastruktur. I dag er det ret svært at klare sig uden det i en cloud-containerverden. Der er allerede flere open-source implementeringer af service mesh tilgængelige på markedet, men deres funktionalitet, pålidelighed og sikkerhed er ikke altid tilstrækkelig, især når der er krav fra store finansielle virksomheder i hele landet. Derfor har vi i Sbertech besluttet at tilpasse Service Mesh og vil gerne fortælle, hvad der er fantastisk ved Service Mesh, hvad der ikke er, og hvad vi har tænkt os at gøre med det.
Populariteten af Service Mesh-mønsteret stiger i takt med udbredelsen af cloud-teknologier. Det repræsenterer et dedikeret infrastrukturlag, der forenkler interaktionen mellem forskellige netværkstjenester. Moderne cloud-applikationer består af hundreder og endda tusinder af sådanne tjenester, hver med tusinder af kopier.
Interaktionen mellem disse tjenester og deres administration er den centrale opgave for Service Mesh. Det er faktisk en netværksmodel af mange proxyer, der styres centralt og udfører et sæt meget nyttige funktioner.
På proxy-niveau (data plane):
- Tildeling og distribution af routing- og trafikbalanceringspolitikker
- Distribution af nøgler, certifikater, tokens
- Indsamling af telemetri, dannelse af overvågningsmetrikker
- Integration med sikkerheds- og overvågningsinfrastruktur
På kontrolplan-niveau (control plane):
- Anvendelse af routing- og trafikbalanceringspolitikker
- Håndtering af gentagelser og tidsafbrud, identifikation af "døde" noder (circuit breaking), håndtering af fejl (injecting faults) og sikring af resiliens i tjenester via andre mekanismer
- Godkendelse/autorisation af opkald
- Frafaldelse af metrikker (observability)
Brugergruppen, der er interesseret i udviklingen af denne teknologi, er meget bred — fra små startups til store internetkoncernen, såsom PayPal.
Hvad er formålet med Service Mesh i erhvervssektoren
Brugen af Service Mesh giver mange åbenlyse fordele. Først og fremmest er det blot praktisk for udviklerne: til at skrive koden får de en teknologisk platform, som væsentligt forenkler integrationen i cloud-infrastrukturen ved at transportlaget er helt adskilt fra applikationslogikken.
Derudover, Service Mesh forenkler forholdet mellem leverandører og kunder. I dag er det meget lettere for API-leverandører og -kunder at blive enige om grænseflader og kontrakter uden at involvere en speciel integrationsmægler og voldgiftsmand – en virksomhedsservicebus. Denne tilgang påvirker to nøgletal: Hastigheden for at få ny funktionalitet på markedet (time-to-market) stiger, men omkostningerne for løsningen stiger, da integrationen skal gøres selvstændigt. Ved at bruge Service Mesh kan udviklingsteams af forretningsfunktionalitet finde balancen. Resultatet er, at API-leverandører kan fokusere udelukkende på den applikationsmæssige del af deres service og blot offentliggøre den i Service Mesh – API'et vil straks være tilgængeligt for alle kunder, og integrationskvaliteten vil være produktionsklar og kræve ikke en eneste ekstra kode-linje.
Den næste fordel er, at udvikleren, ved at bruge Service Mesh, fokuserer udelukkende på forretningsfunktionaliteten – på den produktmæssige, ikke den teknologiske del af sin service. For eksempel behøver man ikke længere at tænke på, at der i tilfælde af, at tjenesten kaldes over netværket, kan ske en forbindelsebrud. Derudover hjælper Service Mesh med at balancere trafikken mellem kopier af den samme service: hvis en af kopierne "er død", skifter systemet al trafik til de resterende sunde kopier.
Service Mesh — det er et godt fundament for at skabe distribuerede applikationer, som skjuler for kunden de detaljer, der vedrører opfordringer til hans tjenester både indefra og udefra. Alle applikationer, der bruger Service Mesh, er på transportniveau adskilt fra både netværket og hinanden: der er ingen forbindelse imellem dem. Samtidig får udvikleren fuld kontrol over sine tjenester.
Det skal bemærkes, at opdatering af distribuerede applikationer i et miljø, hvor Service Mesh anvendes, bliver lettere. For eksempel, blue/green-udrulning, hvor to anvendelsesmiljøer er tilgængelige til installation, hvoraf det ene ikke opdateres og er i standby. Tilbagevenden til en tidligere version i tilfælde af en mislykket udgivelse håndteres af en speciel router, som Service Mesh gør fremragende.. Til test af den nye version kan man også bruge en kanariefugleudgivelse — at skifte til den nye version kun for 10% af trafikken eller forespørgsler fra en pilotgruppe af kunder. Den primære trafik går til den gamle version, og intet går i stykker.
Derudover Service Mesh giver os kontrol over SLA i realtid. Systemet af distribuerede proxyer vil ikke lade tjenesten fejle, når en af kunderne overskrider den tildelte kvote. Hvis båndbredden via API er begrænset, kan ingen overbelaste det med et stort antal transaktioner: Service Mesh står foran tjenesten og tillader ikke overskydende trafik. Det vil blot forsvar i integrationslaget, mens selve tjenesterne fortsætter med at fungere uden at bemærke det.
Hvis en virksomhed ønsker at reducere omkostningerne ved udvikling af integrationsløsninger, er Service Mesh også en god løsning: man kan skifte fra kommercielle produkter til dens open-source version.. Vores Enterprise Service Mesh er baseret på open-source versionen af Service Mesh.
En anden fordel er tilgængeligheden af et samlet og fuldt udbygd sæt af integrationsservices. Da hele integrationen opbygges gennem dette mellemlag, kan vi styre al integrationstrafik og forholdet mellem applikationer, der danner virksomhedens kerne. Dette er meget praktisk.
Og endelig Service Mesh tilskynder virksomheden til at skifte til en dynamisk infrastruktur. I dag kigger mange mod containerisering. At dele monolitten op i mikrotjenester og implementere det hele smukt — dette emne er i høj kurs. Men når du forsøger at overføre et system, der har været i produktion i mange år, til nye spor, støder du straks på en lang række problemer: det er ikke nemt at presse det hele ind i containere og implementere det på platformen. Og implementering, synkronisering og interaktion mellem disse distribuerede komponenter er et andet meget komplekst emne. Hvordan vil de kommunikere med hinanden? Vil der ikke være kaskadesvigt? Service Mesh hjælper med at løse nogle af disse problemer og letter overgangen fra en gammel arkitektur til en ny ved at sikre, at man kan glemme logikken bag netværksudvekslingen.
Hvorfor er tilpasning af Service Mesh nødvendig
I vores virksomhed lever mange systemer og moduler side om side, og runtime er meget belastet. Så en simpel skabelon, hvor et system kalder et andet og modtager et svar, er ikke tilstrækkelig, fordi vi i produktion ønsker mere. Hvad mere er nødvendigt fra et virksomhedsmæssigt Service Mesh?
Begivenhedsbehandlingsservice
Lad os forestille os, at vi skal lave real-time event processing — et system, der i realtid analyserer kundens handlinger og straks kan give et relevant tilbud. For at realisere en sådan funktionalitet bruges en arkitektonisk skabelon kaldet event-driven architecture (EDA). Ingen eksisterende Service Mesh understøtter sådanne skabeloner nativt, og det er meget vigtigt, især for en bank!
Det er temmelig underligt, at "remote procedure call" (RPC) understøttes af alle versioner af Service Mesh, men de har ikke kompatibilitet med EDA. Fordi Service Mesh er en form for moderne distribueret integration, mens EDA er en meget relevant arkitektonisk skabelon, der muliggør unikke ting i forhold til kundeoplevelsen.
Vores Enterprise Service Mesh skal løse dette problem. Derudover ønsker vi at se implementeringen af garanteret levering, streaming og kompleks begivenhedsbehandling med brug af forskellige filtre og skabeloner.
Filoverførselsservice
Udover EDA ville det være godt at have mulighed for at overføre filer: i Enterprise er filintegration ofte den eneste mulighed. Det arkitektoniske mønster ETL (Extract, Transform, Load — "udtræk, transformere, indlæse") anvendes i sådanne situationer. Her udveksles alle normalt udelukkende filer: store datamængder, som det ikke er hensigtsmæssigt at sende med separate forespørgsler. Muligheden for nativ understøttelse af filoverførsel i Enterprise Service Mesh giver den nødvendige fleksibilitet for virksomheden.
Orkestreringstjeneste
I store organisationer er der næsten altid forskellige teams, der arbejder med forskellige produkter. For eksempel arbejder nogle teams i en bank med indskud, mens andre arbejder med kreditprodukter, og der er mange sådanne tilfælde. Det er forskellige mennesker, forskellige teams, der skaber deres egne produkter, udvikler deres egne API'er og stiller dem til rådighed for andre. Ofte opstår der et behov for at samle disse tjenester og implementere en kompleks logik for sekventiel kald til et sæt af API'er. For at løse dette problem er der brug for en løsning i integrationslaget, der gør det muligt at forenkle al denne kompositlogik (kald af flere API'er, beskrivelse af forespørgselsruter osv.). Det er her orkestreringstjenesten i Enterprise Service Mesh kommer ind i billedet.
AI og ML
Når mikrotjenester kommunikerer gennem et fælles integrationslag, ved Service Mesh naturligvis alt om kald til hver tjeneste. Vi indsamler telemetri: hvem der har kaldt hvem, hvornår, hvor længe, hvor mange gange osv. Når der er hundredtusindvis af disse tjenester, og kaldt er milliarder, akkumuleres alt dette og danner Big Data. Disse data kan analyseres ved hjælp af AI, maskinlæring osv., og derefter kan der laves nyttige ting baseret på analyse-resultaterne. Det ville være passende at overlade kontrol over al denne netværkstrafik og app-kald, der er integreret i Service Mesh, delvist til kunstig intelligens.
API Gateway tjeneste
Som regel er der i Service Mesh proxy'er og tjenester, der interagerer med hinanden inden for en betroet grænse. Men der findes også eksterne interessenter. Kravene til API'er, der gives til denne gruppe forbrugere, er langt mere seriøse. Denne opgave opdeles i to hoveddele.
- Sikkerhed. Spørgsmål relateret til ddos, sårbarheder i protokoller, applikationer, operativsystemer osv.
- Størrelser. Når antallet af API-konti, der skal udleveres til kunderne, går op i tusinder eller endda hundredtusinder, opstår behovet for et værktøj til at administrere denne API-samling. Det er nødvendigt at overvåge API'erne konstant: fungerer de eller ej, hvad er deres status, hvilken trafik der kommer, hvilke statistikker der er osv. API-gatewayen skal kunne klare denne opgave ved at gøre hele processe administreret og sikker. Takket være denne komponent lærer Enterprise Service Mesh uden unødvendig besvær at publicere både interne og eksterne API’er.
Service til understøttelse af specifikke protokoller og dataformater (API-gateway)
I øjeblikket kan de fleste Service Mesh-løsninger kun arbejde nativt med HTTP- og HTTP2-trafik eller i en begrænset tilstand på TCP/IP-niveau. Enterprise Service Mesh har mange andre meget specifikke datatransmissionsprotokoller. Nogle systemer kan bruge meddelelsesbrokere, mens andre er integreret på databasesniveau. Hvis virksomheden har SAP, kan det også anvende sit eget integrationssystem. Alt dette fungerer, og det er en vigtig del af forretningen.
Man kan ikke bare sige: "Lad os opgive legacy og lave nye systemer, der kan bruge Service Mesh". For at få alle de gamle systemer til at fungere sammen med de nye (på mikrotjenestearkitektur), vil systemer, der kan bruge Service Mesh, have brug for en eller anden adapter, mellemliggende enhed, gateway. Enig, det ville være rart, hvis det blev leveret i boksen sammen med servicen. API-gatewayen kan lige netop understøtte enhver form for integration. Tænk på det, du installerer bare Enterprise Service Mesh, og det er allerede klar til at interagere med alle de protokoller, du har brug for. For os er denne tilgang meget vigtig.
Sådan forestiller vi os den virksomhedsversion af Service Mesh (Enterprise Service Mesh). Den beskrevne tilpasning løser de fleste problemer, der opstår, når man forsøger at bruge de færdige open-source versioner af integrationsplatformen. Service Mesh-arkitekturen, som kun har eksisteret i et par år, fortsætter med at udvikle sig, og vi er glade for, at vi kan bidrage til dens udvikling. Vi håber, at vores erfaring vil være nyttig for dig.
Kilde: habr.com
