<\/a><\/noindex>
P\u00e5 proxy-niveau (data plane):<\/i><\/p>\n\nTildeling og distribution af routing- og trafikbalanceringspolitikker\n<\/li>\n Distribution af n\u00f8gler, certifikater, tokens\n<\/li>\n Indsamling af telemetri, dannelse af overv\u00e5gningsmetrikker\n<\/li>\n Integration med sikkerheds- og overv\u00e5gningsinfrastruktur\n<\/li>\n<\/ul>\n\nP\u00e5 kontrolplan-niveau (control plane):<\/i><\/p>\n\nAnvendelse af routing- og trafikbalanceringspolitikker\n<\/li>\n H\u00e5ndtering af gentagelser og tidsafbrud, identifikation af \"d\u00f8de\" noder (circuit breaking), h\u00e5ndtering af fejl (injecting faults) og sikring af resiliens i tjenester via andre mekanismer\n<\/li>\n Godkendelse\/autorisation af opkald\n<\/li>\n Frafaldelse af metrikker (observability)\n<\/li>\n<\/ul>\n\nBrugergruppen, der er interesseret i udviklingen af denne teknologi, er meget bred \u2014 fra sm\u00e5 startups til store internetkoncernen, s\u00e5som PayPal.<\/p>\n
Hvad er form\u00e5let med Service Mesh i erhvervssektoren<\/h2>\n \nBrugen af Service Mesh giver mange \u00e5benlyse fordele. F\u00f8rst og fremmest er det blot praktisk for udviklerne: til at skrive koden f\u00e5r de en teknologisk platform<\/i>, som v\u00e6sentligt forenkler integrationen i cloud-infrastrukturen ved at transportlaget er helt adskilt fra applikationslogikken.<\/p>\n
Derudover, Service Mesh forenkler forholdet mellem leverand\u00f8rer og kunder.<\/i> I dag er det meget lettere for API-leverand\u00f8rer og -kunder at blive enige om gr\u00e6nseflader og kontrakter uden at involvere en speciel integrationsm\u00e6gler og voldgiftsmand \u2013 en virksomhedsservicebus. Denne tilgang p\u00e5virker to n\u00f8gletal: Hastigheden for at f\u00e5 ny funktionalitet p\u00e5 markedet (time-to-market) stiger, men omkostningerne for l\u00f8sningen stiger, da integrationen skal g\u00f8res selvst\u00e6ndigt. Ved at bruge Service Mesh kan udviklingsteams af forretningsfunktionalitet finde balancen. Resultatet er, at API-leverand\u00f8rer kan fokusere udelukkende p\u00e5 den applikationsm\u00e6ssige del af deres service og blot offentligg\u00f8re den i Service Mesh \u2013 API'et vil straks v\u00e6re tilg\u00e6ngeligt for alle kunder, og integrationskvaliteten vil v\u00e6re produktionsklar og kr\u00e6ve ikke en eneste ekstra kode-linje.<\/p>\n
Den n\u00e6ste fordel er, at udvikleren, ved at bruge Service Mesh, fokuserer udelukkende p\u00e5 forretningsfunktionaliteten<\/i> \u2013 p\u00e5 den produktm\u00e6ssige, ikke den teknologiske del af sin service. For eksempel beh\u00f8ver man ikke l\u00e6ngere at t\u00e6nke p\u00e5, at der i tilf\u00e6lde af, at tjenesten kaldes over netv\u00e6rket, kan ske en forbindelsebrud. Derudover hj\u00e6lper Service Mesh med at balancere trafikken mellem kopier af den samme service: hvis en af kopierne \"er d\u00f8d\", skifter systemet al trafik til de resterende sunde kopier. <\/p>\n
Service Mesh <\/i>\u2014 det er et godt fundament for at skabe distribuerede applikationer<\/i>, som skjuler for kunden de detaljer, der vedr\u00f8rer opfordringer til hans tjenester b\u00e5de indefra og udefra. Alle applikationer, der bruger Service Mesh, er p\u00e5 transportniveau adskilt fra b\u00e5de netv\u00e6rket og hinanden: der er ingen forbindelse imellem dem. Samtidig f\u00e5r udvikleren fuld kontrol over sine tjenester.<\/p>\n
Det skal bem\u00e6rkes, at opdatering af distribuerede applikationer i et milj\u00f8, hvor Service Mesh anvendes, bliver lettere.<\/i> For eksempel, blue\/green-udrulning, hvor to anvendelsesmilj\u00f8er er tilg\u00e6ngelige til installation, hvoraf det ene ikke opdateres og er i standby. Tilbagevenden til en tidligere version i tilf\u00e6lde af en mislykket udgivelse h\u00e5ndteres af en speciel router, som Service Mesh g\u00f8r fremragende.. <\/i>Til test af den nye version kan man ogs\u00e5 bruge en kanariefugleudgivelse <\/i>\u2014 at skifte til den nye version kun for 10% af trafikken eller foresp\u00f8rgsler fra en pilotgruppe af kunder. Den prim\u00e6re trafik g\u00e5r til den gamle version, og intet g\u00e5r i stykker.<\/p>\n
Derudover Service Mesh giver os kontrol over SLA i realtid<\/i>. Systemet af distribuerede proxyer vil ikke lade tjenesten fejle, n\u00e5r en af kunderne overskrider den tildelte kvote. Hvis b\u00e5ndbredden via API er begr\u00e6nset, kan ingen overbelaste det med et stort antal transaktioner: Service Mesh st\u00e5r foran tjenesten og tillader ikke overskydende trafik. Det vil blot forsvar i integrationslaget, mens selve tjenesterne forts\u00e6tter med at fungere uden at bem\u00e6rke det.<\/p>\n
Hvis en virksomhed \u00f8nsker at reducere omkostningerne ved udvikling af integrationsl\u00f8sninger, er Service Mesh ogs\u00e5 en god l\u00f8sning: man kan skifte fra kommercielle produkter til dens open-source version.<\/i>. Vores Enterprise Service Mesh er baseret p\u00e5 open-source versionen af Service Mesh. <\/p>\n
En anden fordel er tilg\u00e6ngeligheden af et samlet og fuldt udbygd s\u00e6t af integrationsservices<\/i>. Da hele integrationen opbygges gennem dette mellemlag, kan vi styre al integrationstrafik og forholdet mellem applikationer, der danner virksomhedens kerne. Dette er meget praktisk.<\/p>\n
Og endelig Service Mesh tilskynder virksomheden til at skifte til en dynamisk infrastruktur.<\/i> I dag kigger mange mod containerisering. At dele monolitten op i mikrotjenester og implementere det hele smukt \u2014 dette emne er i h\u00f8j kurs. Men n\u00e5r du fors\u00f8ger at overf\u00f8re et system, der har v\u00e6ret i produktion i mange \u00e5r, til nye spor, st\u00f8der du straks p\u00e5 en lang r\u00e6kke problemer: det er ikke nemt at presse det hele ind i containere og implementere det p\u00e5 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\u00e6re kaskadesvigt? Service Mesh hj\u00e6lper med at l\u00f8se nogle af disse problemer og letter overgangen fra en gammel arkitektur til en ny ved at sikre, at man kan glemme logikken bag netv\u00e6rksudvekslingen.<\/p>\nHvorfor er tilpasning af Service Mesh n\u00f8dvendig<\/h2>\n
\nI vores virksomhed lever mange systemer og moduler side om side, og runtime er meget belastet. S\u00e5 en simpel skabelon, hvor et system kalder et andet og modtager et svar, er ikke tilstr\u00e6kkelig, fordi vi i produktion \u00f8nsker mere. Hvad mere er n\u00f8dvendigt fra et virksomhedsm\u00e6ssigt Service Mesh? <\/p>\n
Begivenhedsbehandlingsservice<\/h3>\n \nLad os forestille os, at vi skal lave real-time event processing \u2014 et system, der i realtid analyserer kundens handlinger og straks kan give et relevant tilbud. For at realisere en s\u00e5dan funktionalitet bruges en arkitektonisk skabelon kaldet event-driven architecture (EDA)<\/i>. Ingen eksisterende Service Mesh underst\u00f8tter s\u00e5danne skabeloner nativt, og det er meget vigtigt, is\u00e6r for en bank!<\/p>\n
Det er temmelig underligt, at \"remote procedure call\" (RPC) underst\u00f8ttes 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\u00f8r unikke ting i forhold til kundeoplevelsen.<\/p>\n
Vores Enterprise Service Mesh skal l\u00f8se dette problem. Derudover \u00f8nsker vi at se implementeringen af garanteret levering, streaming og kompleks begivenhedsbehandling med brug af forskellige filtre og skabeloner.<\/p>\n
Filoverf\u00f8rselsservice<\/h3>\n \nUdover EDA ville det v\u00e6re godt at have mulighed for at overf\u00f8re filer: i Enterprise er filintegration ofte den eneste mulighed. Det arkitektoniske m\u00f8nster ETL (Extract, Transform, Load \u2014 \"udtr\u00e6k, transformere, indl\u00e6se\") anvendes i s\u00e5danne situationer. Her udveksles alle normalt udelukkende filer: store datam\u00e6ngder, som det ikke er hensigtsm\u00e6ssigt at sende med separate foresp\u00f8rgsler. Muligheden for nativ underst\u00f8ttelse af filoverf\u00f8rsel i Enterprise Service Mesh giver den n\u00f8dvendige fleksibilitet for virksomheden.<\/p>\n
Orkestreringstjeneste<\/h3>\n \nI store organisationer er der n\u00e6sten 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\u00e5danne tilf\u00e6lde. Det er forskellige mennesker, forskellige teams, der skaber deres egne produkter, udvikler deres egne API'er og stiller dem til r\u00e5dighed for andre. Ofte opst\u00e5r der et behov for at samle disse tjenester og implementere en kompleks logik for sekventiel kald til et s\u00e6t af API'er. For at l\u00f8se dette problem er der brug for en l\u00f8sning i integrationslaget, der g\u00f8r det muligt at forenkle al denne kompositlogik (kald af flere API'er, beskrivelse af foresp\u00f8rgselsruter osv.). Det er her orkestreringstjenesten i Enterprise Service Mesh kommer ind i billedet.<\/p>\n
AI og ML<\/h3>\n \nN\u00e5r mikrotjenester kommunikerer gennem et f\u00e6lles integrationslag, ved Service Mesh naturligvis alt om kald til hver tjeneste. Vi indsamler telemetri: hvem der har kaldt hvem, hvorn\u00e5r, hvor l\u00e6nge, hvor mange gange osv. N\u00e5r der er hundredtusindvis af disse tjenester, og kaldt er milliarder, akkumuleres alt dette og danner Big Data. Disse data kan analyseres ved hj\u00e6lp af AI, maskinl\u00e6ring osv., og derefter kan der laves nyttige ting baseret p\u00e5 analyse-resultaterne. Det ville v\u00e6re passende at overlade kontrol over al denne netv\u00e6rkstrafik og app-kald, der er integreret i Service Mesh, delvist til kunstig intelligens.<\/p>\n
API Gateway tjeneste<\/h3>\n \nSom regel er der i Service Mesh proxy'er og tjenester, der interagerer med hinanden inden for en betroet gr\u00e6nse. Men der findes ogs\u00e5 eksterne interessenter. Kravene til API'er, der gives til denne gruppe forbrugere, er langt mere seri\u00f8se. Denne opgave opdeles i to hoveddele. <\/p>\n
\nSikkerhed<\/i>. Sp\u00f8rgsm\u00e5l relateret til ddos, s\u00e5rbarheder i protokoller, applikationer, operativsystemer osv. \n<\/li>\nSt\u00f8rrelser<\/i>. N\u00e5r antallet af API-konti, der skal udleveres til kunderne, g\u00e5r op i tusinder eller endda hundredtusinder, opst\u00e5r behovet for et v\u00e6rkt\u00f8j til at administrere denne API-samling. Det er n\u00f8dvendigt at overv\u00e5ge 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\u00f8re hele processe administreret og sikker. Takket v\u00e6re denne komponent l\u00e6rer Enterprise Service Mesh uden un\u00f8dvendig besv\u00e6r at publicere b\u00e5de interne og eksterne API\u2019er.\n<\/li>\n<\/ul>\n <\/p>\n
Service til underst\u00f8ttelse af specifikke protokoller og dataformater (API-gateway)<\/h3>\n \nI \u00f8jeblikket kan de fleste Service Mesh-l\u00f8sninger kun arbejde nativt med HTTP- og HTTP2-trafik eller i en begr\u00e6nset tilstand p\u00e5 TCP\/IP-niveau. Enterprise Service Mesh har mange andre meget specifikke datatransmissionsprotokoller. Nogle systemer kan bruge meddelelsesbrokere, mens andre er integreret p\u00e5 databasesniveau. Hvis virksomheden har SAP, kan det ogs\u00e5 anvende sit eget integrationssystem. Alt dette fungerer, og det er en vigtig del af forretningen.<\/p>\n
Man kan ikke bare sige: \"Lad os opgive legacy og lave nye systemer, der kan bruge Service Mesh\". For at f\u00e5 alle de gamle systemer til at fungere sammen med de nye (p\u00e5 mikrotjenestearkitektur), vil systemer, der kan bruge Service Mesh, have brug for en eller anden adapter, mellemliggende enhed, gateway. Enig, det ville v\u00e6re rart, hvis det blev leveret i boksen sammen med servicen. API-gatewayen kan lige netop underst\u00f8tte enhver form for integration. T\u00e6nk p\u00e5 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.<\/p>\n
S\u00e5dan forestiller vi os den virksomhedsversion af Service Mesh (Enterprise Service Mesh). Den beskrevne tilpasning l\u00f8ser de fleste problemer, der opst\u00e5r, n\u00e5r man fors\u00f8ger at bruge de f\u00e6rdige open-source versioner af integrationsplatformen. Service Mesh-arkitekturen, som kun har eksisteret i et par \u00e5r, forts\u00e6tter med at udvikle sig, og vi er glade for, at vi kan bidrage til dens udvikling. Vi h\u00e5ber, at vores erfaring vil v\u00e6re nyttig for dig.<\/i>habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"Service Mesh \u2014 \u0438\u0437\u0432\u0435\u0441\u0442\u043d\u044b\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u043d\u044b\u0439 \u043f\u0430\u0442\u0442\u0435\u0440\u043d \u0434\u043b\u044f \u0438\u043d\u0442\u0435\u0433\u0440\u0430\u0446\u0438\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0438 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0430 \u043d\u0430 \u043e\u0431\u043b\u0430\u0447\u043d\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u0432 \u043e\u0431\u043b\u0430\u0447\u043d\u043e-\u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043d\u043e\u043c \u043c\u0438\u0440\u0435 \u043e\u0431\u043e\u0439\u0442\u0438\u0441\u044c \u0431\u0435\u0437 \u043d\u0435\u0433\u043e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u043e. \u041d\u0430 \u0440\u044b\u043d\u043a\u0435 \u0443\u0436\u0435 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e open-source \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0439 service mesh, \u043d\u043e \u0438\u0445 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u043e\u0441\u0442\u0438, \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 \u0434\u0430\u043b\u0435\u043a\u043e \u043d\u0435 \u0432\u0441\u0435\u0433\u0434\u0430 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043a\u043e\u0433\u0434\u0430 \u0440\u0435\u0447\u044c \u0438\u0434\u0435\u0442 \u043e \u0442\u0440\u0435\u0431\u043e\u0432\u0430\u043d\u0438\u044f\u0445 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u0444\u0438\u043d\u0430\u043d\u0441\u043e\u0432\u044b\u0445 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0439 \u043c\u0430\u0441\u0448\u0442\u0430\u0431\u0430 \u0432\u0441\u0435\u0439 \u0441\u0442\u0440\u0430\u043d\u044b. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26549,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35388","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Hvorfor](\"\/wp-content\/uploads\/2019\/06\/90b0df34323399c96548f86b6bd16522.jpg\")