Kaixo berriro!.. Kurtso hasiera bezperan Beste itzulpen erabilgarria prestatu dugu.
Zerbitzu-sare bat aplikazioen programazio-interfazeen (API) arteko sarean oinarritutako prozesuen arteko komunikazio-bolumen handiak kudeatzeko behar den azpiegitura-geruza konfiguragarria eta latentzia txikia da. Service Mesh-ek komunikazio azkar, fidagarri eta segurua ahalbidetzen du edukiontzidun eta askotan iragankorrak diren aplikazio-azpiegitura zerbitzuen artean. Service Mesh-ek zerbitzuen aurkikuntza, karga orekatzea, enkriptatzea, gardentasuna, trazabilitatea, autentifikazioa eta baimena eta itzaltze automatikoko ereduen laguntza bezalako gaitasunak eskaintzen ditu (etengailua).
Zerbitzu-sare bat zerbitzu-instantzia bakoitzari proxy instantzia bat emanez inplementatzen da normalean Sidecar. Sidecar zerbitzuen arteko komunikazioak kudeatu, segurtasun-arazoak kontrolatu eta konpontzeko, hau da, banakako zerbitzuetatik abstrai daitekeen guztia. Horrela, garatzaileek aplikazio-kodea idatzi, mantendu eta hornitu dezakete zerbitzuetan, eta sistema-administratzaileek Service Mesh-ekin lan egin eta aplikazioa exekutatu dezakete.
Google, IBM eta Lyft-en Istio da gaur egun zerbitzu-sare-arkitektura ospetsuena. Eta Kubernetes, jatorriz Googlen garatu zena, gaur egun Istio-k onartzen duen edukiontzien orkestrazio-esparru bakarra da. Saltzaileak Istio-ren komertzialki onartzen diren bertsioak sortzen saiatzen ari dira. Interesgarria izango da kode irekiko proiektura zer gauza berri ekar ditzaketen ikustea.
Hala ere, Istio ez da aukera bakarra Service Mesh inplementazio batzuk garatzen ari baitira. Eredua sidecar proxy inplementazio ezagunena da, Buoyant, HashiCorp, Solo.io eta beste proiektuek epaitu dezaketen bezala. Arkitektura alternatiboak ere badaude: Netflix teknologia-tresnak Service Mesh funtzionaltasuna Ribbon, Hysterix, Eureka, Archaius liburutegien bidez inplementatzen den ikuspegietako bat da, baita Azure Service Fabric bezalako plataformetan ere.
Service Mesh-ek bere terminologia ere badu zerbitzu-osagai eta funtzioetarako:
- Edukiontzien orkestrazio esparrua. Aplikazio-azpiegiturara gero eta edukiontzi gehiago gehitzen diren heinean, edukiontziak kontrolatzeko eta kudeatzeko tresna bereizi bat behar da: edukiontzien orkestrazio esparrua. Kubernetes-ek tinko okupatu du nitxo hau, hainbesteraino non bere lehiakide nagusiek Docker Swarm eta Mesosphere DC/OS-ek Kubernetes-ekin integrazioa eskaintzen baitute alternatiba gisa.
- Zerbitzuak eta Instantziak (Kubernetes Pods). Instantzia bat mikrozerbitzu baten kopia bakarra da. Batzuetan kasu bat edukiontzi bat da. Kubernetesen, instantzia bat pod izeneko edukiontzi independente talde txiki batek osatzen du. Bezeroak oso gutxitan sartzen dira zuzenean instantzia edo pod batera; maizago, zerbitzu batera sartzen dira, hau da, instantzia edo pod (erreplikak) berdin, eskalagarri eta akatsekiko tolerantzia duten multzoa.
- Sidecar Proxy. Sidecar Proxy-ak instantzia edo pod bakar batekin funtzionatzen du. Sidecar Proxy-ren helburua lan egiten duen edukiontzitik datorren trafikoa bideratzea edo proxy-a eta trafikoa itzultzea da. Sidecar-ek beste Sidecar Proxiekin elkarreragin egiten du eta orkestrazio-esparru batek kudeatzen du. Service Mesh-en inplementazio askok Sidecar Proxy erabiltzen dute instantzia edo pod batetik sartu eta ateratzen den trafiko guztia atzemateko eta kudeatzeko.
- Zerbitzuaren Aurkikuntza. Instantzia batek beste zerbitzu batekin komunikatu behar duenean, beste zerbitzuaren instantzia osasuntsu eta erabilgarri bat aurkitu (aurkitu) behar du. Normalean, instantziak DNS bilaketak egiten ditu. Edukiontzien orkestrazio esparruak eskaerak jasotzeko prest dauden instantzien zerrenda mantentzen du eta DNS kontsultak egiteko interfaze bat eskaintzen du.
- Karga orekatzea. Edukiontzien orkestrazio-esparru gehienek karga orekatzea eskaintzen dute 4. geruzan (garraioa). Service Mesh-ek karga-oreka konplexuagoa ezartzen du 7. geruzan (aplikazio-mailan), algoritmoetan aberatsa eta trafikoa kudeatzeko eraginkorragoa. Karga orekatzeko ezarpenak APIa erabiliz alda daitezke, urdin-berdeak edo kanariar inplementazioak antolatzeko aukera emanez.
- enkriptatze. Service Mesh-ek eskaerak eta erantzunak enkriptatu eta desenkriptatu ditzake, zerbitzuetatik zama hori kenduz. Service Mesh-ek errendimendua hobe dezake lehendik dauden konexio iraunkorrak lehenetsiz edo berrerabiliz, konexio berriak sortzeko konputazio garestiaren beharra murriztuz. Trafiko enkriptatzea da ohikoena elkarrekiko TLS (mTLS), non gako publikoko azpiegiturak (PKI) ziurtagiriak eta gakoak sortzen eta banatzen dituen Sidecar Proxy-k erabiltzeko.
- Autentifikazioa eta Baimena. Service Mesh-ek aplikazioaren kanpotik edo barrutik egindako eskaerak baimendu eta autentifikatu ditzake, instantziari baliozkotutako eskaerak soilik bidaliz.
- Automatikoki itzaltzeko ereduaren laguntza. Service Mesh euskarriak , osasungaitzak diren instantzia isolatu eta gero pixkanaka instantzia osasuntsuen multzora itzultzen dituena behar denean.
Instantzia arteko sareko trafikoa kudeatzen duen Service Mesh aplikazio baten zatiari deitzen zaio Datuen planoa. Sortu eta zabaldu jokabidea kontrolatzen duen konfigurazioa Datuen planoa, bereizi bat erabiliz egiten da Kontrol-hegazkina. Kontrol-hegazkina normalean, aplikazioa kontrolatzeko API, CLI edo GUI batera konektatzeko diseinatuta dago.
Zerbitzu-sareko Kontrol Planak Sidecar Proxyaren eta Datu Planaren artean banatzen du konfigurazioa.
Service Mesh arkitektura sarritan erabiltzen da arazo operatibo konplexuak konpontzeko edukiontziak eta mikrozerbitzuak erabiliz. Arloan aitzindariak Lyft, Netflix eta Twitter bezalako enpresak dira, mundu osoko milioika erabiltzaileri zerbitzu egonkorrak eskaintzen dizkietenak. (). Ez hain zorrotzak diren aplikazioetarako, ziurrenik nahikoa izango da arkitektura sinpleagoak.
Service Mesh arkitektura ez da inoiz aplikazioen funtzionamendu eta entrega arazo guztien erantzuna izango. Arkitektoek eta garatzaileek tresna arsenal izugarria dute, eta horietako bakarra mailua da, eta, zeregin askoren artean, bakarra konpondu behar du: iltzeak mailutzea. , adibidez, mikrozerbitzuak erabiliz arazoak konpontzeko planteamendu jarraitu bat eskaintzen duten hainbat eredu biltzen ditu.
Service Mesh arkitektura batean elkartzen diren elementuak, hala nola NGINX, edukiontziak, Kubernetes eta mikrozerbitzuak ikuspegi arkitektoniko gisa, berdin produktiboak izan daitezke Service Mesh ez diren inplementazioetan. Esate baterako, Istio zerbitzu-sare-arkitektura oso gisa diseinatu zen, baina bere modulartasunak esan nahi du garatzaileek behar dituzten teknologia-osagaiak soilik hauta eta inplementa ditzaketela. Hori kontuan hartuta, garrantzitsua da Service Mesh kontzeptua argi ulertzea, nahiz eta ziur ez zauden inoiz zure aplikazioan guztiz inplementatu ahal izango duzun.
Iturria: www.habr.com