Service Mesh er et velkendt arkitektonisk mønster til integration af mikrotjenester og migrering til cloud-infrastruktur. I dag, i cloud-container-verdenen, er det ret svært at undvære det. Adskillige open source service mesh-implementeringer er allerede tilgængelige på markedet, men deres funktionalitet, pålidelighed og sikkerhed er langt fra altid nok, især når det kommer til kravene fra store finansielle virksomheder i hele landet. Derfor besluttede vi hos Sbertech at tilpasse Service Mesh og vil gerne tale om, hvad der er fedt i Service Mesh, hvad der ikke er særlig godt, og hvad vi skal med det.
Populariteten af Service Mesh-mønsteret vokser med populariteten af cloud-teknologier. Det er et dedikeret infrastrukturlag, der forenkler interaktionen mellem forskellige netværkstjenester. Moderne cloud-applikationer består af hundredvis og endda tusindvis af sådanne tjenester, som hver kan have tusindvis af kopier.
Interaktion mellem disse tjenester og deres ledelse er en nøgleopgave for Service Mesh. Faktisk er dette en netværksmodel af mange proxyer, der styres centralt og udfører et sæt meget nyttige funktioner.
På proxy-niveau (dataplan):
- Tildeling og udbredelse af politikker for routing og trafikbalancering
- Uddeling af nøgler, certifikater, tokens
- Indsamling af telemetri, dannelse af overvågningsmetrikker
- Integration med sikkerheds- og overvågningsinfrastruktur
På kontrolplanniveau:
- Anvendelse af routing- og trafikbalanceringspolitikker
- Håndtering af gentagelser og timeouts, detektering af "døde" noder (kredsløbsbrud), håndtering af fejlsituationer (injektion af fejl) og sikring af stabiliteten (resiliens) af tjenester gennem andre mekanismer
- Opkaldsgodkendelse/autorisation
- Faldende metrics (observerbarhed)
Kredsen af brugere, der er interesseret i udviklingen af denne teknologi, er meget bred - fra små startups til store internetselskaber, såsom PayPal.
Hvorfor har du brug for Service Mesh i erhvervslivet
Brug af et Service Mesh giver mange åbenlyse fordele. Først og fremmest er det bare praktisk for udviklere: til at skrive kode ny teknologisk platform, hvilket i høj grad forenkler integrationen i cloud-infrastrukturen på grund af, at transportlaget er fuldstændig isoleret fra applikationslogikken.
Desuden Service Mesh forenkler forholdet mellem leverandører og forbrugere. I dag er det meget nemmere for API-udbydere og forbrugere at blive enige om grænseflader og kontrakter på egen hånd uden at involvere en særlig integrationsformidler og voldgiftsmand til dette - en virksomhedsservicebus. Denne tilgang påvirker i høj grad to indikatorer. Hastigheden på at bringe ny funktionalitet til markedet (time-to-market) øges, men samtidig stiger omkostningerne ved løsningen, da integrationen skal udføres selvstændigt. Brugen af Service Mesh af business feature teams hjælper med at holde balancen her. Som et resultat kan API-udbydere udelukkende fokusere på applikationskomponenten af deres tjeneste og blot publicere den i Service Mesh - API'en bliver straks tilgængelig for alle kunder, og integrationskvaliteten vil være produktionsklar og vil ikke kræve en enkelt linje af ekstra kode.
Den næste fordel er det udvikler, der bruger Service Mesh, fokuserer udelukkende på forretningsfunktionalitet - på produktet og ikke på den teknologiske komponent i deres service. For eksempel behøver du ikke længere tænke på, at der i en situation, hvor tjenesten bliver kaldt over netværket, kan opstå et forbindelsesbrud et sted. Derudover hjælper Service Mesh med at balancere trafikken mellem kopier af samme tjeneste: hvis en af kopierne "døde", så vil systemet skifte al trafik til de resterende live kopier.
Service Mesh — det er et godt grundlag for at bygge distribuerede applikationer, som skjuler for kunden detaljerne om at give opkald til sine tjenester både indefra og udefra. Alle applikationer, der bruger Service Mesh, er isoleret fra netværket og fra hinanden på transportniveau: der er ingen forbindelse mellem dem. Dette giver udvikleren fuld kontrol over deres tjenester.
Det skal bemærkes, at opdatering af distribuerede applikationer i et miljø, hvor Service Mesh bruges, bliver lettere. For eksempel en blå/grøn installation, hvor to applikationsmiljøer er tilgængelige for installation, hvoraf det ene ikke er opdateret og er inaktivt. Tilbage til den tidligere version i tilfælde af en mislykket udgivelse udføres af en speciel router, hvis rolle er perfekt håndteret af Service Mesh. For at teste den nye version kan du også bruge udsætning af kanariefugle - Skift til den nye version kun 10% af trafikken eller anmodninger fra en pilotgruppe af klienter. Hovedtrafikken går til den gamle version, intet går i stykker.
Også Service Mesh giver os SLA-kontrol i realtid. Systemet med distribuerede fuldmagter vil ikke tillade at overvælde tjenesten, når en af kunderne overskrider den kvote, han har fået. Hvis båndbredden på API'en er begrænset, vil ingen være i stand til at presse den med et stort antal transaktioner: Service Mesh står foran tjenesten og tillader ikke ekstra trafik. Det vil simpelthen slå tilbage i integrationslaget, og selve tjenesterne vil fortsætte med at fungere uden at bemærke det.
Hvis en virksomhed ønsker at reducere omkostningerne ved at udvikle integrationsløsninger, hjælper Service Mesh også: du kan skifte til dens open source-versioner fra kommercielle produkter. Vores Enterprise Service Mesh er baseret på open source-versionen af Service Mesh.
En anden fordel er tilgængelighed af et enkelt fuldgyldigt sæt integrationstjenester. Da al integration er bygget gennem dette mellemlag, kan vi styre al integrationstrafik og kommunikation mellem applikationer, der udgør virksomhedens forretningskerne. Det er meget behageligt.
Og endelig Service Mesh opfordrer en virksomhed til at flytte til en dynamisk infrastruktur. Nu søger mange mod containerisering. At skære en monolit i mikrotjenester, det hele er smukt at implementere - emnet er stigende. Men når man forsøger at sætte et system på et nyt grundlag, der har været i produktion i mange år, støder man straks på en række problemer: Det er ikke nemt at skubbe det hele ned i containere og installere det på en platform. Og implementeringen, synkroniseringen og interaktionen af disse distribuerede komponenter er et andet komplekst emne. Hvordan vil de kommunikere med hinanden? Vil der være kaskadefejl? Service Mesh giver dig mulighed for at løse nogle af disse problemer og lette migreringen fra den gamle arkitektur til den nye på grund af det faktum, at du kan glemme netværksudvekslingslogikken.
Hvorfor Service Mesh-tilpasning er nødvendig
I vores virksomhed eksisterer hundredvis af systemer og moduler sammen, og køretiden er meget travl. Så et simpelt mønster, hvor et system ringer til et andet og får svar, er ikke nok, for i produktionen vil vi have mere. Hvad har du ellers brug for fra en virksomheds Service Mesh?
Eventhåndteringsservice
Lad os forestille os, at vi skal lave hændelsesbehandling i realtid – et system, der analyserer kundens handlinger i realtid og umiddelbart kan give ham et relevant tilbud. For at implementere denne funktionalitet, brug arkitektonisk mønster kaldet begivenhedsdrevet arkitektur (EDA). Ingen af de nuværende Service Mesh understøtter naturligt sådanne mønstre, og det er meget vigtigt, især for en bank!
Det er ret mærkeligt, at "remote call" Remote Procedure Call (RPC) understøttes af alle versioner af Service Mesh, men de er ikke venner med EDA. Fordi Service Mesh er en slags moderne distribueret integration, og EDA er et meget relevant arkitektonisk mønster, der giver dig mulighed for at gøre unikke ting i forhold til kundeoplevelsen.
Vores Enterprise Service Mesh burde løse dette problem. Derudover ønsker vi at se implementeringen af garanteret levering, streaming og kompleks hændelsesbehandling ved hjælp af en række forskellige filtre og skabeloner.
Filoverførselstjeneste
Ud over EDA ville det være rart at kunne overføre filer: I Enterprise-skalaer er kun filintegration meget ofte mulig. Især ETL (Extract, Transform, Load) arkitektoniske mønster bruges. I den udveksler alle som regel udelukkende filer: big data bruges, hvilket er upassende at skubbe med separate anmodninger. Evnen til at understøtte filoverførsel i Enterprise Service Mesh giver dig den fleksibilitet, som din virksomhed har brug for.
Orkestreringstjeneste
Store organisationer har næsten altid forskellige teams, der laver forskellige produkter. I en bank arbejder nogle teams for eksempel med indlån, mens andre arbejder med låneprodukter, og den slags sager er der rigtig mange af. Det er forskellige mennesker, forskellige teams, der laver deres produkter, udvikler deres egne API'er og leverer dem til andre. Og meget ofte er der behov for sammensætningen af disse tjenester, såvel som implementeringen af kompleks logik til sekventielt at kalde et sæt API'er. For at løse dette problem er der behov for en løsning i integrationslaget, som vil forenkle al denne sammensatte logik (kalder flere API'er, beskriver anmodningsruten osv.). Dette er orkestreringstjenesten i Enterprise Service Mesh.
AI og ML
Når mikrotjenester kommunikerer gennem et enkelt integrationslag, ved Service Mesh naturligvis alt om hver tjenestes opkald. Vi indsamler telemetri: hvem ringede til hvem, hvornår, hvor længe, hvor mange gange og så videre. Når der er hundredtusindvis af disse tjenester og milliarder af opkald, så akkumuleres alt dette og danner Big Data. Disse data kan analyseres ved hjælp af AI, machine learning osv., og så kan nogle nyttige ting gøres ud fra analysens resultater. Det ville være hensigtsmæssigt i det mindste delvist at overføre kontrol over al denne netværkstrafik og applikationsopkald integreret i Service Mesh til kunstig intelligens.
API Gateway Service (API Gateway)
Et Service Mesh har typisk proxyer og tjenester, der kommunikerer med hinanden inden for en betroet perimeter. Men der er også eksterne samarbejdspartnere. Kravene til API'er udsat for denne forbrugergruppe er meget strengere. Vi deler denne opgave op i to hoveddele.
- Безопасность. Problemer relateret til ddos, protokolsårbarheder, applikationer, operativsystemer og så videre.
- Vægt. Når antallet af API'er, der skal gives til kunder, løber op i tusindvis eller endda hundredtusinder, er der behov for en form for administrationsværktøj til dette sæt API'er. Du skal konstant overvåge API'en: om de virker eller ej, i hvilken status, hvilken trafik der kommer, hvilken statistik osv. API-gatewayen skulle være i stand til at håndtere denne opgave, hvilket gør hele processen overskuelig og sikker. Takket være denne komponent lærer Enterprise Service Mesh, hvordan man nemt udgiver både intern API og ekstern API.
Supportservice til specifikke protokoller og dataformater (AS-gateway)
I øjeblikket kan de fleste Service Mesh-løsninger kun fungere med HTTP- og HTTP2-trafik eller i en trunkeret tilstand på TCP/IP-niveau. Enterprise Service Mesh har mange andre meget specifikke dataoverførselsprotokoller. Nogle systemer kan bruge meddelelsesmæglere, andre er integreret på databaseniveau. Hvis virksomheden har SAP, så kan den også bruge sit eget integrationssystem. Og alt dette fungerer og er en vigtig del af forretningen.
Du kan ikke bare sige: "Lad os opgive arven og lave nye systemer, der kan bruge Service Mesh." For at blive venner med alle gamle systemer med nye (på en mikroservicearkitektur), vil systemer, der kan bruge Service Mesh, have brug for en form for adapter, mellemled, gateway. Enig, det ville være rart hvis det kom i en æske med servicen. AC-gatewayen kan bare understøtte enhver integrationsmulighed. Forestil dig, at du bare installerer 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 præsenterer vi virksomhedsversionen af Service Mesh (Enterprise Service Mesh). Den beskrevne tilpasning løser de fleste af de problemer, der opstår, når man forsøger at bruge færdige open source-versioner af integrationsplatformen. Efter at have dukket op for kun et par år siden, fortsætter Service Mesh-arkitekturen med at udvikle sig, og vi er glade for at kunne bidrage til dens udvikling. Vi håber, at vores erfaring vil være nyttig for dig.
Kilde: www.habr.com