Let wel. vertaal.: Diensgaas is 'n verskynsel wat nog nie 'n stabiele vertaling in Russies het nie (meer as 2 jaar gelede het ons die opsie "gaas vir dienste" voorgestel, en 'n bietjie later het sommige kollegas die kombinasie "dienssif" aktief begin bevorder). Voortdurende gepraat oor hierdie tegnologie het gelei tot 'n situasie waarin die bemarking en tegniese komponente te nou verweef is. Hierdie wonderlike materiaal van een van die skrywers van die oorspronklike term is bedoel om duidelikheid vir ingenieurs en ander te verskaf.
Strokiesprent van
Inleiding
As jy 'n sagteware-ingenieur is wat iewers in die agterplaasstelsels werk, het die term "diensnetwerk" waarskynlik reeds die afgelope paar jaar stewig in jou gedagtes ingeburger geraak. Danksy 'n vreemde toeval neem hierdie frase die bedryf al hoe meer oor, en die hype en promosieaanbiedinge wat daarmee gepaardgaan, groei soos 'n sneeubal wat afdraand vlieg en geen tekens toon dat dit verlangsaam nie.
Diensgaas is gebore in die troebel, bevooroordeelde waters van die wolk-inheemse ekosisteem. Ongelukkig beteken dit dat baie van die kontroversie rondom dit wissel van "lae-kalorie praatjies" tot - om 'n tegniese term te gebruik - volslae onsin. Maar as jy deur al die geraas sny, sal jy vind dat die diensmaas 'n baie werklike, gedefinieerde en belangrike funksie het.
In hierdie pos sal ek probeer om presies dit te doen: verskaf 'n eerlike, in-diepte, ingenieur-gefokusde gids tot diensnetwerk. Ek gaan nie net die vraag beantwoord nie: "Wat dit is?", - maar ook "Hoekom?"En "Hoekom nou?". Ten slotte sal ek probeer om te verduidelik hoekom (na my mening) hierdie spesifieke tegnologie so 'n dolle opskudding veroorsaak het, wat 'n interessante storie op sigself is.
Кто я?
Hi almal! My naam is . Ek is een van die skeppers — die heel eerste diensmaasprojek en die projek wat die skuld kry vir die voorkoms van die kwartaal diensmaas as sulks (jammer ouens!). (Nota transl.: Terloops, met die aanbreek van die verskyning van hierdie term, meer as 2,5 jaar gelede, het ons reeds die vroeë materiaal van dieselfde skrywer vertaal getiteld "".) Ek kop ook is 'n opstart wat oulike diensnetwerkdinge soos Linkerd en .
Jy kan seker raai dat ek 'n baie bevooroordeelde en subjektiewe mening oor hierdie kwessie het. Ek sal egter probeer om vooroordeel tot die minimum te beperk (met die uitsondering van een afdeling: "Hoekom word daar so baie gepraat oor diensnetwerk?", - waarin ek nog my vooropgestelde idees sal deel). Ek sal ook my bes doen om hierdie gids so objektief moontlik te maak. Vir spesifieke voorbeelde sal ek hoofsaaklik op Linkerd se ervaring staatmaak, terwyl ek verskille (indien enige) uitwys waarvan ek weet in die implementering van ander tipes diensnetwerk.
Goed, tyd om aan te beweeg na die goedjies.
Wat is 'n diensnetwerk?
Ten spyte van al die hype, is die struktuur van die diensnetwerk redelik eenvoudig. Dit is net 'n klomp gebruikersruimte-gevolmagtigdes wat "langs" die dienste geleë is (ons sal later 'n bietjie praat oor wat "volgende" is), plus 'n stel beheerprosesse. Die gevolmagtigdes word gesamentlik genoem datavlak, en die beheerprosesse word genoem beheer vliegtuig. Die datavliegtuig onderskep oproepe tussen dienste en doen “allerhande verskillende dinge” daarmee; Die beheervlak koördineer dienooreenkomstig die gedrag van die gevolmagtigde en bied toegang aan jou, d.w.s. operateur, na die API, sodat die netwerk as 'n geheel gemanipuleer en gemeet kan word.
Watter soort gevolmagtigde is dit? Dit is 'n Laag 7-bewuste TCP-instaanbediener (d.w.s. "met inagneming van" laag 7 van die OSI-model) soos HAProxy en NGINX. Jy kan 'n volmag na jou smaak kies; Linkerd gebruik 'n Rust-instaanbediener, eenvoudig genoem . Ons het dit spesifiek saamgestel vir diensmaas. Ander meshes verkies ander gevolmagtigdes (Envoy is 'n algemene keuse). Die keuse van 'n volmag is egter net 'n kwessie van implementering.
Wat doen hierdie instaanbedieners? Dit is duidelik dat hulle gevolmagtigde oproepe na en van dienste (streng gesproke, hulle tree op as gevolmagtigdes en omgekeerde gevolmagtigdes, hanteer beide inkomende en uitgaande oproepe). En hulle implementeer 'n kenmerkstel wat op oproepe fokus tussen dienste. Hierdie fokus op verkeer tussen dienste is wat 'n diensnetwerk-instaanbediener onderskei van byvoorbeeld API-poorte of intree-gevolmagtigdes (laasgenoemde fokus op oproepe wat van die buitewêreld in die groep inkom). (Let wel. vertaal.: Vir 'n vergelyking van bestaande Ingress-beheerders vir Kubernetes, waarvan baie die reeds genoemde gesant gebruik, sien .)
So, ons het die datavlak uitgesorteer. Die beheervlak is eenvoudiger: dit is 'n stel komponente wat al die meganika verskaf wat die datavliegtuig nodig het om op 'n gekoördineerde wyse te werk, insluitend diensontdekking, uitreiking van TLS-sertifikate, metrieke samevoeging, ens. Die datavlak lig die beheervlak van sy gedrag; op sy beurt bied die beheervlak 'n API wat jou toelaat om die gedrag van die datavlak as 'n geheel te verander en te monitor.
Hieronder is 'n diagram van die beheervlak en datavlak in Linkerd. Soos u kan sien, bevat die beheervlak verskeie verskillende komponente, insluitend 'n Prometheus-instansie wat statistieke van instaanbedieners versamel, sowel as ander komponente soos destination (diens ontdekking), identity (sertifikaatowerheid, CA) en public-api (eindpunte vir web en CLI). In teenstelling hiermee is die datavlak 'n eenvoudige gekoppelde proxy langs die toepassingsinstansie. Dit is net 'n logiese diagram; In 'n werklike ontplooiing het jy dalk drie replikas van elke beheervlakkomponent en honderde of duisende gevolmagtigdes in die datavlak.
(Die blou reghoeke in hierdie diagram simboliseer die grense van Kubernetes-peule. Jy kan sien dat die houers met linkerd-proxy in dieselfde peul as die toepassingshouers is. Hierdie skema staan bekend as syspanhouer.)
Diensnetwerkargitektuur het verskeie belangrike implikasies. Eerstens, aangesien die taak van 'n gevolmagtigde is om oproepe tussen dienste te onderskep, maak 'n diensnetwerk net sin as jou toepassing vir 'n sekere stel dienste geskep is. Maas kan 'n mens gebruik met monoliete, maar dit is duidelik oorbodig ter wille van een enkele volmag, en die funksionaliteit daarvan sal waarskynlik nie in aanvraag wees nie.
Nog 'n belangrike gevolg is dat die diensnetwerk vereis groot aantal gevolmagtigdes. Om die waarheid te sê, Linkerd heg 'n gekoppelde proxy aan elke instansie van elke diens (ander implementerings voeg 'n instaanbediener by elke nodus/gasheer/virtuele masjien. Dit is in elk geval baie). Sulke aktiewe gebruik van gevolmagtigdes hou op sigself 'n aantal bykomende komplikasies in:
- Gevolmagtigdes in die datavlak moet wees vinnig, aangesien daar vir elke oproep 'n paar oproepe na die instaanbediener is: een aan die kliëntkant, een aan die bedienerkant.
- Ook gevolmagtigdes moet wees klein и liggewig. Elkeen sal geheue- en SVE-hulpbronne verbruik, en hierdie verbruik sal lineêr groei met die toepassing.
- Jy sal 'n meganisme nodig hê om 'n groot aantal gevolmagtigdes te ontplooi en op te dateer. Om dit met die hand te doen is nie 'n opsie nie.
Oor die algemeen lyk 'n diensnetwerk so (ten minste uit 'n voëlvlug): jy ontplooi 'n klomp gebruikersruimte-gevolmagtigdes wat "iets doen" met interne, interdiensverkeer, en gebruik 'n beheervliegtuig om dit te monitor en te bestuur.
Nou is dit tyd om die vraag te vra "Hoekom?"
Waarvoor is 'n diensnetwerk?
Diegene wat die eerste keer die idee van 'n diensnetwerk teëgekom het, kan vergewe word omdat hulle 'n bietjie beangs voel. Die diensnetwerkontwerp beteken dat dit nie net latensie in die toepassing verhoog nie, maar ook verteer hulpbronne en sal byvoeg 'n klomp nuwe meganismes in die infrastruktuur. Eers stel jy 'n diensnetwerk op, en dan skielik vind jy dat jy honderde (indien nie duisende nie) gevolmagtigdes moet diens. Die vraag is, wie sal dit vrywillig doen?
Die antwoord op hierdie vraag bestaan uit twee dele. Eerstens kan die transaksiekoste verbonde aan die implementering van hierdie gevolmagtigdes aansienlik verminder word danksy 'n paar veranderinge wat in die ekosisteem plaasvind (meer hieroor later).
Tweedens, 'n toestel soos hierdie is eintlik 'n goeie manier om addisionele logika in die stelsel in te voer. Nie net omdat 'n diensnetwerk baie nuwe funksionaliteit kan byvoeg nie, maar ook omdat dit gedoen kan word sonder om met die ekosisteem in te meng. Trouens, die hele diensnetwerkmodel is op hierdie uitgangspunt gebaseer: in 'n multidiensstelsel, maak nie saak wat nie doen individuele dienste, verkeer tussen hulle is die ideale punt om funksionaliteit by te voeg.
Byvoorbeeld, in Linkerd (soos in die meeste meshes) is die funksionaliteit hoofsaaklik gefokus op HTTP-oproepe, insluitend HTTP/2 en gRPC*. Die funksionaliteit is redelik ryk - dit kan in drie klasse verdeel word:
- Kenmerke wat verband hou met betroubaarheid. Herhaalde versoeke, time-outs, kanarie-benadering (verkeersverdeling/herleiding), ens.
- Kenmerke wat verband hou met monitering. Samevoeging van sukseskoerse, vertragings en versoekvolumes vir elke diens of individuele aanwysings; konstruksie van topologiese kaarte van dienste, ens.
- Kenmerke wat verband hou met sekuriteit. Wedersydse TLS, toegangsbeheer, ens.
* Vanuit Linkerd se oogpunt verskil gRPC feitlik niks van HTTP/2 nie: dit gebruik net protobuf in die loonvrag. Uit 'n ontwikkelaar se oogpunt is die twee dinge natuurlik verskillend.
Baie van hierdie meganismes werk op die versoekvlak (vandaar die "L7-instaanbediener"). Byvoorbeeld, as die Foo-diens 'n HTTP-oproep na die Bar-diens maak, kan die linkerd-proxy aan die Foo-kant intelligente lasbalansering uitvoer en oproepe van Foo na Bar-instansies roeteer op grond van die waargenome latensie; dit kan die versoek herhaal indien nodig (en as dit idempotent is); dit kan die reaksiekode en uitteltyd, ens. Net so kan gekoppelde volmag aan die Balie-kant 'n versoek verwerp as dit nie toegelaat word nie of die versoeklimiet oorskry word; kan 'n vertraging van sy kant aanteken, ens.
Gevolmagtigdes kan ook "iets doen" op die verbindingsvlak. Byvoorbeeld, gekoppelde gevolmagtigde aan die Foo-kant kan 'n TLS-verbinding inisieer, en gekoppelde gevolmagtigde aan die Bar-kant kan dit beëindig, en beide kante kan mekaar se TLS-sertifikate* verifieer. Dit bied nie net enkripsie tussen dienste nie, maar ook 'n kriptografies veilige manier om dienste te identifiseer: Foo en Bar kan "bewys" dat hulle is wie hulle sê hulle is.
* "Mutual of a friend" beteken dat die kliëntsertifikaat ook geverifieer is (wedersydse TLS). In "klassieke" TLS, byvoorbeeld tussen 'n blaaier en 'n bediener, word die sertifikaat van slegs een kant (die bediener) gewoonlik geverifieer.
Ongeag of hulle op die versoek- of verbindingsvlak werk, is dit belangrik om te beklemtoon dat alle diensnetwerkfunksies is operasioneel karakter. Linkerd is nie in staat om die semantiek van die loonvrag te transformeer nie - byvoorbeeld om velde by 'n JSON-fragment te voeg of veranderinge aan protobuf aan te bring. Ons sal later oor hierdie belangrike kenmerk praat wanneer ons oor ESB en middelware praat.
Dit is die stel kenmerke wat 'n diensnetwerk bied. Die vraag ontstaan: hoekom implementeer dit nie direk in die toepassing nie? En hoekom enigsins moeite doen met 'n gevolmagtigde?
Waarom diensnetwerk 'n goeie idee is
Alhoewel die vermoëns van 'n diensnetwerk opwindend is, lê die kernwaarde daarvan nie eintlik in die kenmerke daarvan nie. Op die ou end het ons Kan implementeer hulle direk in die toepassing (ons sal later sien dat dit die oorsprong van die diensnetwerk was). Om dit in een sin te probeer opsom, is die waarde van 'n diensnetwerk: dit bied kenmerke van kritieke belang om moderne bedienersagteware op 'n konsekwente wyse oor die hele stapel en onafhanklik van toepassingskode te laat loop.
Kom ons ontleed hierdie voorstel.
«Kenmerke van kritieke belang vir die gebruik van moderne bedienersagteware" As jy 'n transaksionele bedienertoepassing skep wat aan die publieke internet gekoppel is, versoeke van die buitewêreld aanvaar en binne 'n kort tyd daarop reageer - byvoorbeeld 'n webtoepassing, 'n API-bediener en die oorgrote meerderheid ander moderne toepassings - en as jy dit implementeer as 'n stel dienste wat sinchronies met mekaar in wisselwerking is, en as jy voortdurend hierdie sagteware opgradeer, nuwe kenmerke byvoeg, en as jy gedwing word om hierdie stelsel in werkende toestand te handhaaf tydens die wysigingsproses - in hierdie geval, baie geluk, jy skep moderne bedienersagteware. En al hierdie wonderlike kenmerke wat hierbo gelys word, blyk eintlik vir jou krities te wees. Die toepassing moet betroubaar, veilig wees en jy moet kan waarneem wat dit doen. Dit is presies die vrae wat service mesh help oplos.
(OK, die vorige paragraaf sluit steeds my oortuiging in dat hierdie benadering die moderne manier is om bedienersagteware te skep. Ander verkies om monoliete, "reaktiewe mikrodienste" en ander dinge te ontwikkel wat nie onder die definisie hierbo val nie. Hierdie mense het waarskynlik hul opinie verskil van myne. Op my beurt dink ek dat hulle "verkeerd" is - hoewel die diensnetwerk in elk geval nie baie nuttig vir hulle is nie).
«Uniform vir die hele stapel" Die funksionaliteit wat deur 'n diensnetwerk verskaf word, is nie net missie-kritiek nie. Dit is van toepassing op alle dienste in die toepassing, ongeag in watter taal hulle geskryf is, watter raamwerk hulle gebruik, wie dit geskryf het, hoe dit ontplooi is, en enige ander subtiliteite van hul ontwikkeling en gebruik.
«Onafhanklik van toepassingskode" Ten slotte bied 'n diensnetwerk nie net konsekwente funksionaliteit oor die hele stapel nie, dit doen dit op 'n manier wat nie vereis dat die toepassing geredigeer word nie. Die fundamentele basis van diensnetwerkfunksionaliteit, insluitend take vir konfigurasie, opdatering, bedryf, instandhouding, ens., is geheel en al op die platformvlak geleë en is onafhanklik van die toepassing. Die toepassing kan verander sonder om die diensnetwerk te beïnvloed. Op sy beurt kan die diensnetwerk verander sonder enige deelname van die toepassing.
Kortom, 'n diensnetwerk bied nie net noodsaaklike funksionaliteit nie, maar doen dit ook op 'n globale, eenvormige en toepassing-onafhanklike manier. En dus, alhoewel diensnetwerkfunksionaliteit in dienskode geïmplementeer kan word (byvoorbeeld as 'n biblioteek wat by elke diens ingesluit is), sal hierdie benadering nie die eenvormigheid en onafhanklikheid verskaf wat so waardevol is in die geval van 'n diensnetwerk nie.
En al wat jy hoef te doen is om 'n klomp gevolmagtigdes by te voeg! Ek belowe ons sal binnekort kyk na die bedryfskoste verbonde aan die byvoeging van hierdie gevolmagtigdes. Maar kom ons stop eers en kyk na hierdie idee van onafhanklikheid vanuit verskillende perspektiewe. mense.
Wie help diensnetwerk?
Hoe ongerieflik dit ook al mag wees, vir 'n tegnologie om 'n belangrike deel van die ekosisteem te word, moet dit deur mense aanvaar word. So wie stel belang in diensmaas? Wie baat by die gebruik daarvan?
As jy moderne bedienersagteware ontwikkel, kan jy min of meer aan jou span as 'n groep dink diens eienaarswat saam besigheidslogika ontwikkel en implementeer, en platform eienaars, die ontwikkeling van die interne platform waarop hierdie dienste funksioneer. In klein organisasies is dit dalk dieselfde mense, maar soos die maatskappy groei, is hierdie rolle geneig om meer uitgesproke te word en selfs in sub-rolle verdeel te word... (Daar is baie om hier te sê oor die veranderende aard van devops, die organisatoriese impak van mikrodienste, ens.) n. Maar kom ons neem vir eers hierdie beskrywings soos gegee).
Vanuit hierdie oogpunt is die duidelike begunstigdes van die diensnetwerk die platformeienaars. Uiteindelik is die doel van die platformspan om 'n interne platform te skep waarop dienseienaars besigheidslogika kan implementeer en dit op 'n manier te doen wat verseker dat hulle so onafhanklik as moontlik is van die duistere besonderhede van sy werking. Nie net bied 'n diensnetwerk vermoëns wat van kritieke belang is om hierdie doel te bereik nie, dit doen dit op 'n manier wat op sy beurt nie afhanklikhede op dienseienaars oplê nie.
Dienseienaars bevoordeel ook, hoewel op 'n meer indirekte manier. Die doelwit van die dienseienaar is om so produktief as moontlik te wees in die implementering van die logika van die besigheidsproses, en hoe minder hy hoef te bekommer oor operasionele kwessies, hoe beter. In plaas daarvan om te gaan met die implementering van, sê, herprobeer-beleide of TLS, kan hulle uitsluitlik op besigheidsdoelwitte fokus en hoop dat die platform vir die res sorg. Dit is 'n groot voordeel vir hulle.
Die organisatoriese waarde van so 'n verdeling tussen die eienaars van platforms en dienste kan nie oorskat word nie. Ek dink sy dra by die hoof bydrae tot die waarde van die diensmaas.
Ons het hierdie les geleer toe 'n vroeë Linkerd-aanhanger ons vertel het hoekom hulle diensnetwerk gekies het: omdat dit hulle toegelaat het om "die praatwinkel tot 'n minimum te beperk." Hier is 'n paar besonderhede: die ouens van een groot maatskappy het hul platform na Kubernetes migreer. Aangesien die toepassing sensitiewe inligting hanteer het, wou hulle alle kommunikasie oor die groepe enkripteer. Die situasie is egter gekompliseer deur die teenwoordigheid van honderde dienste en honderde ontwikkelingspanne. Die vooruitsig om almal te kontak en hulle te oortuig om TLS-ondersteuning by hul planne in te sluit, het hulle glad nie gelukkig gemaak nie. Nadat hulle Linkerd geïnstalleer het, het hulle oorgedra verantwoordelikheid van ontwikkelaars (vanuit die oogpunt waarvan dit onnodige moeilikheid was) tot platformspelers, vir wie dit 'n top-vlak prioriteit was. Met ander woorde, Linkerd het nie soseer 'n tegniese probleem nie as 'n organisatoriese probleem vir hulle opgelos.
Kortom, 'n diensnetwerk is meer 'n oplossing, nie 'n tegniese een nie, maar sosio-tegnies Probleme. (Dankie vir die bekendstelling van hierdie term.)
Sal 'n diensnetwerk al my probleme oplos?
Ja. Ek bedoel, nee!
As jy kyk na die drie klasse kenmerke wat hierbo uiteengesit is - betroubaarheid, sekuriteit en waarneembaarheid - word dit duidelik dat 'n diensnetwerk nie 'n volledige oplossing vir enige van hierdie probleme is nie. Alhoewel Linkerd versoeke kan heruitreik (as dit weet dat hulle idempotent is), is dit nie in staat om besluite te neem oor wat om aan die gebruiker terug te stuur as die diens permanent misluk het nie - daardie besluite moet deur die toepassing geneem word. Linkerd kan statistieke van suksesvolle versoeke hou, maar dit is nie in staat om na die diens te kyk en sy interne maatstawwe te verskaf nie - die toepassing moet sulke hulpmiddels hê. En hoewel Linkerd in staat is om mTLS te organiseer, verg volwaardige sekuriteitsoplossings baie meer.
'n Subset van die kenmerke in hierdie gebiede wat deur die diensnetwerk aangebied word, hou verband met platform kenmerke. Hiermee bedoel ek funksies wat:
- Onafhanklik van besigheidslogika. Die manier waarop oproephistogramme tussen Foo en Bar saamgestel word, is heeltemal onafhanklik van hoekom Foo bel vir Bar.
- Moeilik om korrek te implementeer. In Linkerd word herproberings geparameteriseer met allerhande fancy dinge soos herprobeer begrotings (probeer begrotings weer), aangesien 'n ongesofistikeerde, reguit benadering tot die implementering van sulke dinge beslis sal lei tot die ontstaan van 'n sogenaamde "stortvloed van versoeke" (weer probeer storm) en ander probleme kenmerkend van verspreide stelsels.
- Die doeltreffendste as dit eenvormig toegedien word. Die TLS-meganisme maak net sin as dit oral toegepas word.
Aangesien hierdie funksies op die proxy-vlak (en nie op die toepassingsvlak) geïmplementeer word nie, verskaf die diensnetwerk dit by die platform, nie toepassings nie. Dit maak dus nie saak in watter taal die dienste geskryf is, watter raamwerk hulle gebruik, wie dit geskryf het en hoekom nie. Gevolmagtigdes werk buite al hierdie besonderhede, en die fundamentele basis van hierdie funksionaliteit, insluitend take vir konfigurasie, opdatering, bedryf, instandhouding, ens., lê slegs op die platformvlak.
Voorbeelde van diensnetwerkvermoëns
Om op te som, 'n diensnetwerk is nie 'n volledige oplossing vir betroubaarheid, waarneembaarheid of sekuriteit nie. Die omvang van hierdie gebiede vereis die deelname van dienseienaars, Ops/SRE-spanne en ander maatskappy-entiteite. Die diensnetwerk verskaf slegs 'n platformvlak "sny" vir elk van hierdie areas.
Waarom het diensnetwerk nou gewild geword?
Teen hierdie tyd wonder jy seker: ok, as die diensnetwerk so goed is, hoekom het ons nie tien jaar gelede begin om miljoene gevolmagtigdes in die stapel te ontplooi nie?
Daar is 'n banale antwoord op hierdie vraag: tien jaar gelede het almal monoliete gebou, en niemand het 'n diensmaas nodig nie. Dit is waar, maar na my mening mis hierdie antwoord die punt. Selfs tien jaar gelede is die konsep van mikrodienste as 'n belowende manier om grootskaalse stelsels te bou wyd bespreek en toegepas by maatskappye soos Twitter, Facebook, Google en Netflix. Die algemene siening - ten minste in die dele van die bedryf waarmee ek in aanraking gekom het - was dat mikrodienste die "regte manier" was om groot stelsels te bou, al was dit vrek moeilik.
Natuurlik, hoewel daar tien jaar gelede maatskappye was wat mikrodienste bedryf het, het hulle nie oral waar hulle kon gevolmagtigdes geplak om 'n diensnetwerk te vorm nie. As jy egter mooi kyk, het hulle iets soortgelyks gedoen: baie van hierdie maatskappye het die gebruik van 'n spesiale interne biblioteek vereis vir netwerkkommunikasie (soms 'n dik kliëntbiblioteek genoem, vet kliënt biblioteek).
Netflix het Hysterix gehad, Google het Stubby gehad, Twitter het die Finagle-biblioteek gehad. Finagle was byvoorbeeld verpligtend vir elke nuwe diens op Twitter. Dit het beide die kliënt- en bedienerkant van verbindings hanteer, toegelaat vir herhaalde versoeke, ondersteunde versoekroetering, vragbalansering en meting. Dit het 'n konsekwente laag van betroubaarheid en waarneembaarheid oor die hele Twitter-stapel verskaf, ongeag wat die diens gedoen het. Dit het natuurlik net vir JVM-tale gewerk en was gebaseer op 'n programmeringsmodel wat vir die hele toepassing gebruik moes word. Die funksionaliteit daarvan was egter amper dieselfde as dié van die diensmaas. (Trouens, die eerste weergawe van Linkerd was bloot Finagle toegedraai in volmagvorm.)
Tien jaar gelede was daar dus nie net mikrodienste nie, maar ook spesiale proto-diens-maasbiblioteke wat dieselfde probleme opgelos het wat diensmaas vandag oplos. Die diensmaas self het toe egter nie bestaan nie. Daar moes nog een skof wees voordat sy verskyn het.
En dit is waar die dieper antwoord lê, versteek in 'n ander verandering wat oor die afgelope 10 jaar plaasgevind het: die koste van die implementering van mikrodienste het dramaties gedaal. Die maatskappye wat hierbo genoem is wat tien jaar gelede mikrodienste gebruik het—Twitter, Netflix, Facebook, Google—was maatskappye van enorme skaal en enorme hulpbronne. Hulle het nie net die behoefte gehad nie, maar ook die vermoë om groot mikrodienste-gebaseerde toepassings te bou, te ontplooi en te bedryf. Die energie en moeite wat Twitter-ingenieurs ingesit het om van 'n monolitiese na 'n mikrodienste-benadering te beweeg, is verstommend. (Om eerlik te wees, so is die feit dat dit geslaag het.) Hierdie soort infrastruktuurmaneuvers was toe onmoontlik vir kleiner maatskappye.
Vinnig vorentoe na die hede. Daar is vandag nuwe ondernemings waar die verhouding van mikrodienste tot ontwikkelaars 5:1 is (of selfs ), en wat meer is, hulle hanteer dit suksesvol! As 'n 5-persoon-opstartonderneming maklik 50 mikrodienste kan bedryf, dan het iets duidelik die koste van die implementering daarvan verminder.
1500 mikrodienste in Monzo; elke lyn is 'n voorgeskrewe netwerkreël wat verkeer toelaat
Die dramatiese vermindering in die koste van die bedryf van mikrodienste is die resultaat van een proses: groeiende gewildheid van houers и orkestreerders. Dit is juis die diep antwoord op die vraag wat bygedra het tot die ontstaan van die diensmaas. Dieselfde tegnologie het beide diensnetwerke en mikrodienste aantreklik gemaak: Kubernetes en Docker.
Hoekom? Wel, Docker los een groot probleem op - die verpakkingsprobleem. Deur 'n toepassing en sy (nie-netwerk) looptydafhanklikhede in 'n houer te verpak, verander Docker die toepassing in 'n verwisselbare eenheid wat op enige plek gehuisves en uitgevoer kan word. Terselfdertyd vergemaklik dit die werking aansienlik veeltalig Stapel: Omdat 'n houer 'n atoomeenheid van uitvoering is, vir ontplooiing en operasionele doeleindes, maak dit nie saak wat binne is nie, of dit nou 'n JVM-, Node-, Go-, Python- of Ruby-toepassing is. Jy begin dit net en dit is dit.
Kubernetes neem alles na die volgende vlak. Noudat daar tonne "dinge om te hardloop" en tonne masjiene is om dit mee te laat loop, is daar 'n behoefte aan 'n instrument wat hulle met mekaar kan korreleer. In 'n breë sin gee jy vir Kubernetes baie houers en baie masjiene, en dit karteer hulle teen mekaar (natuurlik is dit 'n dinamiese en voortdurend veranderende proses: nuwe houers beweeg om die stelsel, masjiene begin en stop , ens. Kubernetes neem egter dit alles in ag ).
Sodra Kubernetes opgestel is, verskil die tydskoste om een diens te ontplooi en te bedryf min van die koste om tien dienste te ontplooi en te bedryf (in werklikheid is dit amper dieselfde vir 100 dienste). Voeg hierby houers as 'n verpakkingsmeganisme wat meertalige implementering aanmoedig, en jy het 'n magdom nuwe toepassings geïmplementeer in die vorm van mikrodienste wat in verskillende tale geskryf is - presies die soort omgewing waarvoor 'n diensnetwerk so goed geskik is.
Dus, ons kom by die antwoord op die vraag waarom die idee van 'n diensnetwerk nou gewild geword het: die homogeniteit wat Kubernetes vir dienste verskaf, is direk van toepassing op die operasionele uitdagings wat 'n diensnetwerk in die gesig staar. Jy verpak die gevolmagtigdes in houers, gee Kubernetes die taak om hulle te plak waar dit ook al kan, en voila! As gevolg hiervan kry u 'n diensnetwerk, terwyl al die meganika van die ontplooiing daarvan deur Kubernetes bestuur word. (Ten minste uit 'n voëlvlug. Natuurlik is daar baie nuanses aan hierdie proses.)
Om dit op te som: die rede waarom diensmaskers nou gewild geword het, en nie tien jaar gelede nie, is dat Kubernetes en Docker nie net aansienlik toegeneem het nie behoefte daarin, wat die implementering van toepassings as stelle veeltalige mikrodienste vereenvoudig het, maar ook aansienlik verminder koste vir die werking daarvan, verskaffing van meganismes vir die ontplooiing en ondersteuning van syspan-instaanbediener-vlote.
Hoekom word daar so baie oor diensnetwerk gepraat?
Предупреждение: In hierdie afdeling maak ek gebruik van allerhande aannames, vermoedens, versinsels en binne-inligting.
Doen 'n soektog vir "service mesh" en jy sal 'n klomp herwonne lae-kalorie-inhoud, vreemde projekte en 'n kaleidoskoop van vervorming teëkom wat 'n eggokamer waardig is. Enige spoggerige nuwe tegnologie doen dit, maar in die geval van 'n diensnetwerk is die probleem veral akuut. Hoekom?
Wel, deel daarvan is my skuld. Ek het hard gewerk om Linkerd en die diensnetwerk te bevorder elke kans wat ek kry deur ontelbare blogplasings en artikels soos hierdie een. Maar ek is nie so kragtig nie. Om hierdie vraag regtig te beantwoord, moet ons 'n bietjie oor die algehele situasie praat. En dit is onmoontlik om daaroor te praat sonder om een projek te noem: is 'n oopbron-diensnetwerk wat gesamentlik deur Google, IBM en Lyft ontwikkel is.
(Die drie maatskappye het baie verskillende rolle: Lyft se betrokkenheid blyk slegs in naam te wees; hulle is die skrywers van Envoy, maar gebruik of neem nie deel aan Istio se ontwikkeling nie. IBM is betrokke by en gebruik Istio se ontwikkeling. Google is aktief betrokke by Istio se ontwikkeling ontwikkeling, maar gebruik dit nie eintlik so ver ek kan sê nie.)
Die Istio-projek is opvallend vir twee dinge. Eerstens is daar die enorme bemarkingspoging wat veral Google insit om dit te bevorder. Ek sou skat dat die meeste mense wat bewus is van die diensmaaskonsep vandag eers daaroor geleer het deur Istio. Die tweede ding is hoe swak Istio ontvang is. In hierdie saak is ek natuurlik 'n belanghebbende party, maar om so objektief as moontlik te probeer bly, kan ek steeds nie help nie , nie baie kenmerkend nie (hoewel nie uniek nie: systemd kom in gedagte, ...) vir 'n oopbronprojek.
(In die praktyk blyk dit dat Istio probleme het nie net met kompleksiteit en UX nie, maar ook met prestasie. Bv. In 'n derdeparty-studie het navorsers situasies gevind waarin Istio se stertvertraging 100 keer hoër was as Linkerd s'n, sowel as situasies waarin Linkerd aanhou om suksesvol te funksioneer terwyl Istio heeltemal ophou werk het.)
As ek my teorieë oor hoekom dit gebeur het, tersyde gestel word, glo ek dat die oorweldigende opgewondenheid rondom die diensnetwerk verklaar word deur Google se deelname. Naamlik 'n kombinasie van die volgende drie faktore:
- Google se indringende promosie van Istio;
- 'n ooreenstemmende afkeurende, kritiese houding teenoor die projek;
- die onlangse meteoriese styging in gewildheid van Kubernetes, waarvan die herinneringe nog vars is.
Hierdie faktore kombineer saam om 'n verdwaasde, suurstofvrye omgewing te skep waarin die kapasiteit vir rasionele oordeel verswak word, en net die vreemde verskeidenheid oorbly. .
Vanuit Linkerd se perspektief is dit...wat ek as 'n gemengde seën sou beskryf. Ek bedoel, dit is wonderlik dat service mesh die hoofstroom betree het op 'n manier wat dit nie in 2016 gedoen het toe Linkerd die eerste keer begin het nie en dit was regtig moeilik om mense te kry om aandag aan die projek te gee. Nou is daar nie so 'n probleem nie! Maar die slegte nuus is dat die diensmaaslandskap vandag so verwarrend is dat dit byna onmoontlik is om te verstaan watter projekte eintlik in die diensmaaskategorie hoort (wat nog te sê van verstaan watter een die beste geskik is vir 'n spesifieke gebruiksgeval). Dit is beslis 'n transaksiebreker vir almal (en daar is beslis sommige gevalle waar Istio of 'n ander projek beter geskik is as Linkerd, aangesien laasgenoemde steeds nie 'n universele oplossing is nie).
Aan Linkerd se kant was ons strategie om die geraas te ignoreer, aan te hou fokus op die oplossing van werklike gemeenskapsprobleme, en in wese te wag dat die hype verdwyn. Uiteindelik sal die hype bedaar en ons kan rustig voortgaan om te werk.
Intussen sal ons almal bietjie geduldig moet wees.
Sal 'n diensnetwerk nuttig wees vir my, 'n nederige sagteware-ingenieur?
Die volgende vraelys sal jou help om hierdie vraag te beantwoord:
Is jy net betrokke by die implementering van besigheidslogika? In hierdie geval sal die diensnetwerk nie vir jou nuttig wees nie. Dit wil sê, jy mag dalk daarin belangstel, maar ideaal gesproke behoort die diensnetwerk niks direk in jou omgewing te beïnvloed nie. Hou aan werk aan dit waarvoor jy betaal word.
Ondersteun jy die platform by 'n maatskappy wat Kubernetes gebruik? Ja, in hierdie geval het jy 'n diensnetwerk nodig (tensy jy natuurlik K8s gebruik net om 'n monoliet of bondelverwerking uit te voer - maar dan wil ek vra hoekom jy K8s nodig het). Jy sal waarskynlik met baie mikrodienste eindig wat deur verskillende mense geskryf is. Hulle het almal interaksie met mekaar en is vasgebind in 'n warboel van runtime-afhanklikhede, en jy moet 'n manier vind om dit alles te hanteer. Deur Kubernetes te gebruik, kan jy 'n diensnetwerk "vir jouself" kies. Om dit te doen, maak jouself vertroud met hul vermoëns en kenmerke en beantwoord die vraag of enige van die beskikbare projekte vir jou geskik is (ek beveel aan om jou navorsing met Linkerd te begin).
Is jy 'n platformmaatskappy by 'n maatskappy wat NIE Kubernetes gebruik nie, maar mikrodienste gebruik? In hierdie geval sal 'n diensnetwerk vir jou nuttig wees, maar die gebruik daarvan sal nie-triviaal wees. Natuurlik kan jy naboots werkdiensnetwerk deur 'n klomp gevolmagtigdes te plaas, maar 'n belangrike voordeel van Kubernetes is die ontplooiingsmodel: die handmatige instandhouding van hierdie gevolmagtigdes sal baie meer tyd, moeite en koste verg.
Is jy verantwoordelik vir die platform in 'n maatskappy wat met monoliete werk? In hierdie geval het jy waarskynlik nie 'n diensnetwerk nodig nie. As jy met monoliete (of selfs versamelings monoliete) werk wat goed gedefinieerde en selde veranderende interaksiepatrone het, dan sal 'n diensnetwerk min hê om jou te bied. So jy kan dit eenvoudig ignoreer en hoop dat dit soos 'n slegte droom sal verdwyn...
Gevolgtrekking
Waarskynlik moet diensnetwerk steeds nie "die mees gehyped tegnologie in die wêreld" genoem word nie - hierdie twyfelagtige eer behoort waarskynlik aan Bitcoin of AI. Sy is seker onder die top vyf. Maar as jy deur die lae geraas sny, word dit duidelik dat die diensnetwerk werklike voordele inhou vir diegene wat toepassings op Kubernetes bou.
Ek wil graag hê jy moet Linkerd probeer - installeer dit op 'n Kubernetes-kluster (of selfs Minikube op 'n skootrekenaar) , en jy kan self sien waarvan ek praat.
FAQ
— As ek die diensnetwerk ignoreer, sal dit verdwyn?
— Ek moet jou teleurstel: diensmaas is al lank met ons.
- Maar ek WIL NIE diensmaas gebruik nie!
- Wel, dit is nie nodig nie! Lees net my vraelys hierbo om te verstaan of jy jou ten minste met die basiese beginsels daarvan moet vergewis.
— Is dit nie goeie ou ESB/middelware met 'n nuwe sous nie?
— Diensnetwerk handel oor operasionele logika, nie semantiese een nie. onderneming diens bus (). Die handhawing van hierdie skeiding help die diensmaas om dieselfde lot te vermy.
— Hoe verskil 'n diensnetwerk van API-poorte?
— Daar is 'n miljoen artikels oor hierdie onderwerp. Google dit net.
— Gesant is 'n diensnetwerk?
- Nee, Envoy is nie 'n diensnetwerk nie, dit is 'n instaanbediener. Dit kan gebruik word om 'n diensnetwerk te organiseer (en nog baie meer - dit is 'n volmag vir algemene doeleindes). Maar op sigself is dit nie 'n diensmaas nie.
— Network Service Mesh is 'n diensnetwerk?
- Geen. Ten spyte van die naam, is dit nie 'n diensnetwerk nie (hoe hou jy van bemarkingswonderwerke?).
— Sal 'n diensnetwerk help met my boodskap-tou-gebaseerde reaktiewe asinchrone stelsel?
- Nee, diensmaas sal jou nie help nie.
— Watter diensnetwerk moet ek gebruik?
- , geen brein nie.
- Die artikel suig! / Die skrywer is welkom!
— Deel asseblief die skakel daarna met al jou vriende sodat hulle dit kan sien!
Erkennings
Soos jy dalk uit die titel kon raai, is hierdie artikel geïnspireer deur Jay Kreps se fantastiese verhandeling "" Ek het Jay tien jaar gelede ontmoet toe ek 'n onderhoud op Linked In gevoer het en sedertdien was hy 'n inspirasie vir my.
Alhoewel ek daarvan hou om myself 'n "Linkerd-ontwikkelaar" te noem, is die realiteit dat ek meer 'n onderhouder van die README.md-lêer op 'n projek is. Daar word vandag aan Linkerd gewerk , , mense, en hierdie projek sou nie gebeur het sonder die deelname van 'n wonderlike gemeenskap van bydraers en gebruikers nie.
En ten slotte, 'n spesiale dank aan die skepper van Linkerd, (primus inter pares), wat baie jare gelede saam met my in al hierdie bohaai met diensmaas geduik het.
PS van vertaler
Lees ook op ons blog:
- «»;
- «»;
- «»;
- «»;
- «".
Bron: will.com