Ohar. itzul.: Zerbitzu-sarea errusierara oraindik itzulpen egonkorrik ez duen fenomenoa da (duela 2 urte baino gehiago "zerbitzuetarako sare" aukera proposatu genuen, eta pixka bat beranduago lankide batzuk "zerbitzuaren bahe" konbinazioa aktiboki sustatzen hasi ziren. Teknologia honi buruz etengabe hitz egiteak marketinaren eta osagai teknikoak estuegi loturik dauden egoera ekarri du. Jatorrizko terminoaren egileetako baten material zoragarri honek argitasuna eman nahi die ingeniariei eta besteei.
-ko komikia
Sarrera
Backend sistemen espazioan nonbait lan egiten duen software ingeniaria bazara, ziurrenik "zerbitzu-sare" terminoa zure buruan oso errotuta geratu da azken bi urteetan. Kasualitate bitxi bati esker, esaldi honek gero eta gehiago hartzen du industria, eta hari lotutako txalo eta sustapen eskaintzak hazten ari dira maldan behera hegan egiten duen elur-bola eta moteltze zantzurik ez duela erakusten.
Zerbitzu-sarea hodeiaren jatorrizko ekosistemako ur ilun eta alboragarrietan jaio zen. Zoritxarrez, horrek esan nahi du haren inguruko eztabaidaren zati handi bat "kaloria gutxiko eztabaida"-tik -termino tekniko bat erabiltzeko- zentzugabekeria hutsa dela. Baina zarata guztia mozten baduzu, zerbitzu-sareak oso funtzio erreala, zehaztua eta garrantzitsua duela ikusiko duzu.
Argitalpen honetan, hori egiten saiatuko naiz: zerbitzu sarerako gida zintzo, sakona eta ingeniariari zuzendutakoa eskaini. Ez dut galderari bakarrik erantzungo: "Zer da hau?", - baina baita "Zergatik?"Eta "Zergatik orain?". Azkenik, saiatuko naiz azaltzen zergatik (nire ustez) teknologia jakin honek eragin duen zalaparta zoroa, eta hori istorio interesgarria da berez.
Nor naiz ni?
Kaixo guztioi! Nire izena da . Sortzaileetako bat naiz — lehen zerbitzu sarearen proiektua eta terminoaren agerpenaren erruduna den proiektua zerbitzu-sare horrela (barkatu mutilak!). (Oharra itzul.: Bide batez, termino honen agerpenaren hasieran, duela 2,5 urte baino gehiago, jadanik egile beraren lehen materiala itzuli genuen “".) Burua ere naiz Linkerd eta bezalako zerbitzu-sareko gauza bikainak sortzen dituen startup bat da .
Asmatuko duzu ziurrenik gai honi buruz oso iritzi partikular eta subjektiboa dudala. Hala ere, alborapena gutxien izaten saiatuko naiz (atal bat izan ezik: "Zergatik hitz egiten da hainbeste zerbitzu sareari buruz?", - zeinetan oraindik nire aurrez pentsatutako ideiak partekatuko ditudan). Gainera, ahal den guztia egingo dut gida hau ahalik eta objektiboena izan dadin. Adibide zehatzetarako, batez ere Linkerden esperientzian oinarrituko naiz, beste zerbitzu-sare mota batzuen inplementazioan ezagutzen ditudan desberdintasunak (halakorik balego) adieraziz.
Ados, goxoetara pasatzeko garaia.
Zer da zerbitzu-sare bat?
Emozio guztiak gorabehera, zerbitzu sarearen egitura nahiko erraza da. Hau zerbitzuen "ondoan" kokatutako erabiltzaile-espazioko proxi mordo bat besterik ez da (geroago hitz egingo dugu zer den "hurrengoa"), gehi kontrol-prozesu multzo bat. Proxyak kolektiboki deitzen dira datu-planoa, eta kontrol-prozesuei deitzen zaie kontrol planoa. Datu-hegazkinak zerbitzuen arteko deiak atzematen ditu eta haiekin "denetariko gauza desberdinak" egiten ditu; Kontrol-planoak, horren arabera, proxyaren portaera koordinatzen du eta sarbidea ematen dizu, hau da. operadoreari, APIari, sarea bere osotasunean manipulatu eta neurtzeko aukera emanez.
Zein proxy mota da hau? Hau geruzako 7-ko TCP proxy bat da (hau da, OSI ereduaren 7. geruza "kontuan hartuz") HAProxy eta NGINX bezalakoak. Proxy bat aukeratu dezakezu zure gustura; Linkerdek Rust proxy bat erabiltzen du, besterik gabe izendatua . Zerbitzu-sarerako bereziki bildu dugu. Beste sare batzuek beste proxy batzuk nahiago dituzte (Envoy aukera arrunta da). Hala ere, proxy bat aukeratzea ezarpen kontua besterik ez da.
Zer egiten dute proxy zerbitzari hauek? Jakina, zerbitzuetara eta zerbitzuetatik datozen deiak proxy egiten dituzte (esan bezala, proxy eta alderantzizko proxy gisa jarduten dute, sarrerako eta irteerako deiak kudeatzen dituzte). Eta deiak bideratzen dituen funtzio multzo bat ezartzen dute arteko zerbitzuak. Zerbitzuen arteko trafikoaren arreta hori da zerbitzu sareko proxy bat, esate baterako, API atebideetatik edo sarrerako proxyetatik bereizten duena (azken hauek kanpoko mundutik klusterera datozen deiak bideratzen ditu). (Ohar. itzul.: Kubernetes-erako dauden Ingress kontrolagailuen konparaziorako, horietako askok dagoeneko aipatutako Envoy erabiltzen duten, ikus .)
Beraz, datu-planoa ordenatu dugu. Kontrol-planoa sinpleagoa da: datu-planoak modu koordinatuan funtzionatzeko behar dituen mekanika guztiak eskaintzen dituen osagaien multzoa da, besteak beste, zerbitzuen aurkikuntza, TLS ziurtagiriak ematea, agregazio metrikoa, etab. Datu-planoak kontrol-planoaren berri ematen dio. bere portaera; aldi berean, kontrol-planoak datu-planoaren portaera bere osotasunean aldatzeko eta kontrolatzeko aukera ematen duen API bat eskaintzen du.
Jarraian, Linkerd-eko kontrol-planoaren eta datu-planoaren diagrama dago. Ikus dezakezunez, kontrol-planoak hainbat osagai ditu, besteak beste, Prometheus instantzia bat proxy zerbitzarietatik neurketak biltzen dituena, baita beste osagai batzuk ere. destination (zerbitzuaren aurkikuntza), identity (ziurtagiri-agintaritzak, CA) eta public-api (weberako eta CLIrako amaierako puntuak). Aitzitik, datu-planoa aplikazioaren instantziaren ondoan dagoen linkerd-proxy soil bat da. Hau diagrama logiko bat besterik ez da; Mundu errealeko inplementazioan, baliteke kontrol-planoaren osagai bakoitzaren hiru erreplika eta ehunka edo milaka proxy edukitzea datu-planoan.
(Diagrama honetako laukizuzen urdinek Kubernetes poden mugak sinbolizatzen dituzte. Linkerd-proxy duten edukiontziak aplikazioen edukiontzien ontzi berean daudela ikus dezakezu. Eskema hau izenez ezagutzen da. sidecar edukiontzia.)
Zerbitzu sarearen arkitekturak hainbat ondorio garrantzitsu ditu. Lehenik eta behin, proxy baten zeregina zerbitzuen arteko deiak atzematea denez, zerbitzu-sare batek bakarrik du zentzua zure aplikazioa zerbitzu multzo jakin baterako sortu bada. Sarea ko ahal monolitoekin erabili, baina hori argi eta garbi erredundantea da proxy bakar baten mesedetan, eta bere funtzionaltasuna nekez eskatuko da.
Beste ondorio garrantzitsu bat zerbitzu sareak eskatzen duela da erraldoia proxy kopurua. Izan ere, Linkerdek linkerd-proxy bat eransten dio zerbitzu bakoitzaren instantzia guztietan (beste inplementazio batzuek proxy bat gehitzen dute nodo/ostalari/makina birtual bakoitzean. Hori asko da hala ere). Proxyen erabilera aktibo horrek berez konplikazio gehigarri batzuk dakartza:
- Datu-planoko proxyek izan behar dute azkar, dei bakoitzeko proxyrako dei pare bat baitaude: bat bezeroaren aldetik, bestea zerbitzariaren aldetik.
- Proxiek ere izan beharko lukete txikia и arina. Bakoitzak memoria eta CPU baliabideak kontsumituko ditu, eta kontsumo hori linealki haziko da aplikazioarekin.
- Proxy kopuru handi bat zabaldu eta eguneratzeko mekanismo bat beharko duzu. Eskuz egitea ez da aukera bat.
Oro har, zerbitzu-sare batek itxura hau du (hegazti-ikuspegitik behintzat): barne-zerbitzuen arteko trafikoarekin "zerbait egiten" duten erabiltzaile-espazioko proxy mordoa zabaltzen dituzu eta kontrol-plano bat erabiltzen duzu haiek kontrolatzeko eta kudeatzeko.
Orain "Zergatik?" galdera egiteko garaia da.
Zertarako balio du zerbitzu sare bat?
Zerbitzu-sare baten ideia lehen aldiz topatu zutenei barkatu egin zitzaien beldur apur bat sentitzea. Zerbitzuaren sarearen diseinuak esan nahi du aplikazioan latentzia handituko duela ez ezik, gainera kontsumitu baliabideak eta gehituko du mekanismo berri mordoa azpiegituretan. Lehenik eta behin zerbitzu-sare bat konfiguratzen duzu, eta, bat-batean, ehunka (milaka) proxy zerbitzua eman behar duzula ikusten duzu. Galdera da, nork egingo du borondatez hau?
Galdera honen erantzunak bi zati ditu. Lehenik eta behin, proxy hauek zabaltzearekin lotutako transakzio-kostuak nabarmen murriztu daitezke ekosisteman gertatzen diren aldaketa batzuei esker (hori gehiago aurrerago).
Bigarrenik, horrelako gailu bat sisteman logika gehigarria sartzeko modu bikaina da. Ez bakarrik zerbitzu sare batek funtzionalitate berri asko gehi ditzakeelako, baita ekosistema oztopatu gabe egin daitekeelako ere. Izan ere, zerbitzu-sare-eredu osoa premisa horretan oinarritzen da: zerbitzu anitzeko sisteman, edozein dela ere egiteko banakako zerbitzuak, trafikoa haien artean funtzionalitateak gehitzeko puntu aproposa da.
Adibidez, Linkerd-en (sare gehienetan bezala) funtzionaltasuna HTTP deietara bideratzen da batez ere, HTTP/2 eta gRPC* barne. Funtzionalitatea nahiko aberatsa da - hiru klasetan bana daiteke:
- lotutako ezaugarriak fidagarritasuna. Errepikaturiko eskaerak, denbora-muga, kanariar hurbilketa (trafikoa zatitzea/birbideratzea), etab.
- lotutako ezaugarriak jarraipena. Arrakasta-tasen, atzerapenen eta eskaera-bolumenen batuketa zerbitzu edo banakako norabide bakoitzeko; zerbitzuen mapa topologikoen eraikuntza, etab.
- lotutako ezaugarriak segurtasuna. Elkarrekiko TLS, sarbide-kontrola, etab.
* Linkerden ikuspuntutik, gRPC ez da ia HTTP/2 desberdina: protobuf erabiltzen du karga-kargan. Garatzaile baten ikuspuntutik, bi gauzak desberdinak dira, noski.
Mekanismo horietako askok eskaera mailan funtzionatzen dute (hortik "L7 proxy"). Esate baterako, Foo zerbitzuak Bar zerbitzura HTTP dei bat egiten badu, Foo aldean dagoen linkerd-proxy-ak karga orekatzeko adimenduna egin dezake eta Foo-ren instantzietatik deiak bideratu ditzake ikusitako latentzian oinarrituta; behar izanez gero (eta idempotentea bada); erantzun kodea eta denbora-muga graba ditzake, etab. Era berean, Barra aldean dagoen linkerd-proxy-k eskaera bat baztertu dezake onartzen ez bada edo eskaeraren muga gainditzen bada; bere aldetik atzerapen bat graba dezake, etab.
Proxiek konexio mailan ere "zerbait egin" dezakete. Adibidez, Foo aldean dagoen linkerd-proxy-k TLS konexioa abiarazi dezake, eta Bar aldean dagoen linkerd-proxy-k amaitu egin dezake eta bi aldeek elkarren TLS ziurtagiriak egiaztatu ditzakete*. Honek zerbitzuen arteko enkriptatzeaz gain, zerbitzuak identifikatzeko modu kriptografikoki segurua ere eskaintzen du: Foo eta Bar-ek esaten dutena direla "frogatu" dezakete.
* "Lagun baten elkarrekikotasuna" esan nahi du bezeroaren ziurtagiria ere egiaztatuta dagoela (elkarrekiko TLS). TLS "klasikoetan", arakatzaile baten eta zerbitzari baten artean adibidez, alde bakar baten (zerbitzariaren) ziurtagiria egiaztatu ohi da.
Eskaera edo konexio mailan funtzionatzen duten ala ez, garrantzitsua da azpimarratzea zerbitzu sarearen funtzio guztiak direla. operatiboa pertsonaia. Linkerd-ek ezin du kargaren semantika eraldatu; adibidez, JSON zati bati eremuak gehitzea edo protobuf-en aldaketak egitea. Ezaugarri garrantzitsu honi buruz hitz egingo dugu aurrerago ESB eta middlewareari buruz hitz egiten dugunean.
Hau da zerbitzu sare batek eskaintzen dituen ezaugarrien multzoa. Galdera sortzen da: zergatik ez aplikatzen zuzenean aplikazioan? Eta zergatik kezkatu proxy batekin?
Zergatik zerbitzu sarea ideia ona da
Zerbitzu sare baten gaitasunak zirraragarriak diren arren, bere oinarrizko balioa ez da benetan bere ezaugarrietan datza. Azkenean guk Ezin inplementatu zuzenean aplikazioan (aurrerago ikusiko dugu hori zela zerbitzu-sarearen jatorria). Esaldi batean laburbiltzen saiatzeko, zerbitzu-sare baten balioa hau da: zerbitzariaren software modernoa modu koherentean exekutatzeko funtsezko eginbideak eskaintzen ditu pila osoan eta aplikazio-kodetik independentean.
Azter dezagun proposamen hau.
«Zerbitzariaren software modernoa exekutatzeko funtsezko ezaugarriak" Internet publikora konektatuta dagoen transakzio zerbitzari-aplikazio bat sortzen ari bazara, kanpoko munduaren eskaerak onartzen eta denbora laburrean erantzuten ari bazara, adibidez, web aplikazio bat, API zerbitzari bat eta beste aplikazio modernoen gehiengoa. - eta sinkronoki elkarreragiten duten zerbitzu multzo gisa inplementatzen baduzu, eta software hau etengabe berritzen ari bazara, funtzio berriak gehitzen badituzu eta aldaketa prozesuan sistema hau funtzionamenduan mantentzea behartzen baduzu - honetan kasu, zorionak, zerbitzariaren software modernoa sortzen ari zara. Eta goian zerrendatutako ezaugarri bikain horiek guztiak benetan funtsezkoak dira zuretzat. Aplikazioak fidagarria, segurua izan behar du eta zer egiten ari den behatu behar duzu. Hauek dira zerbitzu sareak konpontzen laguntzen dituen galderak.
(Ados, aurreko paragrafoan oraindik ere nire ustea sartzen da ikuspegi hau zerbitzariaren softwarea sortzeko modu modernoa dela. Beste batzuek nahiago dute monolitoak, "mikrozerbitzu erreaktiboak" eta goian emandako definizioaren barruan sartzen ez diren beste gauza batzuk garatu. iritzia nirearen ezberdina da. Era berean, "oker" daudela uste dut - nahiz eta, nolanahi ere, zerbitzu-sarea ez den oso erabilgarria haientzat).
«Pila osorako uniformea" Zerbitzu-sare batek eskaintzen duen funtzionaltasuna ez da misio-kritikoa soilik. Aplikazioko zerbitzu guztietan aplikatzen dira, edozein hizkuntzatan idatzita dauden, zer esparru erabiltzen duten, nork idatzi dituen, nola zabaldu diren eta haien garapen eta erabileraren beste edozein sotiltasun.
«Aplikazio-kodetik independentea" Azkenik, zerbitzu-sare batek pila osoan funtzionalitate koherentea ez ezik, aplikazioa editatu behar ez duen moduan egiten du. Zerbitzu-sarearen funtzionalitatearen oinarrizko oinarria, konfigurazio, eguneratze, funtzionamendu, mantentze-lanak, etab. barne, plataforma mailan dago erabat eta aplikaziotik independentea da. Aplikazioa alda daiteke zerbitzu sarean eragin gabe. Era berean, zerbitzu-sarea alda daiteke aplikazioaren parte-hartzerik gabe.
Laburbilduz, zerbitzu-sare batek ezinbesteko funtzionaltasuna emateaz gain, modu globalean, uniformean eta aplikazioetatik independentean ere egiten du. Beraz, zerbitzu-sarearen funtzionaltasuna zerbitzu-kodean inplementa daitekeen arren (adibidez, zerbitzu bakoitzean sartutako liburutegi gisa), ikuspegi honek ez du zerbitzu-sare baten kasuan hain baliotsua den uniformetasun eta independentzia emango.
Eta egin behar duzun guztia proxy mordo bat gehitzea da! Proxy hauek gehitzearekin lotutako kostu operatiboak aztertuko ditugula agintzen dut laster. Baina lehenik gelditu gaitezen eta ikus gaitezen independentziaren ideia hau ikuspegi ezberdinetatik. pertsona.
Nori laguntzen dio zerbitzu sareak?
Deserosoa izan daitekeen arren, teknologia bat ekosistemaren zati garrantzitsu bihurtzeko, jendeak onartu behar du. Beraz, nori interesatzen zaio zerbitzu sarean? Nork ateratzen du bere erabileratik?
Zerbitzariaren software modernoa garatzen ari bazara, gutxi gorabehera zure taldea talde gisa pentsa dezakezu zerbitzuen jabeakelkarrekin negozio-logika garatzen eta ezartzen dutenak, eta plataformaren jabeak, zerbitzu horiek funtzionatzen duten barne plataforma garatuz. Erakunde txikietan, pertsona berdinak izan daitezke, baina enpresa hazi ahala, rol horiek nabarmenagoak izan ohi dira eta baita azpiroletan banatzen ere... (Asko dago hemen devops-en izaera aldakorrari buruz, mikrozerbitzuen antolakuntza-eragina, etab.) n. Baina oraingoz har ditzagun deskribapen hauek emandako moduan).
Ikuspegi horretatik, zerbitzu sarearen onuradun argiak plataformaren jabeak dira. Azken finean, azken finean, plataforma-taldearen helburua barne-plataforma bat sortzea da, non zerbitzuen jabeek negozio-logika inplementatu dezaketen eta funtzionamenduaren xehetasun lausoetatik ahalik eta independenteak direla ziurtatzeko moduan. Zerbitzu-sare batek helburu hori lortzeko funtsezko gaitasunak eskaintzeaz gain, zerbitzuen jabeenganako menpekotasunak ezartzen ez dituen moduan egiten ditu.
Zerbitzuen jabeek ere etekina ateratzen diote, modu zeharkakoagoan bada ere. Zerbitzuaren jabearen helburua negozio-prozesuaren logika ezartzean ahalik eta produktiboena izatea da, eta arazo operatiboez zenbat eta gutxiago kezkatu, orduan eta hobeto. Demagun, politikak edo TLS berriro inplementatzeari aurre egin behar izan beharrean, negozio-helburuetan soilik zentratu daitezke eta plataformak gainontzekoaz arduratzea espero dute. Hau abantaila handia da beraientzat.
Plataformen eta zerbitzuen jabeen arteko banaketa horren antolaketa-balioa ezin da gehiegi baloratu. Nik uste dut ekarpena egiten duela nagusia zerbitzu-sarearen balioari ekarpena.
Ikasgai hau ikasi genuen Linkerd-eko zale goiztiar batek zergatik aukeratu zuten zerbitzu-sarea esan zigunean: "hiztun denda ahalik eta gutxien mantentzea" ahalbidetzen zuelako. Hona hemen xehetasun batzuk: enpresa handi bateko mutilek Kubernetesera migratu zuten plataforma. Aplikazioak informazio sentikorra kudeatzen zuenez, klusterren arteko komunikazio guztiak enkriptatu nahi zituzten. Hala ere, egoera zaildu egin zen ehunka zerbitzu eta ehunka garapen talderen presentziagatik. Guztiekin harremanetan jartzeko eta TLS laguntza beren planetan sartzeko konbentzitzeko aukerak ez zituen batere zoriontsu egin. Linkerd instalatu ondoren, transferitu egin zuten erantzukizuna garatzaileengandik (hau alferrikako arazoak izan ziren ikuspuntutik) plataformakoen artean, hauentzat maila goreneko lehentasuna zen. Beste era batera esanda, Linkerdek konpondu zien ez hainbeste arazo teknikoa, antolakuntzarena baizik.
Laburbilduz, zerbitzu-sare bat irtenbide bat gehiago da, ez teknikoa, baina sozio-teknikoak Arazoak. (Eskerrik asko termino hau sartzeagatik.)
Zerbitzu-sare batek konponduko al ditu nire arazo guztiak?
Bai. Esan nahi dut, ez!
Goian azaldutako hiru funtzio-klaseei erreparatzen badiegu —fidagarritasuna, segurtasuna eta behagarritasuna—, argi geratzen da zerbitzu-sare bat ez dela arazo hauetako edozein konponbide osoa. Linkerd-ek eskaerak berriro igorri ditzakeen arren (badakiki idempotenteak direla), ezin du erabaki erabiltzaileari zer itzuli behar den zerbitzua betirako huts egin badu; aplikazioak hartu behar ditu erabakiak. Linkerd-ek eskaera arrakastatsuen estatistikak gorde ditzake, baina ezin du zerbitzua aztertu eta bere barne-neurriak eman - aplikazioak horrelako tresnak izan behar ditu. Eta Linkerd mTLS antolatzeko gai den arren, erabateko segurtasun-irtenbideek askoz gehiago eskatzen dute.
Zerbitzu-sareak eskaintzen dituen eremu horietako ezaugarrien azpimultzo bat dagokio plataformaren ezaugarriak. Honekin esan nahi dut funtzio hauek:
- Negozio logikatik independentea. Foo eta Bar arteko deien histogramak eraikitzeko modua guztiz independentea da zergatik Fook Bar-i deitzen dio.
- Zaila da zuzen ezartzea. Linkerd-en, berriro saiakerak mota guztietako gauza dotoreekin parametrizatzen dira, berriro saiatu aurrekontuak (berriro saiatu aurrekontuak), horrelako gauzak ezartzeko buru-belarri eta sofistikatu gabeko ikuspegi batek, zalantzarik gabe, "eskaeren jausi" deritzonaren sorrera ekarriko du. (Berriro saiatu ekaitza) eta sistema banatuen ezaugarri diren beste arazo batzuk.
- Eraginkorrena uniformeki aplikatzen denean. TLS mekanismoak zentzua du nonahi aplikatzen bada.
Funtzio hauek proxy mailan (eta ez aplikazio mailan) ezartzen direnez, zerbitzu sareak eskaintzen ditu. plataforma, ez aplikazioak. Beraz, berdin dio zer hizkuntzatan idatzita dauden zerbitzuak, zein esparru erabiltzen dituzten, nork idatzi dituen eta zergatik. Proxiek xehetasun guzti horietatik kanpo funtzionatzen dute, eta funtzionalitate honen oinarrizko oinarria, konfigurazio, eguneratze, funtzionamendu, mantentze-lanak, etab. barne, plataforma mailan dago soilik.
Zerbitzu-sare-gaitasunen adibideak
Laburbilduz, zerbitzu-sare bat ez da fidagarritasun, behagarritasun edo segurtasunerako irtenbide osoa. Arlo horien esparruak zerbitzuen jabeen, Ops/SRE taldeen eta beste enpresa-entitate batzuen parte hartzea eskatzen du. Zerbitzu-sareak plataforma-mailako "xerta" bat baino ez du eskaintzen eremu horietako bakoitzerako.
Zergatik bihurtu da zerbitzu sare ezaguna oraintxe bertan?
Oraingoz ziurrenik galdetzen ari zara: ados, zerbitzu-sarea hain ona bada, zergatik ez ginen hasi milioika proxy pila batean zabaltzen duela hamar urte?
Galdera honen erantzun hutsal bat dago: duela hamar urte denek eraiki zituzten monolitoak, eta inork ez zuen zerbitzu-sarerik behar. Hau egia da, baina nire ustez erantzun honek huts egiten du. Duela hamar urte ere, mikrozerbitzuen kontzeptua eskala handiko sistemak eraikitzeko bide itxaropentsu gisa eztabaidatu eta aplikatu zen Twitter, Facebook, Google eta Netflix bezalako enpresetan. Ikuspegi orokorrak —harremanetan jarri nintzen sektoreko ataletan behintzat— mikrozerbitzuak sistema handiak eraikitzeko "bide egokia" zirela zen, nahiz eta zaila izan.
Noski, duela hamar urte mikrozerbitzuak jarduten dituzten enpresak bazeuden ere, ez zituzten proxy-ak ahal zuten leku guztietan itsatsi zerbitzu sare bat osatzeko. Hala ere, ondo begiratuz gero, antzeko zerbait egin zuten: enpresa horietako askok sareko komunikaziorako barne liburutegi berezi bat erabiltzea eskatzen zuten (batzuetan bezeroen liburutegi lodia deitzen zaio, fat bezero liburutegia).
Netflixek Hysterix zuen, Googlek Stubby, Twitterrek Finagle liburutegia. Finagle, adibidez, derrigorrezkoa zen Twitterren zerbitzu berri guztietan. Konexioen bezero eta zerbitzariaren aldea kudeatzen zuen, eskaera errepikatuak, eskaera bideratzea onartzen zuen, karga orekatzea eta neurketa onartzen zituen. Twitter pila osoan fidagarritasun- eta behagarritasun-geruza koherentea eskaintzen zuen, zerbitzuak zertan ari zen kontuan hartu gabe. Jakina, JVM lengoaietarako bakarrik funtzionatu zuen eta aplikazio osorako erabili behar zen programazio eredu batean oinarritzen zen. Hala ere, bere funtzionaltasuna zerbitzu sarearen ia berdina zen. (Izan ere, Linkerd-en lehen bertsioa Finagle besterik ez zen proxy moduan bilduta.)
Hala, duela hamar urte mikrozerbitzuak ez ezik, proto-zerbitzu-sareko liburutegi bereziak ere bazeuden, gaur egun zerbitzu-sareak ebazten dituen arazo berberak konpontzen zituztenak. Hala ere, zerbitzu-sarea bera ez zen existitzen orduan. Bera agertu baino lehen txanda bat gehiago egon behar zen.
Eta hor dago erantzun sakonena, azken 10 urteotan gertatu den beste aldaketa batean ezkutatuta: mikrozerbitzuak zabaltzearen kostua izugarri jaitsi da. Duela hamar urte mikrozerbitzuak erabiltzen zituzten lehen aipatutako enpresak —Twitter, Netflix, Facebook, Google— eskala izugarriko eta baliabide izugarriko enpresak ziren. Beharra ez ezik, mikrozerbitzuetan oinarritutako aplikazio handiak eraikitzeko, zabaldu eta ustiatzeko gaitasuna ere bazuten. Harrigarria da Twitter-eko ingeniariek ikuspegi monolitiko batetik mikrozerbitzuetara pasatzeko jarri duten energia eta ahalegina. (Bidezkoa izateko, arrakasta izan zuena ere bai.) Horrelako azpiegitura maniobrak ezinezkoak ziren orduan enpresa txikiagoentzat.
Azkar aurrera orain arte. Gaur egun, mikrozerbitzuen arteko proportzioa 5:1ekoa da (edo are ), eta are gehiago, arrakastaz aurre egiten diete! 5 pertsonako startup batek 50 mikrozerbitzu erraz funtziona ditzake, orduan zerbaitek argi eta garbi murriztu du haien ezarpenaren kostua.
1500 mikrozerbitzu Monzon; linea bakoitza trafikoa ahalbidetzen duen sare-arau agindu bat da
Mikrozerbitzuen funtzionamenduaren kostuaren murrizketa izugarria prozesu baten ondorioa da: ontzien ospea gero eta handiagoa da и orkestratzaileak. Hau da, hain zuzen, zerbitzu sarearen sorreran zerk lagundu duen galderari erantzun sakona. Teknologia berak erakargarri egin zituen zerbitzu-sareak eta mikrozerbitzuak: Kubernetes eta Docker.
Zergatik? Beno, Docker-ek arazo handi bat konpontzen du: ontziaren arazoa. Aplikazio bat eta bere (sarekoak ez diren) exekuzio-denborako mendekotasunak edukiontzi batean bilduta, Docker-ek aplikazioa edozein lekutan ostatatu eta exekutatu daitekeen unitate trukagarri bihurtzen du. Aldi berean, funtzionamendua asko errazten du eleaniztun Pila: edukiontzi bat exekuzio-unitate atomiko bat denez, hedapenerako eta helburu operatiboetarako, berdin du barruan dagoena, izan JVM, Node, Go, Python edo Ruby aplikazio bat. Abiarazi besterik ez duzu eta kitto.
Kubernetes-ek dena hurrengo mailara eramaten du. Orain, "exekutatu beharreko gauza" eta exekutatzeko makina asko daudenez, elkarren artean korrelazionatu ditzakeen tresna baten beharra dago. Zentzu zabalean, Kubernetesi ontzi asko eta makina asko ematen dizkiozu, eta elkarren aurka mapatzen ditu (noski, prozesu dinamikoa eta etengabe aldatzen da: edukiontzi berriak sisteman zehar mugitzen dira, makinak hasi eta gelditzen dira). , etab. Hala ere, Kubernetesek hori guztia hartzen du kontuan ).
Kubernetes konfiguratuta dagoenean, zerbitzu bat zabaltzeko eta funtzionatzeko denbora-kostua oso desberdina da hamar zerbitzu zabaldu eta funtzionatzeko kostuarekin alderatuta (hain zuzen ere, ia berdina da 100 zerbitzurentzat). Gehitu edukiontzi honi eleanitza inplementazioa bultzatzen duen ontziratze-mekanismo gisa, eta hainbat aplikazio berri inplementatuko dituzu hizkuntza ezberdinetan idatzitako mikrozerbitzuen moduan - zehazki zerbitzu-sare bat hain egokia den ingurune mota.
Beraz, zerbitzu-sare baten ideia zergatik bihurtu den ezagun galderari erantzungo diogu: Kubernetes-ek zerbitzuei ematen dien homogeneotasuna zerbitzu-sare batek dituen erronka operatiboei zuzenean aplikatzen die. Proxyak edukiontzietan paketatzen dituzu, Kubernetesi ahal den lekuan itsatsiaren zeregina ematen diozu, eta listo! Ondorioz, zerbitzu-sare bat lortzen duzu, bere hedapenaren mekanika guztiak Kubernetes-ek kudeatzen dituen bitartean. (Hegaztiaren ikuspegitik behintzat. Noski, prozesu honek ñabardura asko ditu.)
Laburbilduz: zerbitzu-sareak orain ezagunak bihurtu diren arrazoia da, eta ez duela hamar urte, Kubernetes eta Docker ez direla nabarmen handitu. beharra bertan, aplikazioen ezarpena sinplifikatu izana mikrozerbitzu eleaniztun multzo gisa, baina, era berean, nabarmen murriztu kostuak funtzionamendurako, sidecar proxy flotak zabaltzeko eta laguntzeko mekanismoak eskainiz.
Zergatik hitz egiten da hainbeste zerbitzu sareari buruz?
Abisua: Atal honetan era guztietako hipotesiak, aieruak, asmakizunak eta barruko informazioa erabiltzen ditut.
Bilatu "zerbitzu-sarea" eta kaloria gutxiko eduki birziklatu ugari, proiektu bitxiak eta oihartzun-ganbera bat merezi duen distortsio-kaleidoskopio batekin aurkituko dituzu. Edozein teknologia berri dotoreek egiten dute hori, baina zerbitzu-sare baten kasuan arazoa bereziki larria da. Zergatik?
Beno, zati bat nire errua da. Lan handia egin dut Linkerd eta zerbitzu-sarea sustatzeko aukera guztietan blog-argitalpen eta artikulu hau bezalako artikulu ugariren bidez. Baina ez naiz horren indartsua. Galdera honi benetan erantzuteko, egoera orokorrari buruz pixka bat hitz egin behar dugu. Eta ezinezkoa da horretaz hitz egitea proiektu bat aipatu gabe: Google, IBM eta Lyft-ek elkarrekin garatutako kode irekiko zerbitzu-sare bat da.
(Hiru konpainiek oso rol desberdinak dituzte: Lyft-en inplikazioa izenez bakarrik agertzen da; Envoy-en egileak dira, baina ez dute Istio-ren garapenean erabiltzen edo parte hartzen. IBMk Istio-ren garapenean parte hartzen du eta erabiltzen du. Google-k aktiboki parte hartzen du Istio-ren garapenean. garapena, baina ez du erabiltzen nik esan dezakedan neurrian.)
Istio proiektua bi gauzagatik nabarmentzen da. Lehenik eta behin, Googlek, bereziki, hura sustatzeko egiten ari den marketin-esfortzu handia dago. Gaur egun zerbitzu-sarearen kontzeptua ezagutzen duten gehienek Istio-ren bitartez ezagutu dutela lehenengoz kalkulatuko nuke. Bigarren gauza da Istio zein harrera txarra izan zuen. Gai honetan, jakina, interesatua naiz, baina ahalik eta objektiboena izaten saiatzen, oraindik ezin dut lagundu , ez oso bereizgarria (bakarrik ez bada ere: systemd datorkit burura, ...) Open Source proiektu baterako.
(Praktikan, Istiok konplexutasunarekin eta UXrekin ez ezik, errendimenduarekin ere arazoak dituela dirudi. Adibidez, Hirugarrenen ikerketa batean, ikertzaileek Istioren buztanaren latentzia Linkerdena baino 100 aldiz handiagoa zen egoerak aurkitu zituzten, baita baliabiderik gabeko egoerak ere, non Linkerdek arrakastaz funtzionatzen jarraitu zuen Istiok guztiz funtzionatzeari utzi zion bitartean.)
Hori zergatik gertatu zenari buruzko nire teoriak alde batera utzita, zerbitzu sarearen inguruko zirrara izugarria Google-ren parte hartzearekin azaltzen dela uste dut. Hots, hiru faktore hauen konbinazioa:
- Google-ren Istio-ren sustapen intrusiboa;
- dagokion proiektuarekiko jarrera gaitzesgarria eta kritikoa;
- Kubernetesen azken ospearen gorakada meteorikoa, zeinaren oroitzapenak oraindik freskoak dira.
Faktore hauek batera, ingurune harrigarri eta oxigenorik gabekoa sortzen dute, non juzgazio arrazionalaren gaitasuna ahuldu eta barietate arraroa baino ez da geratzen. .
Linkerden ikuspegitik, hau da... bedeinkapen misto gisa deskribatuko nukeena. Esan nahi dut, bikaina da zerbitzu-sareak 2016an Linkerd hasi zenean sartu ez den moduan eta oso zaila izan zen jendeak proiektuari arreta jartzea. Orain ez dago horrelako arazorik! Baina albiste txarra da zerbitzu sarearen panorama hain nahasia dela gaur egun, ezen ia ezinezkoa dela ulertzea zerbitzu sarearen kategoriako proiektuak zeintzuk diren ulertzea (are gutxiago erabilera kasu jakin baterako zein den egokiena). Zalantzarik gabe, dealbreaker bat da guztiontzat (eta, zalantzarik gabe, badaude kasu batzuk non Istio edo beste proiektu bat Linkerd baino hobeto egokitzen den, azken hau oraindik ez baita irtenbide unibertsala).
Linkerden aldetik, gure estrategia zaratari jaramonik ez egitea izan da, komunitatearen benetako arazoak konpontzen jarraitzea eta, funtsean, iragarkia hil arte itxarotea. Azken finean, iragarkia baretu egingo da eta lasai lanean jarraitu ahal izango dugu.
Bitartean, denok pazientzia pixka bat izan beharko dugu.
Zerbitzu-sare bat baliagarria izango al zait software-ingeniari xume batentzat?
Galdetegi honek galdera honi erantzuten lagunduko dizu:
Negozio-logika inplementatzen bakarrik parte hartzen duzu? Kasu honetan, zerbitzu-sarea ez zaizu erabilgarria izango. Hau da, noski, interesatuko zaizula, baina hobe da zerbitzu-sareak ez luke zuzenean eragin behar zure ingurunean. Jarraitu ordaintzen dizutenagatik lanean.
Plataforma onartzen al duzu Kubernetes erabiltzen duen enpresa batean? Bai, kasu honetan zerbitzu-sare bat behar duzu (salbu, noski, K8ak monolito edo loteen prozesamendu bat exekutatzeko erabiltzen ari ez bazara, baina orduan galdetu nahiko nuke zergatik behar dituzun K8ak). Litekeena da pertsona ezberdinek idatzitako mikrozerbitzu askorekin amaituko duzula. Guztiak elkarreragiten dute eta exekuzio-denborako mendekotasun nahasketa batean lotuta daude, eta horri guztiari aurre egiteko modua aurkitu behar duzu. Kubernetes erabiliz, zerbitzu-sare bat "zuk" aukera dezakezu. Horretarako, ezagutu haien gaitasun eta ezaugarriak eta erantzun eskuragarri dauden proiekturen bat zuretzat egokia den ala ez (Linerd-ekin zure ikerketa hastea gomendatzen dut).
Kubernetes erabiltzen EZ duen baina mikrozerbitzuak erabiltzen dituen plataformako enpresa al zara? Kasu honetan, zerbitzu-sare bat erabilgarria izango zaizu, baina bere erabilera ez da hutsala izango. Noski ahal duzula imitatu lan-zerbitzuaren sare proxy mordo bat jarriz, baina Kubernetesen abantaila garrantzitsu bat hedapen-eredua da: proxy horiek eskuz mantentzeak askoz denbora, ahalegin eta gastu gehiago beharko ditu.
Plataformaren arduraduna zara monolitoekin lan egiten duen enpresa batean? Kasu honetan, ziurrenik ez duzu zerbitzu sarerik behar. Monolitoekin (edo baita monolito-bildumekin ere) ondo definituta eta oso gutxitan aldatzen diren elkarrekintza-ereduak dituzten monolitoekin lan egiten baduzu, zerbitzu-sare batek ezer gutxi izango dizu eskaintzeko. Beraz, ez ikusi egin dezakezu eta amets txar bat bezala desagertuko dela espero...
Ondorioa
Seguruenik, zerbitzu-sareak oraindik ez luke "munduko teknologiarik ospetsuena" deitu behar - zalantzazko ohore hau Bitcoin edo AIrena da ziurrenik. Ziurrenik lehen bosten artean dago. Baina zarata-geruzak mozten badituzu, argi geratzen da zerbitzu-sareak benetako onurak ekartzen dizkiela Kubernetesen aplikazioak eraikitzen dituztenei.
Linkerd probatzea gustatuko litzaidake: Kubernetes kluster batean instalatuz (edo baita Minikube ordenagailu eramangarri batean) , eta zuk zeuk ikusiko duzu zertaz ari naizen.
ohiko galderak
— Zerbitzu sarea alde batera uzten badut, desagertuko al da?
— Desilusionatu behar zaitut: zerbitzu-sarea gurekin dago denbora luzez.
- Baina EZ DUT NAHI zerbitzu sarerik erabili!
- Tira, ez da beharrezkoa! Irakurri goiko nire galdetegia, gutxienez bere oinarriak ezagutu behar dituzun ulertzeko.
— Ez al da ESB/erdiko tresna zahar ona saltsa berri batekin?
— Zerbitzu-sareak logika operatiboa lantzen du, ez semantikoa. enpresa zerbitzuen autobusa (). Bereizketa hori mantentzeak zerbitzu-sareak patu bera saihesten laguntzen du.
— Zertan desberdintzen da zerbitzu-sare bat API atebideetatik?
— Gai honi buruzko milioi bat artikulu daude. Google besterik ez.
— Envoy zerbitzu-sare bat da?
- Ez, Envoy ez da zerbitzu sare bat, proxy zerbitzari bat da. Zerbitzu-sare bat antolatzeko erabil daiteke (eta askoz gehiago - helburu orokorreko proxy bat da). Baina berez ez da zerbitzu sare bat.
— Network Service Mesh zerbitzu sare bat da?
- Ez. Izena izan arren, hau ez da zerbitzu sare bat (nola gustatzen zaizu marketin-mirariak?).
— Zerbitzu-sare batek lagunduko al du nire mezu-ilaran oinarritutako sistema asinkrono erreaktiboarekin?
- Ez, zerbitzu sareak ez dizu lagunduko.
— Zein zerbitzu-sare erabili behar dut?
- , burugabekeriarik ez.
- Izugarria da artikulua! / Egilea ongi etorria da!
— Mesedez, partekatu haren esteka zure lagun guztiekin ikus dezaten!
Eskerrak
Izenburuan asmatuko zenuten bezala, artikulu hau Jay Kreps-en tratatu zoragarrian inspiratu zen." Jay duela hamar urte ezagutu nuen Linked In-en elkarrizketatu nuenean eta harrezkero inspirazio bat izan da niretzat.
Nire buruari "Linkerd garatzaile" deitzea gustatzen zaidan arren, errealitatea da proiektu bateko README.md fitxategiaren mantentzaile bat baino gehiago naizela. Linkerd lantzen ari dira gaur , , jendea, eta proiektu hau ez zen gertatuko laguntzaile eta erabiltzaileen komunitate zoragarri baten parte-hartzerik gabe.
Eta azkenik, esker bereziak Linkerd-en sortzaileari, (primus inter pares), duela urte asko nirekin batera buru-belarri murgildu zen zalaparta horretan zerbitzu sarearekin.
PS itzultzailetik
Irakurri ere gure blogean:
- «»;
- «»;
- «»;
- «»;
- «'.
Iturria: www.habr.com