Service Mesh är ett välkänt arkitektoniskt mönster för att integrera mikrotjänster och migrera till molninfrastruktur. Idag i molncontainervärlden är det ganska svårt att klara sig utan det. Flera open-source service mesh-implementeringar finns redan tillgängliga på marknaden, men deras funktionalitet, tillförlitlighet och säkerhet är inte alltid tillräckliga, särskilt när det kommer till kraven från stora finansiella företag över hela landet. Det är därför vi på Sbertech bestämde oss för att anpassa Service Mesh och vill prata om vad som är coolt med Service Mesh, vad som inte är så coolt och vad vi ska göra åt det.
Populariteten för Service Mesh-mönstret växer med molnteknikens popularitet. Det är ett dedikerat infrastrukturlager som förenklar interaktionen mellan olika nätverkstjänster. Moderna molnapplikationer består av hundratals eller till och med tusentals sådana tjänster, som var och en kan ha tusentals exemplar.
Interaktionen mellan och hanteringen av dessa tjänster är en nyckeluppgift för Service Mesh. I själva verket är detta en nätverksmodell av många proxyservrar, som hanteras centralt och som utför en uppsättning mycket användbara funktioner.
På proxynivå (dataplan):
- Tilldela och distribuera routing- och trafikbalanseringspolicyer
- Distribution av nycklar, certifikat, tokens
- Insamling av telemetri, generering av övervakningsmått
- Integration med säkerhets- och övervakningsinfrastruktur
På kontrollplansnivå:
- Tillämpa routing- och trafikbalanseringspolicyer
- Hantera återförsök och timeouts, detektera "döda" noder (kretsbrott), hantera injiceringsfel och säkerställa serviceresiliens genom andra mekanismer
- Samtalsautentisering/auktorisering
- Tappa mätvärden (observerbarhet)
Utbudet av användare som är intresserade av utvecklingen av denna teknik är mycket brett - från små startups till stora internetföretag, till exempel PayPal.
Varför behövs Service Mesh i företagssektorn?
Det finns många tydliga fördelar med att använda ett Service Mesh. Först och främst är det helt enkelt bekvämt för utvecklare: för att skriva kod en teknikplattform dyker upp, vilket avsevärt förenklar integrationen i molninfrastrukturen på grund av att transportskiktet är helt isolerat från applikationslogik.
Dessutom, Service Mesh förenklar relationen mellan leverantörer och konsumenter. Idag är det mycket lättare för API-leverantörer och konsumenter att komma överens om gränssnitt och kontrakt på egen hand, utan att involvera en speciell integrationsförmedlare och medlare - företagstjänstbussen. Detta tillvägagångssätt påverkar avsevärt två indikatorer. Hastigheten att få ut ny funktionalitet på marknaden (time-to-market) ökar, men samtidigt ökar kostnaden för lösningen, eftersom integrationen måste göras oberoende. Användningen av Service Mesh av utvecklingsteam för affärsfunktioner hjälper till att upprätthålla en balans här. Som ett resultat kan API-leverantörer enbart fokusera på applikationskomponenten i deras tjänst och helt enkelt publicera den i Service Mesh - API:et kommer omedelbart att bli tillgängligt för alla kunder, och kvaliteten på integrationen kommer att vara produktionsklar och kommer inte att kräva en enda rad med tilläggskod.
Nästa fördel är det Utvecklaren, som använder Service Mesh, fokuserar enbart på affärsfunktionalitet — på produkten snarare än den tekniska komponenten i dess tjänst. Till exempel behöver du inte längre tänka på att i en situation där en tjänst anropas över nätverket kan ett anslutningsfel uppstå någonstans. Dessutom hjälper Service Mesh till att balansera trafik mellan kopior av samma tjänst: om en av kopiorna "dör" kommer systemet att byta all trafik till de återstående livekopiorna.
Service Mesh - detta är en bra grund för att skapa distribuerade applikationer, som döljer detaljerna för att tillhandahålla samtal till sina tjänster för kunden både internt och externt. Alla applikationer som använder Service Mesh är isolerade på transportnivå både från nätverket och från varandra: det finns ingen kommunikation mellan dem. I det här fallet får utvecklaren full kontroll över sina tjänster.
Det bör nämnas att Det blir lättare att uppdatera distribuerade applikationer i en servicemesh-miljö. Till exempel en blå/grön driftsättning, där två applikationsmiljöer är tillgängliga för installation, varav den ena inte är uppdaterad och är i standbyläge. Återställning till den tidigare versionen i händelse av en misslyckad release utförs av en speciell router, vars roll Service Mesh klarar av bra. För att testa den nya versionen kan du använda kanariesläpp — byt till den nya versionen endast 10 % av trafiken eller förfrågningar från en pilotgrupp av klienter. Huvudtrafiken går till den gamla versionen, inget går sönder.
också Service Mesh ger oss SLA-kontroll i realtid. Det distribuerade proxysystemet tillåter inte att tjänsten misslyckas när en av klienterna överskrider den tilldelade kvoten. Om API-genomströmningen är begränsad kommer ingen att kunna överväldiga den med ett stort antal transaktioner: Service Mesh står framför tjänsten och tillåter inte onödig trafik. Det kommer helt enkelt att slå tillbaka i integrationslagret, och själva tjänsterna kommer att fortsätta att fungera utan att märka det.
Om ett företag vill minska kostnaderna för utveckling av integrationslösningar hjälper Service Mesh även till: Du kan byta till dess öppen källkodsversion från kommersiella produkter. Vårt Enterprise Service Mesh är baserat på open source-versionen av Service Mesh.
En annan fördel - tillgång till en enda fullfjädrad uppsättning integrationstjänster. Eftersom all integration byggs genom denna mellanvara kan vi hantera all integrationstrafik och kopplingar mellan applikationer som utgör företagets affärskärna. Det är väldigt bekvämt.
Och slutligen Service Mesh uppmuntrar ett företag att flytta till en dynamisk infrastruktur. Nu ser många mot containerisering. Att skära en monolit i mikrotjänster, implementera allt detta vackert - ämnet är på uppgång. Men när du försöker överföra ett system som har varit i produktion i många år till en ny plattform, stöter du genast på ett antal problem: att skjuta in allt i containrar och distribuera det på plattformen är inte lätt. Och implementeringen, synkroniseringen och interaktionen av dessa distribuerade komponenter är ett annat mycket komplext ämne. Hur kommer de att kommunicera med varandra? Kommer det att finnas kaskadfel? Service Mesh låter dig lösa några av dessa problem och underlätta migreringen från den gamla arkitekturen till den nya på grund av det faktum att du kan glömma nätverksutbyteslogiken.
Varför behöver du anpassning av Service Mesh?
I vårt företag samexisterar hundratals system och moduler, och körtiden är mycket laddad. Så det räcker inte med ett enkelt mönster av att ett system ringer ett annat och får ett svar, för i produktionen vill vi ha mer. Vad mer behöver du av ett företagstjänstnät?
Eventhanteringstjänst
Låt oss föreställa oss att vi behöver göra händelsebearbetning i realtid – ett system som analyserar kundens agerande i realtid och omedelbart kan ge honom ett relevant erbjudande. För att implementera liknande funktionalitet, använd arkitektoniskt mönster som kallas händelsedriven arkitektur (EDA). Inget av de nuvarande servicenäten stöder sådana mönster, men detta är mycket viktigt, särskilt för en bank!
Det är ganska konstigt att Remote Procedure Call (RPC) stöds av alla versioner av Service Mesh, men de är inte vänliga med EDA. Eftersom Service Mesh är en sorts modern distribuerad integration, och EDA är ett mycket relevant arkitektoniskt mönster som låter dig göra unika saker när det gäller kundupplevelse.
Vårt Enterprise Service Mesh borde lösa detta problem. Dessutom vill vi se implementeringen av garanterad leverans, streaming och komplex händelsebearbetning med hjälp av en mängd olika filter och mallar.
Filöverföringstjänst
Förutom EDA skulle det vara trevligt att kunna överföra filer: i Enterprise-skala är det väldigt ofta bara filintegration som är möjlig. I synnerhet används ETL (Extract, Transform, Load) arkitektoniska mönster. I den, som regel, utbyter alla filer uteslutande: big data används, vilket är opraktiskt att trycka in separata förfrågningar. Möjligheten att inbyggt stödja filöverföringar i Enterprise Service Mesh ger dig den flexibilitet som ditt företag behöver.
Orkestertjänst
Stora organisationer har nästan alltid olika team som tillverkar olika produkter. Till exempel i en bank arbetar vissa team med inlåning, medan andra arbetar med låneprodukter, och det finns ganska många sådana fall. Det här är olika människor, olika team som tillverkar sina produkter, utvecklar sina API:er och tillhandahåller dem till andra. Och mycket ofta finns det ett behov av att komponera dessa tjänster, samt implementera komplex logik för att sekventiellt anropa en uppsättning API:er. För att lösa detta problem behöver du en lösning i integrationslagret som kommer att förenkla all denna sammansatta logik (anropa flera API:er, beskriva förfrågningsvägen, etc.). Detta är orkestreringstjänsten i Enterprise Service Mesh.
AI och ML
När mikrotjänster kommunicerar genom ett enda integrationslager vet Service Mesh naturligtvis allt om varje tjänsts samtal. Vi samlar in telemetri: vem ringde vem, när, hur länge, hur många gånger och så vidare. När det finns hundratusentals av dessa tjänster, och miljarder samtal, ackumuleras allt detta och bildar Big Data. Denna data kan analyseras med hjälp av AI, maskininlärning etc., och sedan kan en del användbara saker göras utifrån analysresultaten. Det skulle vara lämpligt att åtminstone delvis överlåta kontrollen av all denna nätverkstrafik och applikationsanrop integrerade i Service Mesh till artificiell intelligens.
API Gateway-tjänst
Vanligtvis har ett Service Mesh proxyservrar och tjänster som pratar med varandra inom en pålitlig omkrets. Men det finns även externa motparter. Kraven på API:er som exponeras för denna grupp av konsumenter är mycket strängare. Vi delar upp denna uppgift i två huvuddelar.
- Безопасность. Problem relaterade till ddos, sårbarhet hos protokoll, applikationer, operativsystem och så vidare.
- Vågar. När antalet API:er som behöver serveras till klienter går in i tusentals eller till och med hundratusentals, finns det ett behov av någon form av hanteringsverktyg för denna uppsättning API:er. Du måste ständigt övervaka API:et: om de fungerar eller inte, vad deras status är, vilken trafik som flödar, vilken statistik, etc. En API-gateway bör hantera denna uppgift samtidigt som hela processen görs hanterbar och säker. Tack vare denna komponent lär sig Enterprise Service Mesh att enkelt publicera både interna och externa API:er.
Supporttjänst för specifika protokoll och dataformat (AS-gateway)
För närvarande kan de flesta Service Mesh-lösningar fungera inbyggt endast med HTTP- och HTTP2-trafik eller i ett reducerat läge på TCP/IP-nivå. Enterprise Service Mesh växer fram med många andra mycket specifika dataöverföringsprotokoll. Vissa system kan använda meddelandeförmedlare, andra är integrerade på databasnivå. Om företaget har SAP kan det också använda sitt eget integrationssystem. Dessutom fungerar allt detta och är en viktig del av verksamheten.
Du kan inte bara säga: "Låt oss överge arvet och skapa nya system som kan använda Service Mesh." För att koppla ihop alla gamla system med de nya (på en mikrotjänstarkitektur) kommer system som kan använda Service Mesh att behöva någon form av adapter, mellanhand, gateway. Håller med, det skulle vara trevligt om det kom i en kartong tillsammans med tjänsten. AC-gatewayen kan stödja alla integrationsalternativ. Tänk dig att du bara installerar Enterprise Service Mesh och det är redo att interagera med alla protokoll du behöver. Detta tillvägagångssätt är mycket viktigt för oss.
Ungefär så här föreställer vi oss företagsversionen av Service Mesh (Enterprise Service Mesh). Den beskrivna anpassningen löser de flesta problem som uppstår när man försöker använda färdiga versioner med öppen källkod av integrationsplattformen. Service Mesh-arkitekturen introducerades för bara ett par år sedan och fortsätter att utvecklas, och vi är glada över att kunna bidra till dess utveckling. Vi hoppas att vår erfarenhet kommer att vara användbar för dig.
Källa: will.com