Note. iwwersat.: Service Mesh ass e Phänomen deen nach keng stabil Iwwersetzung op Russesch huet (viru méi wéi 2 Joer hu mir d'Optioun "Mesh fir Servicer" proposéiert, an e bësse méi spéit hunn e puer Kollegen ugefaang d'Kombinatioun "Service Sieve" aktiv ze promoten). Konstant Diskussioun iwwer dës Technologie huet zu enger Situatioun gefouert, an där d'Marketing an d'technesch Komponenten ze enk matenee verbonne sinn. Dëst wonnerschéint Material vun engem vun den Auteuren vum urspréngleche Begrëff ass geduecht fir d'Ingenieuren an anerer Kloerheet ze bidden.
Comic aus
Aféierung
Wann Dir e Software-Ingenieur sidd, deen iergendwou am Backend Systemraum schafft, ass de Begrëff "Service Mesh" wahrscheinlech scho fest an Ärem Kapp an de leschte Joeren agebonne ginn. Dank engem komeschen Zoufall iwwerhëlt dëse Saz d'Industrie ëmmer méi, an den Hype an d'Promotiounsoffer, déi domat verbonne sinn, wuessen wéi e Schnéiball, deen erof flitt a weist keng Zeeche vu Verlängerung.
Service Mesh gouf am däischteren, biased Waasser vum Wollek gebierteg Ökosystem gebuer. Leider heescht dat, datt vill vun der Kontrovers ronderëm et rangéiert vun "Kalorie-Kalorie-Gespréich" bis - fir en technesche Begrëff ze benotzen - direkten Nonsens. Awer wann Dir duerch all de Kaméidi geschnidden hutt, fannt Dir datt de Service Mesh eng ganz reell, definéiert a wichteg Funktioun huet.
An dësem Post probéieren ech just dat ze maachen: liwwert en éierlechen, am-Déift, Ingenieur-fokusséierte Guide fir Service Mesh. Ech wäert net nëmmen d'Fro beäntweren: "Wat ass et?", - awer och "Firwat?", wéi och "Firwat elo?". Schlussendlech wäert ech probéieren ze beschränken firwat (a menger Meenung no) dës speziell Technologie sou eng verréckt Opreegung gesuergt huet, wat eng interessant Geschicht u sech ass.
Wat ech
Moien alleguer! Mäin Numm ass . Ech sinn ee vun de Schëpfer — den alleréischten Service Mesh-Projet an de Projet, dee fir d'Erscheinung vum Begrëff Schold ass Service Mesh gemaach wéi esou (sorry Kärelen!). (Note Iwwersetzung.: Iwwregens, um Sonnenopgang vun der Erscheinung vun dësem Begrëff, viru méi wéi 2,5 Joer, hu mir schonn dat fréit Material vum selwechten Auteur mam Titel iwwersat "".) Ech och Kapp ass e Startup deen cool Service Mesh Saachen wéi Linkerd an .
Dir kënnt wahrscheinlech roden datt ech eng ganz partizipativ a subjektiv Meenung zu dësem Thema hunn. Wéi och ëmmer, ech wäert probéieren Bias op e Minimum ze halen (mat Ausnam vun enger Sektioun: "Firwat gëtt et sou vill iwwer Service Mesh geschwat?", - an deem ech nach meng virgefaasst Iddien deelen). Ech wäert och mäi Bescht maachen fir dëse Guide esou objektiv wéi méiglech ze maachen. Fir spezifesch Beispiller wäert ech virun allem op Linkerd seng Erfahrung vertrauen, wärend ech op Differenzen weisen (wann iwwerhaapt) déi ech kennen an der Ëmsetzung vun anere Servicemesh-Typen.
Okay, Zäit fir op d'Goodies ze goen.
Wat ass e Service Mesh?
Trotz allen Hype ass d'Struktur vum Service Mesh ganz einfach. Dëst ass just eng Rëtsch Userspace Proxyen, déi "nieft" de Servicer sinn (mir schwätzen e bëssen iwwer wat "nächst" méi spéit ass), plus eng Rei vu Kontrollprozesser. D'Proxyen ginn kollektiv genannt daten Fliger, an d'Kontrollprozesser ginn genannt Kontroll Fliger. D'Daten Fliger interceptéiert Uriff tëscht Servicer a mécht "all Zorte vu verschiddene Saachen" mat hinnen; De Kontrollebene koordinéiert deementspriechend d'Behuele vum Proxy a bitt Iech Zougang, d.h. Bedreiwer, op d'API, fir datt d'Netzwierk als Ganzt manipuléiert a gemooss gëtt.
Wéi eng Proxy ass dëst? Dëst ass e Layer 7-bewosst TCP Proxy (dh "berécksiichtegt" Layer 7 vum OSI Modell) wéi HAProxy an NGINX. Dir kënnt e Proxy op Är Wënsch wielen; Linkerd benotzt e Rust Proxy, einfach genannt . Mir hunn et speziell fir Service Mesh gemaach. Aner Meshen léiwer aner Proxyen (Envoy ass eng gemeinsam Wiel). Wéi och ëmmer, e Proxy auswielen ass just eng Fro vun der Ëmsetzung.
Wat maachen dës Proxy Serveren? Selbstverständlech, si Proxy Uruff un a vu Servicer (strikt geschwat, si handelen als Proxyen an ëmgedréint Proxyen, behandelen souwuel erakommen an ausgaang Uriff). A si implementéieren e Feature-Set deen sech op Uriff konzentréiert tëscht dem Servicer. Dëse Fokus op Traffic tëscht Servicer ass wat e Service Mesh Proxy ënnerscheet vun, soen, API Gateways oder Ingress Proxies (déi lescht konzentréiere sech op Uriff déi an de Stärekoup vun der Äussewelt kommen). (Note. iwwersat.: Fir e Verglach vun existente Ingress Controller fir Kubernetes, vill vun deenen de scho genannten Envoy benotzen, kuckt .)
Also, mir hunn den Datefliger zortéiert. D'Kontrollplan ass méi einfach: et ass e Set vu Komponenten déi all d'Mechanik ubidden, déi den Datefliger brauch fir op eng koordinéiert Manéier ze bedreiwen, inklusiv Serviceentdeckung, ausginn TLS Zertifikater, metresch Aggregatioun, etc. D'Dateplan informéiert de Kontrollplang säi Verhalen; am Tour, der Kontroll Fliger stellt eng API datt Dir d'Behuele vun der Daten Fliger als Ganzt änneren an Monitor erlaabt.
Drënner ass en Diagramm vum Kontrollplang an Datefliger zu Linkerd. Wéi Dir gesitt, enthält de Kontrollplan e puer verschidde Komponenten, dorënner eng Prometheus Instanz déi Metriken vu Proxy-Server sammelt, souwéi aner Komponenten wéi z. destination (Service Entdeckung), identity (Zertifikat Autoritéit, CA) an public-api (Endpunkte fir Web an CLI). Am Géigesaz, ass den Datefliger en einfachen Linkerd-Proxy nieft der Applikatioun Instanz. Dëst ass just eng Logik Diagramm; An enger realer Welt Deployment, hutt Dir vläicht dräi Repliken vun all Kontrollplanekomponent an Honnerte oder Dausende vu Proxyen am Datefliger.
(Déi blo Rechtecker an dësem Diagramm symboliséieren d'Grenze vu Kubernetes Pods. Dir kënnt gesinn datt d'Container mat linkerd-Proxy am selwechte Pod sinn wéi d'Applikatiounsbehälter. Dëst Schema ass bekannt als Sidecar Container.)
Service Mesh Architektur huet verschidde wichteg Implikatiounen. Als éischt, well d'Aufgab vun engem Proxy ass Uriff tëscht Servicer z'ënnerscheeden, mécht e Service Mesh nëmme Sënn wann Är Applikatioun fir e bestëmmte Set vu Servicer erstallt gouf. Mesh kënnen benotzt mat Monolithen, awer dëst ass kloer iwwerflësseg fir een eenzege Proxy, a seng Funktionalitéit ass onwahrscheinlech gefuerdert.
Eng aner wichteg Konsequenz ass datt de Service Mesh erfuerdert riseg Zuel vu Proxyen. Tatsächlech befestegt Linkerd e Linkerd-Proxy un all Instanz vun all Service (aner Implementatioune fügen e Proxy un all Node/Host/Virtuell Maschinn dobäi. Dat ass souwisou vill). Esou aktiv Notzung vu Proxyen u sech selwer huet eng Rei zousätzlech Komplikatiounen:
- Proxyen am Dateplang musse sinn séier, well fir all Uruff ginn et e puer Uruff un de Proxy: een op der Client Säit, een op der Server Säit.
- Och Proxyen solle sinn kleng и liicht. Jidderee wäert Erënnerung an CPU Ressourcen konsuméieren, an dëse Konsum wäert linear mat der Applikatioun wuessen.
- Dir braucht e Mechanismus fir eng grouss Zuel vu Proxyen z'installéieren an ze aktualiséieren. Manuell maachen ass keng Optioun.
Am Allgemengen gesäit e Service Mesh esou aus (op d'mannst aus engem Vugelperspektiv): Dir setzt eng Rëtsch Userspace Proxyen aus, déi "eppes maachen" mam internen, inter-Service Traffic, a benotzt e Kontrollfliger fir se ze iwwerwaachen an ze verwalten.
Elo ass et Zäit d'Fro ze stellen "Firwat?"
Wat ass e Service Mesh fir?
Déi, déi fir d'éischt d'Iddi vun engem Service Mesh begéint hunn, kéinte verginn ginn fir e bëssen trepidatious ze fillen. De Service Mesh Design heescht datt et net nëmmen d'Latenz an der Applikatioun erhéicht, awer och verbrauchen Ressourcen an wäert addéieren eng Rëtsch nei Mechanismen an der Infrastruktur. Als éischt setzt Dir e Service Mesh op, an dann op eemol fannt Dir datt Dir Honnerte (wann net Dausende) Proxyen braucht. D'Fro ass, wien wäert dat fräiwëlleg maachen?
D'Äntwert op dës Fro huet zwee Deeler. Als éischt kënnen d'Transaktiounskäschte verbonne mat der Aussetzung vun dëse Proxyen wesentlech reduzéiert ginn duerch e puer Ännerungen am Ökosystem (méi méi spéit).
Zweetens, en Apparat wéi dësen ass tatsächlech e super Wee fir zousätzlech Logik an de System aféieren. Net nëmme well e Service Mesh vill nei Funktionalitéit addéiere kann, awer och well et ka gemaach ginn ouni den Ökosystem ze stéieren. Tatsächlech baséiert de ganze Service Mesh Modell op dëser Viraussetzung: an engem Multiservice System, egal wéi mécht individuell Servicer, Verkéier tëscht hinnen ass den ideale Punkt fir Funktionalitéit ze addéieren.
Zum Beispill, a Linkerd (wéi an de meeschte Meshes) ass d'Funktionalitéit haaptsächlech op HTTP-Uriff konzentréiert, dorënner HTTP/2 a gRPC *. D'Funktionalitéit ass zimlech räich - et kann an dräi Klassen opgedeelt ginn:
- Fonctiounen Zesummenhang mat Zouverlässegkeet. Widderholl Ufroen, Timeouts, Kanaresch Approche (Traffic Split / Viruleedung), etc.
- Fonctiounen Zesummenhang mat Iwwerwachung. Aggregatioun vun Succès Tariffer, Verspéidungen an Ufro Bänn fir all Service oder eenzel Richtungen; Bau vun topologesche Kaarte vu Servicer, etc.
- Fonctiounen Zesummenhang mat Sécherheet. Géigesäiteg TLS, Zougang Kontroll, etc.
* Aus Linkerd senger Siicht ass gRPC praktesch net anescht wéi HTTP/2: et benotzt just Protobuf an der Notzlaascht. Aus der Siicht vum Entwéckler sinn déi zwou Saachen natierlech anescht.
Vill vun dëse Mechanismen funktionnéieren um Ufroniveau (also de "L7 Proxy"). Zum Beispill, wann de Foo-Service en HTTP-Uruff un de Bar-Service mécht, kann de Linkerd-Proxy op der Foo-Säit intelligent Belaaschtung ausféieren an Uruff vu Foo zu Bar-Instanzen op Basis vun der observéierter Latenz maachen; et kann d'Ufro widderhuelen wann néideg (a wann et idempotent ass); et kann den Äntwertcode an den Timeout ophuelen, asw. Ähnlech kann linkerd-Proxy op der Bar Säit eng Demande refuséieren wann et net erlaabt ass oder d'Ufrolimit iwwerschratt ass; kann eng Verspéidung vu senger Säit ophuelen, etc.
Proxyen kënnen och um Verbindungsniveau "eppes maachen". Zum Beispill, linkerd-Proxy op der Foo Säit kann eng TLS Verbindung initiéieren, an linkerd-Proxy op der Bar Säit kann et ofschléissen, a béid Säiten kënnen all aner TLS Zertifikater verifizéieren *. Dëst bitt net nëmmen Verschlësselung tëscht Servicer, awer och eng kryptographesch sécher Manéier fir Servicer z'identifizéieren: Foo a Bar kënnen "beweisen" datt se sinn wien se soen datt se sinn.
* "Géigesäitege vun engem Frënd" heescht datt de Client Zertifikat och verifizéiert ass (géigesäitege TLS). Am "klassesche" TLS, zum Beispill tëscht engem Browser an engem Server, gëtt de Certificat vun nëmmen enger Säit (de Server) normalerweis verifizéiert.
Egal ob se op Ufro oder Verbindungsniveau funktionnéieren, ass et wichteg ze betounen datt all Service Mesh Funktiounen sinn operationell Charakter. Linkerd ass net fäeg d'Semantik vun der Notzlaascht ze transforméieren - zum Beispill Felder an e JSON Fragment bäizefügen oder Ännerungen op Protobuf ze maachen. Mir schwätzen iwwer dës wichteg Feature méi spéit wa mir iwwer ESB a Middleware schwätzen.
Dëst ass de Set vu Funktiounen déi e Service Mesh bitt. D'Fro stellt sech: firwat se net direkt an der Applikatioun ëmsetzen? A firwat iwwerhaapt mat engem Proxy beméien?
Firwat Service Mesh ass eng gutt Iddi
Wärend d'Kapazitéite vun engem Service Mesh spannend sinn, läit säi Kärwäert eigentlech net a senge Funktiounen. Um Enn mir Kann implementéiert se direkt an der Applikatioun (mir wäerte spéider gesinn datt dëst den Urspronk vum Service Mesh war). Fir ze probéieren et an engem Saz ze summéieren, ass de Wäert vun engem Service Mesh: et bitt Feature kritesch fir modern Serversoftware op eng konsequent Manéier iwwer de ganze Stack an onofhängeg vum Applikatiounscode ze lafen.
Loosst eis dës Propositioun analyséieren.
«Features kritesch fir modern Serversoftware ze lafen" Wann Dir eng Transaktiounsserverapplikatioun erstellt, déi mam ëffentlechen Internet ugeschloss ass, Ufroe vun der Äussewelt akzeptéiert a bannent kuerzer Zäit op se reagéiert - zum Beispill eng Webapplikatioun, en API Server, an déi grouss Majoritéit vun anere modernen Uwendungen - a wann Dir et als Set vu Servicer implementéiert, déi synchron mateneen interagéieren, a wann Dir dës Software dauernd upgradéiert, nei Features bäidréit, a wann Dir gezwongen sidd dëse System an engem funktionnéierenden Zoustand während dem Modifikatiounsprozess z'erhalen - an dësem Fall, Gratulatioun, Dir schafen modern Server Software. An all dës super Features, déi hei uewen opgezielt sinn, ginn tatsächlech kritesch fir Iech. D'Applikatioun muss zouverlässeg, sécher sinn, an Dir musst fäeg sinn ze observéieren wat se mécht. Dëst si genau d'Froen déi Service Mesh hëlleft ze léisen.
(OK, de viregte Paragraf enthält nach ëmmer meng Iwwerzeegung datt dës Approche de modernen Wee ass fir Serversoftware ze kreéieren. Anerer entwéckelen léiwer Monolithen, "reaktive Mikroservicer" an aner Saachen déi net ënner der Definitioun hei uewen falen. Dës Leit hunn wahrscheinlech hir D'Meenung ass anescht wéi meng. Ech mengen am Géigendeel datt se "falsch" sinn - obwuel op jidde Fall de Service Mesh fir si net ganz nëtzlech ass).
«Uniform fir de ganze Stack" D'Funktionalitéit vun engem Service Mesh ass net nëmme missionskritesch. Si gëllen fir all Servicer an der Applikatioun, onofhängeg vun wéi enger Sprooch se geschriwwen sinn, a wéi engem Kader se benotzt ginn, wien se geschriwwen huet, wéi se ofgesat goufen, an all aner Subtletien vun hirer Entwécklung a Gebrauch.
«Onofhängeg vum Applikatiounscode" Schlussendlech bitt e Service Mesh net nëmmen konsequent Funktionalitéit iwwer de ganze Stack, et mécht dat op eng Manéier déi d'Applikatioun net erfuerdert ze änneren. D'fundamental Basis vun der Service Mesh Funktionalitéit, dorënner Aufgaben fir Konfiguratioun, Aktualiséierung, Operatioun, Ënnerhalt, etc., wunnt ganz um Plattformniveau an ass onofhängeg vun der Applikatioun. D'Applikatioun kann änneren ouni de Service Mesh ze beaflossen. Am Tour kann de Service Mesh ouni Participatioun vun der Applikatioun änneren.
Kuerz gesot, e Service Mesh bitt net nëmme vital Funktionalitéit, mee mécht dat och op eng global, eenheetlech an Applikatioun-onofhängeg Manéier. An dofir, obwuel Service Mesh Funktionalitéit am Service Code ëmgesat ka ginn (zum Beispill, als Bibliothéik an all Service abegraff), wäert dës Approche net d'Uniformitéit an d'Onofhängegkeet ubidden, déi sou wäertvoll ass am Fall vun engem Service Mesh.
An alles wat Dir maache musst ass eng Rëtsch Proxyen ze addéieren! Ech verspriechen, mir wäerte ganz séier d'Operatiounskäschte kucken, déi mat der Zousatz vun dëse Proxyen verbonne sinn. Awer loosst eis als éischt ophalen a kucken op dës Iddi vun der Onofhängegkeet aus verschiddene Perspektiven. vu Leit.
Wien hëlleft Service Mesh?
Wéi onbequem wéi et kann sinn, fir datt eng Technologie e wichtege Bestanddeel vum Ökosystem gëtt, muss se vu Leit ugeholl ginn. Also wien ass fir Service Mesh interesséiert? Wien profitéiert vu senger Benotzung?
Wann Dir modern Server Software entwéckelt, kënnt Dir ongeféier un Äert Team als Grupp denken Service Besëtzerdéi zesummen Affär Logik entwéckelen an ëmsetzen, an Plattform Besëtzer, Entwécklung vun der interner Plattform op där dës Servicer funktionnéieren. A klengen Organisatiounen kënnen dës déiselwecht Leit sinn, awer wéi d'Firma wiisst, tendéieren dës Rollen méi ausgeschwat ze ginn an och an Ënnerrollen opgedeelt ... (Et gëtt hei vill ze soen iwwer d'Verännerung vun der Natur vun Devops, den organisatoreschen Impakt vu Mikroservicer, asw.) n. Awer elo huelen mir dës Beschreiwunge wéi uginn).
Aus dëser Siicht sinn déi kloer Beneficer vum Service Mesh d'Plattformbesëtzer. No allem ass et schlussendlech d'Zil vum Plattformteam eng intern Plattform ze kreéieren op där Servicebesëtzer d'Geschäftslogik kënne implementéieren an dat op eng Manéier maachen déi garantéiert datt se sou onofhängeg wéi méiglech sinn vun den düsteren Detailer vu senger Operatioun. Net nëmmen bitt e Service Mesh Fäegkeeten kritesch fir dëst Zil z'erreechen, et mécht dat op eng Manéier déi am Tour keng Ofhängegkeete vun de Servicebesëtzer setzt.
D'Besëtzer vum Service profitéieren och, obwuel op eng méi indirekt Manéier. D'Zil vum Servicebesëtzer ass sou produktiv wéi méiglech ze sinn fir d'Logik vum Geschäftsprozess ëmzesetzen, a wat manner hien iwwer operationell Themen Suergen muss maachen, wat besser. Amplaz mat der Ëmsetzung ze këmmeren, soen, Retry Politiken oder TLS, kënne se sech eleng op Geschäftsziler konzentréieren an hoffen datt d'Plattform sech ëm de Rescht këmmert. Dëst ass e grousse Virdeel fir si.
Den organisatoresche Wäert vun esou enger Divisioun tëscht de Besëtzer vu Plattformen a Servicer kann net iwwerschätzt ginn. Ech mengen si bäidréit den Haapt Bäitrag zum Wäert vum Service Mesh.
Mir hunn dës Lektioun geléiert wéi e fréie Linkerd Fan eis gesot huet firwat se Service Mesh gewielt hunn: well et hinnen erlaabt huet "de schwätzende Buttek op e Minimum ze halen." Hei sinn e puer Detailer: d'Kärelen vun enger grousser Firma hunn hir Plattform op Kubernetes migréiert. Well d'Applikatioun sensibel Informatioun gehandhabt huet, wollte se all Kommunikatioun iwwer d'Cluster verschlësselen. Wéi och ëmmer, d'Situatioun war komplizéiert duerch d'Präsenz vun Honnerte vu Servicer an Honnerte vun Entwécklungsteams. D'Perspektiv jidderengem ze kontaktéieren an ze iwwerzeegen TLS Ënnerstëtzung an hire Pläng opzehuelen huet se guer net glécklech gemaach. No der Installatioun vun Linkerd, si transferéiert Haftung vun Entwéckler (aus der Siicht vun deenen dëst onnéideg Ierger war) bis Plattformer, fir déi dëst eng Top-Level Prioritéit war. An anere Wierder, Linkerd huet fir si net sou vill en technesche Problem wéi en organisatoreschen geléist.
Kuerz gesot, e Service Mesh ass méi eng Léisung, net eng technesch, awer sozio-technesch Problemer. (Merci fir d'Aféierung vun dësem Begrëff.)
Wäert e Service Mesh all meng Problemer léisen?
Jo. Ech mengen, nee!
Wann Dir déi dräi Klassen vu Featuren kuckt, déi hei uewen beschriwwe sinn - Zouverlässegkeet, Sécherheet an Observabilitéit - gëtt et kloer datt e Servicemesh keng komplett Léisung fir eng vun dëse Probleemer ass. Wärend Linkerd kann Ufroe nei ausginn (wann et weess datt se idempotent sinn), ass et net fäeg Entscheedungen ze treffen iwwer wat fir de Benotzer zréckzekommen wann de Service permanent gescheitert ass - dës Entscheedunge musse vun der Applikatioun gemaach ginn. Linkerd kann Statistike vun erfollegräichen Ufroe behalen, awer et ass net fäeg an de Service ze kucken a seng intern Metriken ubidden - d'Applikatioun muss sou Tools hunn. An obwuel Linkerd fäeg ass mTLS z'organiséieren, erfuerderen vollwäerteg Sécherheetsléisungen vill méi.
Eng Ënnergrupp vun de Funktiounen an dëse Beräicher, déi vum Service Mesh ugebuede ginn, bezéien sech op Plattform Fonctiounen. Mat dësem mengen ech Funktiounen déi:
- Onofhängeg vun der Geschäftslogik. D'Art a Weis wéi Uruffhistogramme tëscht Foo a Bar konstruéiert sinn ass komplett onofhängeg vun firwat Foo rifft Bar.
- Schwéier richteg ëmzesetzen. Zu Linkerd ginn d'Wiederprobe mat all Zorte vu flotte Saachen parametriséiert wéi d'Retry Budgeten (Budgeten nei probéieren), well eng onsophistikéiert, direkt Approche fir sou Saachen ëmzesetzen wäert sécherlech zu der Entstoe vun enger sougenannter "Avalanche vun Ufroen" féieren. (probéiere Stuerm) an aner Problemer charakteristesche vun verdeelt Systemer.
- Am meeschten effikass wann eenheetlech applizéiert. Den TLS Mechanismus mécht nëmme Sënn wann et iwwerall applizéiert gëtt.
Zënter datt dës Funktiounen um Proxy-Niveau ëmgesat ginn (an net um Applikatiounsniveau), liwwert de Service Mesh se op der Plattform, net Uwendungen. Also ass et egal a wéi enger Sprooch d'Servicer geschriwwen sinn, a wéi engem Kader se benotzen, wien se geschriwwen huet a firwat. Proxies funktionnéieren ausserhalb vun all dësen Detailer, an d'fundamental Basis vun dëser Funktionalitéit, dorënner Aufgaben fir Konfiguratioun, Aktualiséierung, Operatioun, Ënnerhalt, etc., läit eleng um Plattformniveau.
Beispiller vu Service Mesh Fäegkeeten
Fir ze resuméieren, ass e Service Mesh keng komplett Léisung fir Zouverlässegkeet, Observabilitéit oder Sécherheet. Den Ëmfang vun dëse Beräicher erfuerdert d'Participatioun vu Servicebesëtzer, Ops / SRE Teams an aner Firmenentitéiten. De Service Mesh bitt nëmmen e Plattformniveau "Slice" fir all vun dëse Beräicher.
Firwat ass Service Mesh elo populär ginn?
Bis elo frot Dir Iech wahrscheinlech: ok, wann de Service Mesh sou gutt ass, firwat hu mir net ugefaang Millioune Proxyen am Stack virun zéng Joer z'installéieren?
Et gëtt eng banal Äntwert op dës Fro: virun zéng Joer huet jiddereen Monolithen gebaut, a kee brauch e Service Mesh. Dëst ass richteg, awer menger Meenung no verpasst dës Äntwert de Punkt. Och virun XNUMX Joer gouf d'Konzept vu Mikroservicer als villverspriechend Manéier fir grouss Systemer ze bauen vill diskutéiert a bei Firmen wéi Twitter, Facebook, Google an Netflix applizéiert. Déi allgemeng Vue - op d'mannst an den Deeler vun der Industrie mat deenen ech a Kontakt komm sinn - war datt Mikroservicer de "richtege Wee" waren fir grouss Systemer ze bauen, och wann et verdammt schwéier war.
Natierlech, och wann et virun zéng Joer Firme ware Mikroservicer operéieren, hunn se net Proxyen iwwerall festgehalen, fir e Servicemesh ze bilden. Wéi och ëmmer, wann Dir genau kuckt, hunn se eppes ähnlech gemaach: vill vun dëse Firmen hunn d'Benotzung vun enger spezieller interner Bibliothéik fir Netzwierkkommunikatioun gebraucht (heiansdo eng déck Clientbibliothéik genannt, Fett Client Bibliothéik).
Netflix hat Hysterix, Google hat Stubby, Twitter hat d'Finagle Bibliothéik. Finagle, zum Beispill, war obligatoresch fir all neie Service op Twitter. Et huet souwuel de Client wéi och Server Säit vu Verbindungen gehandhabt, erlaabt fir widderholl Ufroen, ënnerstëtzt Ufro Routing, Laaschtbalancéierung a Miessung. Et huet eng konsequent Schicht vun Zouverlässegkeet an Observabilitéit iwwer de ganzen Twitter Stack geliwwert, onofhängeg vun deem wat de Service gemaach huet. Natierlech huet et nëmme fir JVM Sproochen geschafft a baséiert op engem Programméierungsmodell dee fir déi ganz Applikatioun benotzt muss ginn. Wéi och ëmmer, seng Funktionalitéit war bal d'selwecht wéi déi vum Service Mesh. (Tatsächlech war déi éischt Versioun vu Linkerd einfach Finagle a Proxyform gewéckelt.)
Also, virun zéng Joer goufen et net nëmme Mikroservicer, awer och speziell Proto-Service-Mesh-Bibliothéiken, déi déiselwecht Probleemer geléist hunn, déi de Service-Mesh haut léisen. Wéi och ëmmer, de Service Mesh selwer gouf deemools net existéiert. Et huet misse nach eng Verréckelung sinn ier si opgetaucht ass.
An dat ass wou déi méi déif Äntwert läit, verstoppt an enger anerer Ännerung déi an de leschten 10 Joer geschitt ass: d'Käschte fir Mikroservicer z'installéieren sinn dramatesch erofgaang. Déi uewe genannte Firmen déi viru zéng Joer Mikroservicer benotzt hunn - Twitter, Netflix, Facebook, Google - ware Firme vun enormer Skala an enorme Ressourcen. Si haten net nëmmen de Besoin, awer och d'Fäegkeet fir grouss Mikroservicer-baséiert Uwendungen ze bauen, z'installéieren an ze bedreiwen. D'Energie an d'Ustrengung déi Twitter Ingenieuren setzen fir vun enger monolithescher op eng Mikroservicer Approche ze plënneren ass erstaunlech. (Fir fair ze sinn, sou ass de Fakt datt et gelongen ass.) Dës Zort vun infrastrukturell Manövere waren dann onméiglech fir kleng Betriber.
Schnell no vir an d'Presentatioun. Et gi Startups haut wou de Verhältnis vu Mikroservicer zu Entwéckler 5:1 ass (oder souguer ), a wat méi ass, si këmmeren sech mat hinnen erfollegräich! Wann e 5-Persoun Startup einfach 50 Mikroservicer operéiere kann, dann huet eppes kloer d'Käschte vun hirer Ëmsetzung reduzéiert.
1500 Mikroservicer zu Monzo; all Linn ass eng virgeschriwwen Reseau Regel datt Traffic erlaabt
Déi dramatesch Reduktioun vun de Käschte fir Mikroservicer ze bedreiwen ass d'Resultat vun engem Prozess: wuessend Popularitéit vu Container и Orchestrateuren. Dëst ass genee déi déif Äntwert op d'Fro, wat zu der Entstoe vum Service Mesh bäigedroen huet. Déi selwecht Technologie huet souwuel Service Meshes wéi och Mikroservicer attraktiv gemaach: Kubernetes an Docker.
Firwat? Gutt, Docker léist ee grousse Problem - de Verpakungsproblem. Andeems Dir eng Applikatioun a seng (net-Netzwierk) Runtime Ofhängegkeeten an e Container packt, verwandelt Docker d'Applikatioun an eng austauschbar Eenheet déi iwwerall gehost a lafen kann. Zur selwechter Zäit vereinfacht et d'Operatioun immens méisproocheg Stack: Well e Container eng atomar Eenheet vun der Ausféierung ass, fir Deployment an operationell Zwecker, ass et egal wat dobannen ass, sief et eng JVM, Node, Go, Python oder Ruby Applikatioun. Dir lancéiert et just an dat ass et.
Kubernetes hëlt alles op den nächsten Niveau. Elo datt et Tonne vu "Saache fir ze lafen" sinn an Tonne Maschinnen fir se ze lafen, ass et e Besoin fir en Tool dat se matenee korreléiere kann. Am breede Sënn gitt Dir Kubernetes vill Container a vill Maschinnen, an et kartéiert se géinteneen (natierlech ass dëst en dynameschen an ëmmer verännerende Prozess: nei Container beweegen sech ronderëm de System, Maschinnen starten a stoppen , etc. Kubernetes hëlt dëst awer alles Rechnung.
Wann de Kubernetes konfiguréiert ass, sinn d'Zäitkäschte fir ee Service z'installéieren an ze bedreiwen wéineg anescht wéi d'Käschte fir zéng Servicer z'installéieren an ze bedreiwen (tatsächlech ass et bal d'selwecht fir 100 Servicer). Füügt dës Behälter als Verpackungsmechanismus un, dee méisproocheg Implementatioun encouragéiert, an Dir hutt eng ganz Partie vun neien Uwendungen implementéiert a Form vu Mikroservicer geschriwwen a verschiddene Sproochen - genee déi Aart vun Ëmfeld fir déi e Service Mesh sou gutt gëeegent ass.
Also, mir kommen op d'Äntwert op d'Fro firwat d'Iddi vun engem Service Mesh elo populär ginn ass: d'Homogenitéit, déi Kubernetes fir Servicer ubitt, gëllt direkt fir déi operationell Erausfuerderunge mat engem Service Mesh. Dir packt d'Proxyen an Containeren, gitt Kubernetes d'Aufgab fir se ze halen wou et kann, a voila! Als Resultat kritt Dir e Service Mesh, während all d'Mechanik vu senger Détachement vu Kubernetes geréiert gëtt. (Op d'mannst aus engem Vugel Bléck. Natierlech ginn et vill Nuancen zu dësem Prozess.)
Fir et ze resuméieren: De Grond firwat Service Meshes elo populär ginn, an net virun zéng Joer, ass datt Kubernetes an Docker net nëmme wesentlech eropgaange sinn brauch an et, vereinfacht d'Ëmsetzung vun Uwendungen als Sets vu méisproochege Mikroservicer, awer och wesentlech reduzéiert Käschten fir seng Operatioun, suergt Mechanismen fir z'installéieren an z'ënnerstëtzen Sidecar Proxy Flotten.
Firwat gëtt et sou vill iwwer Service Mesh geschwat?
D 'Präventioun: An dëser Rubrik benotzen ech all Zorte vu Viraussetzungen, Vermutungen, Fabrikatiounen an Insiderinformatioun.
Maacht eng Sich no "Service Mesh" an Dir kommt op eng Tonn vu recycléiertem Kaloriegehalt, komesch Projeten an e Kaleidoskop vun der Verzerrung, déi eng Echo Chamber wäert sinn. All ausgefalene nei Technologie mécht dëst, awer am Fall vun engem Service Mesh ass de Problem besonnesch akut. Firwat?
Gutt, en Deel dovun ass meng Schold. Ech hu schwéier geschafft fir Linkerd an de Service Mesh ze promoten all Chance déi ech duerch eng Onmass Blogposten an Artikelen wéi dësen kréien. Awer ech sinn net sou staark. Fir dës Fro wierklech ze beäntweren, musse mir e bëssen iwwer d'Gesamtsituatioun schwätzen. An et ass onméiglech doriwwer ze schwätzen ouni ee Projet ze ernimmen: ass en Open Source Service Mesh entwéckelt gemeinsam vu Google, IBM a Lyft.
(Déi dräi Firmen hu ganz ënnerschiddlech Rollen: Dem Lyft seng Bedeelegung schéngt nëmmen am Numm ze sinn; si sinn d'Auteure vum Envoy, awer benotzen oder huelen net un der Entwécklung vun Istio. IBM ass an der Entwécklung vun Istio involvéiert a benotzt. Google ass aktiv an der Istio involvéiert. Entwécklung , awer benotzt se tatsächlech net sou wäit wéi ech kann soen.)
Den Istio Projet ass bemierkenswäert fir zwou Saachen. Als éischt gëtt et den enorme Marketing Effort, deen Google besonnesch setzt fir se ze promoten. Ech géif schätzen datt déi meescht Leit bewosst vum Service Mesh Konzept haut fir d'éischt iwwer Istio geléiert hunn. Déi zweet Saach ass wéi schlecht Istio krut. An dëser Matière sinn ech selbstverständlech Interessenten, mee probéieren esou objektiv wéi méiglech ze bleiwen, kann ech nach ëmmer net hëllefen , net ganz ënnerscheedend (awer net eenzegaarteg: systemd kënnt an de Kapp, ...) fir en Open Source Projet.
(An der Praxis schéngt Istio Problemer net nëmme mat Komplexitéit an UX ze hunn, mä och mat Leeschtung. Zum Beispill, während An enger Drëtt-Partei-Studie hunn d'Fuerscher Situatiounen fonnt, an deenen dem Istio seng Schwanzlatenz 100 Mol méi héich war wéi déi vun Linkerd, souwéi Ressource-gehungerte Situatiounen, wou Linkerd weider erfollegräich fonktionnéiert huet, während Istio komplett opgehalen huet ze schaffen.)
Ausser meng Theorien iwwer firwat dat geschitt ass, gleewen ech datt déi iwwerwältegend Opreegung ronderëm de Service Mesh duerch d'Participatioun vu Google erkläert gëtt. Nämlech eng Kombinatioun vun den folgenden dräi Faktoren:
- Google opdrénglech Promotioun vun Istio;
- eng entspriechend desapprobéierend, kritesch Haltung zum Projet;
- déi rezent meteoresch Erhéijung vun der Popularitéit vu Kubernetes, un déi Erënnerungen nach ëmmer frësch sinn.
Zesummen dës Faktoren kombinéiere fir en stupefying, sauerstofffräi Ëmfeld ze kreéieren, an deem d'Kapazitéit fir rational Uerteel geschwächt ass, an nëmmen déi komesch Varietéit bleift. .
Aus Linkerd senger Perspektiv ass dëst ... wat ech als gemëschte Segen beschreiwen. Ech mengen, et ass super datt Service Mesh de Mainstream erakomm ass op eng Manéier wéi et net am Joer 2016 gemaach huet wéi Linkerd fir d'éischt ugefaang huet an et war wierklech schwéier d'Leit op de Projet opmierksam ze maachen. Elo gëtt et kee sou Problem! Awer déi schlecht Neiegkeet ass datt d'Service Mesh Landschaft haut sou konfus ass datt et bal onméiglech ass ze verstoen wéi eng Projeten tatsächlech an der Service Mesh Kategorie gehéieren (loosst eleng verstoen wéi een am Beschten fir e bestëmmte Benotzungsfall passt). Dëst ass definitiv en Dealbreaker fir jiddereen (an et ginn definitiv e puer Fäll wou Istio oder en anere Projet besser passt wéi Linkerd, well déi lescht nach ëmmer keng universell Léisung ass).
Op Linkerd senger Säit war eis Strategie de Kaméidi ze ignoréieren, weider ze fokusséieren op d'Léisung vun echte Gemeinschaftsproblemer, an am Wesentlechen op den Hype ze stierwen. Um Enn geet den Hype of a mir kënne roueg weider schaffen.
An der Tëschenzäit musse mir alleguer e bësse Gedold hunn.
Wäert e Service Mesh fir mech nëtzlech sinn, en bescheidenen Software Ingenieur?
De folgende Questionnaire hëlleft Iech dës Fro ze beäntweren:
Sidd Dir nëmmen un der Ëmsetzung vun der Geschäftslogik involvéiert? An dësem Fall wäert de Service Mesh fir Iech net nëtzlech sinn. Dat ass, natierlech, Dir kënnt et interesséiert sinn, awer am Idealfall sollt de Service Mesh net direkt eppes an Ärem Ëmfeld beaflossen. Fuert weider un deem wat Dir bezuelt kritt fir ze maachen.
Ënnerstëtzt Dir d'Plattform bei enger Firma déi Kubernetes benotzt? Jo, an dësem Fall braucht Dir e Service Mesh (ausser, natierlech, Dir benotzt K8s just fir e Monolith oder Batchveraarbechtung ze lafen - awer da géif ech froen firwat Dir K8s braucht). Dir wäert méiglecherweis mat vill Mikroservicer ophalen, geschriwwen vu verschiddene Leit. Si interagéieren all mateneen a sinn an engem Wirbel vun Runtime Ofhängegkeeten gebonnen, an Dir musst e Wee fannen fir alles ze këmmeren. Mat Kubernetes erlaabt Iech e Service Mesh "fir Iech selwer" ze wielen. Fir dëst ze maachen, vertraut Iech mat hire Fäegkeeten a Featuren an beäntwert d'Fro ob ee vun de verfügbare Projete fir Iech gëeegent ass (ech recommandéieren Är Fuerschung mat Linkerd unzefänken).
Sidd Dir eng Plattformfirma bei enger Firma déi NET Kubernetes benotzt awer Mikroservicer benotzt? An dësem Fall wäert e Service Mesh fir Iech nëtzlech sinn, awer seng Notzung wäert net trivial sinn. Natierlech kënnt Dir imitéieren Aarbechtsservice Mesh andeems Dir eng Rëtsch Proxyen placéiert, awer e wichtege Virdeel vu Kubernetes ass den Deploymentmodell: d'manuell Ënnerhalt vun dëse Proxyen erfuerdert vill méi Zäit, Effort an Ausgaben.
Sidd Dir verantwortlech fir d'Plattform an enger Firma déi mat Monolithen schafft? An dësem Fall brauch Dir wahrscheinlech kee Service Mesh. Wann Dir mat Monolithen (oder souguer Sammlunge vu Monolithen) schafft, déi gutt definéiert a selten verännert Interaktiounsmuster hunn, da wäert e Service Mesh Iech wéineg ze bidden hunn. Also kënnt Dir et einfach ignoréieren an hoffen datt et wéi e schlechten Dram verschwannen wäert ...
Konklusioun
Wahrscheinlech, Service Mesh soll nach ëmmer net "déi meescht hyped Technologie an der Welt" genannt ginn - dës zweifelhaft Éier gehéiert wahrscheinlech Bitcoin oder AI. Si ass wahrscheinlech an der Top fënnef. Awer wann Dir duerch d'Schichte vu Kaméidi geschnidden, gëtt et kloer datt de Service Mesh wierklech Virdeeler bréngt fir déi, déi Applikatiounen op Kubernetes bauen.
Ech hätt gär datt Dir Linkerd probéiert - et op engem Kubernetes Cluster installéieren (oder souguer Minikube op engem Laptop) , an Dir kënnt fir Iech gesinn wat ech schwätzen.
FAQ
- Wann ech de Service Mesh ignoréieren, wäert et verschwannen?
— Ech muss dech enttäuschen: Service Mesh ass laang bei eis.
- Awer ech WËLL NET Service Mesh benotzen!
- Ma, et ass net néideg! Liest just mäi Questionnaire hei uewen fir ze verstoen ob Dir op d'mannst Iech mat sengen Basics vertraut sollt maachen.
— Ass dat net gutt al ESB/Mëttelware mat enger neier Zooss?
- Service Mesh beschäftegt sech mat operationeller Logik, net semantescher. Enterprise Service Bus (). Dës Trennung erhalen hëlleft dem Service Mesh datselwecht Schicksal ze vermeiden.
- Wéi ënnerscheet sech e Service Mesh vun API Gateways?
- Et ginn eng Millioun Artikelen iwwer dëst Thema. Google et einfach.
- Envoy ass e Service Mesh?
- Nee, Envoy ass kee Service Mesh, et ass e Proxy Server. Et kann benotzt ginn fir e Service Mesh ze organiséieren (a vill méi - et ass en allgemeng Zweck Proxy). Awer u sech ass et kee Servicemesh.
- Network Service Mesh ass e Service Mesh?
- Nee. Trotz dem Numm ass dëst kee Service Mesh (wéi gefällt Dir Marketing Wonner?).
- Wäert e Service Mesh hëllefen mat mengem Message Schlaang-baséiert reaktiv asynchronous System?
- Nee, Service Mesh wäert Iech net hëllefen.
- Wéi eng Service Mesh soll ech benotzen?
- , kee Geck.
- Den Artikel suckt! / Den Auteur ass wëllkomm!
- Deelt w.e.g. de Link mat all Äre Frënn fir datt se et gesinn!
Unerkennungen
Wéi Dir vläicht aus dem Titel virgestallt hutt, gouf dësen Artikel inspiréiert vum Jay Kreps senger fantastescher Ofhandlung "" Ech hunn de Jay virun zéng Joer begéint wéi ech hien op Linked In interviewt hunn an hien ass zënterhier eng Inspiratioun fir mech.
Wärend ech mech gären e "Linkerd Entwéckler" nennen, ass d'Realitéit datt ech méi en Instandhalter vun der README.md Datei op engem Projet sinn. Linkerd gëtt haut geschafft , , Leit, an dëse Projet wier net geschitt ouni d'Participatioun vun enger wonnerbarer Gemeinschaft vu Mataarbechter a Benotzer.
A schlussendlech e spezielle Merci un d'Creator vu Linkerd, (primus inter pares), déi viru ville Joeren zesumme mat mir an all deene Geschwëster mat Déngschtmesh gedaucht sinn.
PS vum Iwwersetzer
Liest och op eisem Blog:
- «";
- «";
- «";
- «";
- «".
Source: will.com