Service Mesh er et velkjent arkitektonisk mønster for integrering av mikrotjenester og migrering til skyinfrastruktur. I dag i skycontainerverdenen er det ganske vanskelig å klare seg uten det. Flere åpen kildekode-tjenestemesh-implementeringer er allerede tilgjengelige på markedet, men deres funksjonalitet, pålitelighet og sikkerhet er ikke alltid tilstrekkelig, spesielt når det kommer til kravene til store finansselskaper over hele landet. Det er derfor vi i Sbertech bestemte oss for å tilpasse Service Mesh og ønsker å snakke om hva som er kult med Service Mesh, hva som ikke er så kult, og hva vi skal gjøre med det.
Populariteten til Service Mesh-mønsteret vokser med populariteten til skyteknologier. Det er et dedikert infrastrukturlag som forenkler samhandlingen mellom ulike nettverkstjenester. Moderne skyapplikasjoner består av hundrevis eller til og med tusenvis av slike tjenester, som hver kan ha tusenvis av kopier.
Samspillet mellom og forvaltningen av disse tjenestene er en nøkkeloppgave for Service Mesh. Faktisk er dette en nettverksmodell av mange proxyer, administrert sentralt og utfører et sett med svært nyttige funksjoner.
På proxy-nivå (dataplan):
- Tilordne og distribuere retningslinjer for ruting og trafikkbalansering
- Utdeling av nøkler, sertifikater, tokens
- Samling av telemetri, generering av overvåkingsmålinger
- Integrasjon med sikkerhets- og overvåkingsinfrastruktur
På kontrollplannivå:
- Bruk av retningslinjer for ruting og trafikkbalansering
- Administrere gjenforsøk og tidsavbrudd, oppdage "døde" noder (kretsbrudd), administrere injeksjonsfeil og sikre serviceresiliens gjennom andre mekanismer
- Anropsautentisering/autorisasjon
- Slippberegninger (observerbarhet)
Utvalget av brukere som er interessert i utviklingen av denne teknologien er veldig bredt - fra små startups til store internettselskaper, for eksempel PayPal.
Hvorfor trengs Service Mesh i bedriftssektoren?
Det er mange klare fordeler ved å bruke et Service Mesh. Først av alt er det ganske enkelt praktisk for utviklere: for å skrive kode en teknologiplattform dukker opp, som betydelig forenkler integrasjonen i skyinfrastrukturen på grunn av at transportlaget er fullstendig isolert fra applikasjonslogikken.
I tillegg, Service Mesh forenkler forholdet mellom leverandører og forbrukere. I dag er det mye lettere for API-leverandører og forbrukere å bli enige om grensesnitt og kontrakter på egen hånd, uten å involvere en spesiell integrasjonsformidler og arbiter - bedriftstjenestebussen. Denne tilnærmingen påvirker to indikatorer betydelig. Hastigheten på å bringe ny funksjonalitet til markedet (time-to-market) øker, men samtidig øker kostnadene for løsningen, siden integrasjon må gjøres uavhengig. Bruken av Service Mesh av utviklingsteam for forretningsfunksjonalitet bidrar til å opprettholde en balanse her. Som et resultat kan API-leverandører fokusere utelukkende på applikasjonskomponenten til tjenesten deres og ganske enkelt publisere den i Service Mesh - API-en vil umiddelbart bli tilgjengelig for alle kunder, og kvaliteten på integrasjonen vil være produksjonsklar og vil ikke kreve en eneste linje med tilleggskode.
Den neste fordelen er det utvikleren, ved hjelp av Service Mesh, fokuserer utelukkende på forretningsfunksjonalitet — på produktet i stedet for den teknologiske komponenten i tjenesten. Du trenger for eksempel ikke lenger tenke på at i en situasjon der en tjeneste kalles over nettverket, kan det oppstå en tilkoblingsfeil et sted. I tillegg hjelper Service Mesh med å balansere trafikk mellom kopier av den samme tjenesten: Hvis en av kopiene "dør", vil systemet bytte all trafikk til de gjenværende live-kopiene.
Service Mesh - dette er et godt grunnlag for å lage distribuerte applikasjoner, som skjuler detaljene for å gi anrop til sine tjenester både internt og eksternt for kunden. Alle applikasjoner som bruker Service Mesh er isolert på transportnivå både fra nettverket og fra hverandre: det er ingen kommunikasjon mellom dem. I dette tilfellet får utvikleren full kontroll over tjenestene sine.
Det er verdt å merke seg at Det blir enklere å oppdatere distribuerte applikasjoner i et service mesh-miljø. For eksempel en blå/grønn distribusjon, der to applikasjonsmiljøer er tilgjengelige for installasjon, hvorav ett ikke er oppdatert og er i standby-modus. Å rulle tilbake til forrige versjon i tilfelle en mislykket utgivelse utføres av en spesiell ruter, hvis rolle Service Mesh takler godt. For å teste den nye versjonen kan du bruke kanarifrigjøring — bytt til den nye versjonen bare 10 % av trafikken eller forespørsler fra en pilotgruppe med klienter. Hovedtrafikken går til den gamle versjonen, ingenting går i stykker.
også Service Mesh gir oss SLA-kontroll i sanntid. Det distribuerte proxy-systemet vil ikke tillate at tjenesten mislykkes når en av klientene overskrider kvoten som er tildelt den. Hvis API-gjennomstrømningen er begrenset, vil ingen kunne overvelde den med et stort antall transaksjoner: Service Mesh står foran tjenesten og tillater ikke unødvendig trafikk. Det vil rett og slett slå tilbake i integreringslaget, og tjenestene i seg selv vil fortsette å fungere uten å merke det.
Dersom en bedrift ønsker å redusere kostnadene for utvikling av integrasjonsløsninger, hjelper Service Mesh også: Du kan bytte til åpen kildekode-versjon fra kommersielle produkter. Vår Enterprise Service Mesh er basert på åpen kildekode-versjon av Service Mesh.
En annen fordel - tilgjengeligheten av et enkelt fullverdig sett med integrasjonstjenester. Fordi all integrasjon bygges gjennom denne mellomvaren, kan vi administrere all integrasjonstrafikk og koblinger mellom applikasjoner som utgjør forretningskjernen i selskapet. Det er veldig behagelig.
endelig Service Mesh oppfordrer et selskap til å flytte til en dynamisk infrastruktur. Nå ser mange mot containerisering. Å kutte en monolitt i mikrotjenester, implementere alt dette vakkert - emnet er på vei oppover. Men når du prøver å overføre et system som har vært i produksjon i mange år til en ny plattform, støter du umiddelbart på en rekke problemer: å skyve det hele inn i containere og distribuere det på plattformen er ikke lett. Og implementeringen, synkroniseringen og interaksjonen av disse distribuerte komponentene er et annet veldig komplekst tema. Hvordan vil de kommunisere med hverandre? Vil det være kaskadefeil? Service Mesh lar deg løse noen av disse problemene og forenkle migrering fra den gamle arkitekturen til den nye på grunn av det faktum at du kan glemme nettverksutvekslingslogikken.
Hvorfor trenger du tilpasning av Service Mesh?
I vårt selskap eksisterer hundrevis av systemer og moduler samtidig, og kjøretiden er svært belastet. Så et enkelt mønster med at ett system ringer til et annet og mottar svar er ikke nok, for i produksjonen vil vi ha mer. Hva mer trenger du fra et enterprise service mesh?
Eventbehandlingstjeneste
La oss forestille oss at vi trenger å lage hendelsesbehandling i sanntid – et system som analyserer kundens handlinger i sanntid og umiddelbart kan gi ham et relevant tilbud. For å implementere lignende funksjonalitet, bruk arkitektonisk mønster kalt hendelsesdrevet arkitektur (EDA). Ingen av de nåværende tjenestenettene støtter slike mønstre, men dette er veldig viktig, spesielt for en bank!
Det er ganske merkelig at Remote Procedure Call (RPC) støttes av alle versjoner av Service Mesh, men de er ikke vennlige med EDA. Fordi Service Mesh er en slags moderne distribuert integrasjon, og EDA er et veldig relevant arkitektonisk mønster som lar deg gjøre unike ting når det gjelder kundeopplevelse.
Vår Enterprise Service Mesh bør løse dette problemet. I tillegg ønsker vi å se implementeringen av garantert levering, streaming og kompleks hendelsesbehandling ved hjelp av en rekke filtre og maler.
Filoverføringstjeneste
I tillegg til EDA, ville det vært fint å kunne overføre filer: i Enterprise-skala er det veldig ofte bare filintegrasjon som er mulig. Spesielt brukes ETL (Extract, Transform, Load) arkitektoniske mønster. I den utveksler som regel alle filer utelukkende: big data brukes, noe som er upraktisk å presse inn separate forespørsler. Muligheten til å støtte filoverføringer i Enterprise Service Mesh gir deg fleksibiliteten virksomheten din trenger.
Orkestreringstjeneste
Store organisasjoner har nesten alltid forskjellige team som lager forskjellige produkter. For eksempel i en bank jobber noen team med innskudd, mens andre jobber med låneprodukter, og det er ganske mange slike tilfeller. Dette er forskjellige mennesker, forskjellige team som lager produktene sine, utvikler API-ene og gir dem til andre. Og veldig ofte er det behov for å komponere disse tjenestene, samt implementere kompleks logikk for sekvensielt å kalle et sett med APIer. For å løse dette problemet trenger du en løsning i integreringslaget som vil forenkle all denne sammensatte logikken (kalle flere APIer, beskrive forespørselsruten, etc.). Dette er orkestreringstjenesten i Enterprise Service Mesh.
AI og ML
Når mikrotjenester kommuniserer gjennom ett enkelt integreringslag, vet Service Mesh naturligvis alt om hver tjenestes samtaler. Vi samler inn telemetri: hvem ringte hvem, når, hvor lenge, hvor mange ganger og så videre. Når det er hundretusenvis av disse tjenestene, og milliarder av samtaler, akkumuleres alt dette og danner Big Data. Disse dataene kan analyseres ved hjelp av AI, maskinlæring osv., og så kan noen nyttige ting gjøres basert på analyseresultatene. Det vil være hensiktsmessig å i det minste delvis overlate kontrollen over all denne nettverkstrafikken og applikasjonsoppkallene integrert i Service Mesh til kunstig intelligens.
API-gateway-tjeneste
Vanligvis har et Service Mesh proxyer og tjenester som snakker med hverandre innenfor en pålitelig omkrets. Men det finnes også eksterne motparter. Kravene til API-er utsatt for denne gruppen forbrukere er mye strengere. Vi deler denne oppgaven i to hoveddeler.
- Безопасность. Problemer knyttet til ddos, sårbarhet for protokoller, applikasjoner, operativsystemer og så videre.
- Skala. Når antallet APIer som må serveres til klienter går inn i tusenvis eller til og med hundretusener, er det behov for et slags administrasjonsverktøy for dette settet med APIer. Du må hele tiden overvåke APIen: om de fungerer eller ikke, hva statusen deres er, hvilken trafikk som flyter, hvilken statistikk osv. En API-gateway skal håndtere denne oppgaven samtidig som den gjør hele prosessen håndterbar og sikker. Takket være denne komponenten lærer Enterprise Service Mesh å enkelt publisere både interne og eksterne APIer.
Støttetjeneste for spesifikke protokoller og dataformater (AS gateway)
For øyeblikket kan de fleste Service Mesh-løsninger fungere naturlig bare med HTTP- og HTTP2-trafikk eller i redusert modus på TCP/IP-nivå. Enterprise Service Mesh dukker opp med mange andre svært spesifikke dataoverføringsprotokoller. Noen systemer kan bruke meldingsmeglere, andre er integrert på databasenivå. Hvis bedriften har SAP, kan den også bruke sitt eget integreringssystem. Dessuten fungerer alt dette og er en viktig del av virksomheten.
Du kan ikke bare si: "La oss forlate arven og lage nye systemer som kan bruke Service Mesh." For å koble alle de gamle systemene med de nye (på en mikrotjenestearkitektur), vil systemer som kan bruke Service Mesh trenge en slags adapter, mellomledd, gateway. Enig, det ville vært fint om det kom i en boks sammen med tjenesten. AC-gatewayen kan støtte alle integreringsalternativer. Tenk deg at du bare installerer Enterprise Service Mesh og den er klar til å samhandle med alle protokollene du trenger. Denne tilnærmingen er veldig viktig for oss.
Det er omtrent slik vi forestiller oss bedriftsversjonen av Service Mesh (Enterprise Service Mesh). Den beskrevne tilpasningen løser de fleste problemene som oppstår når man prøver å bruke ferdige åpen kildekode-versjoner av integrasjonsplattformen. Service Mesh-arkitekturen ble introdusert for bare et par år siden og fortsetter å utvikle seg, og vi er glade for å kunne bidra til utviklingen. Vi håper at vår erfaring vil være nyttig for deg.
Kilde: www.habr.com