Shën. përk.: Rrjeti i shërbimeve — një fenomen që ende nuk ka një përkthim të qëndrueshëm në gjuhën shqipe (më shumë se 2 vite më parë, ne ofruam variantin "rrjet për shërbime", dhe pak më vonë disa kolegë filluan të promovojnë aktivisht kombinimin "sit për shërbime"). Bisedat e vazhdueshme për këtë teknologji çuan në një situatë ku përbërësit marketing dhe teknik janë tepër të ndërthurur. Ky material i shkëlqyer nga një nga autorët e terminit origjinal ka për qëllim të sjellë qartësi për inxhinierët dhe jo vetëm.
Komiku nga
Hyrje
Nëse jeni inxhinier programues, duke punuar ndonjëherë në sistemet e prapme, termi "rrjeti i shërbimeve", ndoshta, tashmë është përcaktuar fort në mendjen tuaj gjatë dy viteve të fundit. Falë një rastësie të çuditshme, kjo frazë po kap gjithnjë e më shumë industrinë, dhe hype dhe ofertat lidhur me të po rriten si një top bore që po bie poshtë një kodrine dhe nuk jep asnjë shenjë ngadalësimi.
Rrjeti i shërbimeve u lind në ujërat e errëta e të tendosura të ekosistemit cloud native. Fatkeqësisht, kjo do të thotë se një pjesë e konsiderueshme e polemikave rreth tij variojnë nga "biseda të ulëta" deri në — nëse e përdorim termin teknik — thjesht marrëzi. Por nëse filtrojmë gjithë zhurmën, mund të zbulojmë se rrjeti i shërbimeve ka një funksion të vërtetë, të caktuar dhe të rëndësishëm.
Në këtë publikim unë do të përpiqem ta realizoj këtë: të paraqes një udhëzues të ndershëm, të thellë dhe të orientuar për inxhinierët për rrjetin e shërbimeve. Kam për qëllim të përgjigjem jo vetëm në pyetjen: “Çfarë është?”, — por edhe “Pse?”, dhe gjithashtu “Pse pikërisht tani?”. Në fund, do të përpiqem të skicoj se pse (sipër mendimit tim) kjo teknologji ka nxitur një kaq të çmendur interes, që vetë është një histori interesante.
Kush jam unë?
Përshëndetje të gjithëve! Më quaj . Jam një nga krijuesit e — projekti i parë i rrjetit të shërbimeve dhe projekti që është fajtor për shfaqjen e termit service mesh si i tillë (më vjen keq, djem!). (Përkthim nga.: për të thënë, në fillim të shfaqjes së këtij termi, më shumë se 2.5 vite më parë, ne tashmë kemi përkthyer një material të hershëm të autorit të njëjtë të titulluar».) Gjithashtu, drejtoj — një startup që merret me krijimin e gjërave të mrekullueshme për rrjetin e shërbimeve si Linkerd dhe .
Ju ndoshta e kuptoni se kam një opinion mjaft subjektiv dhe të njëanshëm për këtë çështje. Megjithatë, do të përpiqem ta reduktoj tendencën e njëanshmërisë (përveç një seksioni: “Përse ka kaq shumë biseda për rrjetin e shërbimeve?”, — në të cilin do të ndaj idetë e mia të njëanshme). Gjithashtu do të bëj gjithçka që mundem për ta bërë këtë udhëzues sa më objektiv të jetë e mundur. Në shembujt konkretë do të mbështetem kryesisht në përvojën e Linkerd, duke treguar dallimet që di (nëse ato ekzistojnë) në zbatimin e llojeve të tjera të rrjeteve të shërbimeve.
Ok, është koha të kalojmë në gjërat e këndshme.
Çfarë është rrjeti i shërbimeve?
Pavarësisht të gjithë hype-it, struktura e rrjetit të shërbimeve është mjaft e thjeshtë. Kjo është thjesht një grup proxy-esh në hapësirë përdoruesi, të vendosura "pranë" shërbimeve (më vonë do të flasim pak mbi atë që do të thotë "pranë"), plus një grup procesesh administrative. Proxy-të së bashku kanë emrin data plane, dhe proceset administrative quhen control plane. Data plane kap thirrjet midis shërbimeve dhe bën "ndryshime" me to; control plane, përkatësisht, koordinon sjelljen e proxy-ve dhe siguron akses për ju, pra për operatorin, në API, duke ju lejuar të manovroni rrjetin dhe ta matni atë si një tërësi.
Çfarë janë këto proxy? Këto janë TCP-proxy të kategorisë "Layer 7-aware" (dmth. "të ndjeshëm" ndaj nivelit 7 të modelit OSI) si HAProxy dhe NGINX. Mund të zgjidhni proxy sipas dëshirës tuaj; Linkerd përdor një proxy në Rust, të quajtur thjesht . E kemi ndërtuar posaçërisht për rrjetin e shërbimeve. Meshët e tjera preferojnë proxy të ndryshme (Envoy është një zgjedhje e zakonshme). Megjithatë, zgjedhja e proxy-ve është thjesht një çështje e zbatimit.
Çfarë bëjnë këto serverë proxy? Është e qartë, ata bëjnë proxy për thirrjet në shërbime dhe nga shërbimet (saktësisht, ata kryejnë funksionin e proxy dhe reverse proxy, duke trajtuar si thirrjet që vijnë ashtu edhe ato që dalin). Dhe ata implementojnë një grup funksionesh që përqendrohet në thirrjet ndërmjet shërbimeve. Ky fokus në trafik ndërmjet shërbimeve e ndan rrjetin e shërbimeve nga, le të themi, portat e API-së ose proxy-të e ingress-it (të fundit fokusohet në thirrjet që vijnë në grup nga bota e jashtme). (Shën. përk.: krahasimi i kontrollorëve ekzistues të Ingress për Kubernetes, shumica e të cilëve përdorin atë që u përmend më parë, Envoy, mund të shihet në .)
Pra ndaj, e kuptuam data plane. Control plane është më e thjeshtë: është një grup komponentësh që sigurojnë të gjithë mekanikën e nevojshme për data plane që të funksionojë në mënyrë të koordinuar, duke përfshirë zbulimin e shërbimeve, lëshimin e certifikatave TLS, agregimin e metrikave etj. Data plane informon control plane për sjelljen e saj; nga ana e saj, control plane ofron një API që lejon ndryshimin dhe monitorimin e sjelljes së data plane si një tërë.
Më poshtë është një diagram i control plane dhe data plane në Linkerd. Siç duket, control plane përfshin disa komponentë të ndryshëm, përfshirë një instancë të Prometheus, e cila mbledh metrika nga serverat proxy, si dhe komponentë të tjerë, si destinacioni (zbulimi i shërbimeve), token-in e identitetit (qendra e certifikimit, CA) dhe public-api (endpoint’ët për web dhe CLI). Ndryshe nga kjo, data plane përfaqëson një linkerd-proxy të thjeshtë pranë instancës së aplikacionit. Kjo është vetëm një skemë logjike; në kushte reale gjatë implementimit mund të keni tri replika të çdo komponenti control plane dhe qindra ose mijëra proxy në data plane.
(Kat-ë e kaltër në këtë diagram simbolizojnë kufijtë e pod-ëve Kubernetes. Duket se konteinerët me linkerd-proxy ndodhen në të njëjtin pod me konteinerët e aplikacionit. Një skemë e tillë njihet si sidecar-container..)
Arkitektura e service mesh ka disa pasoja të rëndësishme. Së pari, pasi detyra e proxy është të kapë thirrjet midis shërbimeve, service mesh ka kuptim vetëm nëse aplikacioni juaj është ndërtuar mbi një set të caktuar shërbimesh. Mesh mund të mund të përdoret me monolite, por është qartazi e tepërt për një vetëm proxy, dhe funksionaliteti i saj me siguri nuk do të kërkohet.
Një tjetër pasojë e rëndësishme është se service mesh kërkon një numër të madh proxy. Në të vërtetë, Linkerd lidh linkerd-proxy me çdo instancë të çdo shërbimi (implementime të tjera shtojnë proxy në çdo nod/houst/makinë virtuale. Në çdo rast, kjo nuk është pak). Ky përdorim aktiv i proxy vetë sjell një sërë komplikimesh të tjera:
- Proxy në data plane duhet të jenë të shpejtë,pasi çdo thirrje ka një çift kërkesash nga proxy: një në anën e klientit, një në anën e serverit.
- Gjithashtu, proxy duhet të jenë të vogla, dhe të lehta.Çdo numër do të konsumojë burime memorjeje dhe CPU, dhe ky konsum do të rritet linearisht me aplikacionin.
- Do t'ju nevojitet një mekanizëm për të deployuar dhe përditësuar një numër të madh proxy. Të bëni këtë manualisht nuk është një opsion.
Në përgjithësi, service mesh duket kështu (të paktën nga lart): ju deployoni një grup proxy userspace, të cilët "bëjnë diçka" me trafikun e brendshëm midis shërbimeve dhe përdorni control plane për t'i monitoruar dhe menaxhuar ato.
Ka ardhur koha për pyetjen "Pse?"
Çfarë përdorimi ka service mesh?
Ata që përballen për herë të parë me idenë e service mesh kanë të drejtë të ndihen disi të frikësuar. Strukturimi i service mesh do të thotë se jo vetëm që do të rrisë vonesat në aplikacion, por gjithashtu do të konsumojë burime dhe do të shtojë një sërë mekanizmash të rinj në infrastrukturë. Së pari, vendosni service mesh dhe pastaj papritur zbuloni se duhet të menaxhoni qindra (nëse jo mijëra) proxy. Pyetja është, kush do të bëjë këtë me dëshirë?
Përgjigja në këtë pyetje ka dy pjesë. Së pari, kostot operative që lidhen me implementimin e këtyre proxy mund të reduktohen ndjeshëm falë disa ndryshimeve që ndodhin në ekosistem (më shumë rreth kësaj më vonë).
Së dyti, një dizajn i tillë është në të vërtetë një mënyrë e shkëlqyer për të sjellë logjik më të avancuar në sistem. Dhe jo vetëm sepse me ndihmën e service mesh mund të shtoni shumë funksione të reja, por gjithashtu sepse mund ta bëni këtë pa ndërhyrë në ekosistemin. Në fakt, e gjithë modeli i service mesh bazohet në këtë postulant: në një sistem me shumë shërbime, pavarësisht se çfarë bëjnë shërbimet e veçanta, trafiku midis tyre është pika ideale për të shtuar funksionalitet.
Për shembull, në Linkerd (ashtu si në shumicën e mesh-eve), funksionaliteti fokusohet kryesisht në thirrjet HTTP, duke përfshirë HTTP/2 dhe gRPC*. Funksionaliteti është abbastanza i pasur - ai mund të ndahen në tre klasa:
- Funksionet lidhur me besueshmëria. Kërkesat e përsëritura, kohët e pritjes, qasja kanari (ndarja/rimëkëmbja e trafikut) etj.
- Funksionet lidhur me monitorimi.. Agregimi i indikatorëve të suksesshëm, vonesave dhe vëllimeve të kërkesave për çdo shërbim ose për drejtime të veçanta; ndërtimi i hartave topologjike të shërbimeve etj.
- Funksionet lidhur me siguria. Mutual TLS, kontrolli i aksesit etj.
* Nga pikëpamja e Linkerd, gRPC pothuajse nuk diferencohet nga HTTP/2: thjesht në ngarkesën e dobishme përdoret protobuf. Nga pikëpamja e zhvilluesit, këto dy gjëra, sigurisht, ndryshojnë.
Shumë prej këtyre mekanizmave funksionojnë në nivelin e kërkesave (këtu vjen dhe "L7-proxy"). Për shembull, nëse shërbimi Foo dërgon një thirrje HTTP në shërbimin Bar, linkerd-proxy në anën e Foo mund të bëjë balancimin e ngarkesës në mënyrë inteligjente dhe të drejtojë thirrjet nga Foo në instancat e Bar në varësi të vonesës së vëzhguar; mund të ripërsërisë kërkesën nëse është e nevojshme (dhe nëse ajo është idempotente); mund të regjistrojë kodin e përgjigjes dhe kohën e pritjes, etj. Në të njëjtën mënyrë, linkerd-proxy në anën e Bar mund të refuzojë kërkesën nëse ajo nuk është e lejuar ose kalon kufirin e kërkesave; mund të regjistrojë vonesën nga ana e tij, etj.
Proxyt mund të "bëjnë diçka" edhe në nivelin e lidhjes. Për shembull, linkerd-proxy në anën e Foo mund të nisë një lidhje TLS, ndërsa linkerd-proxy në anën e Bar – ta ndërpresë atë, dhe të dy palët mund të verifikojnë certifikatat TLS të njëri-tjetrit*. Kjo siguron jo vetëm enkriptim midis shërbimeve, por edhe një mënyrë kriptografike të sigurt për identifikimin e shërbimeve: Foo dhe Bar mund të "provokojnë" se ata janë këta që pretendojnë të jenë.
* "Njëri-tjetri" do të thotë se certifikata e klientit gjithashtu verifikohet (mutual TLS). Në TLSin "e zakonshëm", për shembull, midis shfletuesit dhe serverit, zakonisht verifikohet vetëm certifikata e një ane (serverit).
Pavarësisht nëse ata funksionojnë në nivelin e kërkesave apo lidhjeve, është e rëndësishme të theksohet se të gjitha funksionet e service mesh janë operacionale natyre. Linkerd nuk është në gjendje të transformojë semantikën e ngarkesës së dobishme – për shembull, të shtojë fushat në fragmentin JSON ose të bëjë ndryshime në protobuf. Këtë karakteristikë të rëndësishme do ta diskutojmë më vonë, kur të flasim për ESB dhe middleware.
Kështu është grupi i funksioneve që ofron service mesh. Kjo ngre pyetjen: pse t'i implementojmë ato drejtpërdrejt në aplikacion?
Pse service mesh është një ide e mirë
Ndërsa mundësitë e service mesh e kapin imagjinatën, vlera e saj kryesore në të vërtetë nuk qëndron në funksionalitete. Në fund të fundit, ne mundemi mund t'i implementojmë ato drejtpërdrejt në aplikacion (më vonë do të shohim se kjo ishte origjina e service mesh). Nëse do të përpiqeshim ta shpreh nik këtë ide në një fjalë, vlera e service mesh është: ajo ofron funksione, të cilat janë thelbësore për punën e softuerit modern të serverit, në një mënyrë të njëtrajtshme për të gjithë grumbullin dhe të pavarura nga kodi i aplikacionit..
Le të analizojmë këtë frazë.
«Funksione, të cilat janë thelbësore për punën e softuerit modern të serverit. Nëse po krijoni një aplikacion serveri transaksional, i lidhur me internetin publik, që merr kërkesa nga bota e jashtme dhe përgjigjet aty për aty – për shembull, një aplikacion web, një server API, dhe të shumtën e aplikacioneve moderne tjera, – dhe nëse e implementoni atë si një grup shërbimesh, të cilat ndërveprojnë njëra me tjetrën në mënyrë sinkrone, dhe nëse po modernizoni vazhdimisht këtë softuer, duke shtuar mundësi të reja, dhe nëse jeni të detyruar të mbani këtë sistem në gjendje funksionimi gjatë procesit të modifikimit – në këtë rast, urime, po merret me krijimin e një softueri serveri modern. Dhe të gjitha këto funksione të mrekullueshme, të listuara më sipër, në të vërtetë rezultojnë të jenë thelbësore për ju. Aplikacioni duhet të jetë i besueshëm, i sigurt, dhe ju duhet të keni mundësinë të vëzhgoni atë që bën. Këto pyetje pikërisht i ndihmon të zgjidhë service mesh.
(Ok, në paragrafin e mëparshëm u fut besimi im se ky qasje është një mënyrë moderne për të krijuar softuer serveri. Të tjerë preferojnë të zhvillojnë monolite, "mikroshërbime reaktive" dhe gjëra të tjera që nuk bien nën përkufizimin e dhënë më sipër. Këta njerëz sigurisht që kanë mendimet e tyre, të ndryshme nga të miat. Nga ana ime, mendoj se ata "nuk kanë të drejtë" – megjithatë, në çdo rast, service mesh nuk është shumë e dobishme për ta).
«Të njëtrajtshme për të gjithë grumbullin. Funksionet që ofrohen nga service mesh nuk janë vetëm thelbësore. Ato zbatohen për të gjithë shërbimet në aplikacion pa marrë parasysh se në cilin gjuhë janë shkruar, cilin kuadër përdorin, kush i krijoi, si u shpërndan dhe nga të gjitha nuancat e tjera të zhvillimit dhe përdorimit të tyre.
«Të pavarur nga kodi i aplikacionitNë fund, service mesh jo vetëm që ofron funksionalitete të njëjta për të gjithë stakun — ajo e bën këtë në një mënyrë që nuk kërkon ndryshime në aplikacion. Themeli i funksionalitetit të service mesh, duke përfshirë detyrat për konfigurimin, përditësimin, operimin, mirëmbajtjen etj., ndodhet ekskluzivisht në nivelin e platformës dhe është i pavarur nga aplikacioni. Aplikacioni mund të ndryshojë pa prekur service mesh. Nga ana e saj, service mesh mund të ndryshojë pa asnjë përfshirje të aplikacionit.
Në përmbledhje, service mesh jo vetëm që ofron funksione jetike, por e bën këtë në një mënyrë globale, uniformë dhe të pavarur nga aplikacioni. Prandaj, ndërsa funksionaliteti i service mesh mund të realizohet në kodin e shërbimit (p.sh., si një bibliotekë e inkorporuar në çdo shërbim), ky qasje nuk do të sigurojë njëtrëshmërinë dhe pavarësinë, aq të çmuara në rastin e service mesh.
Dhe gjithçka që nevojitet është të shtoni një grup proxysh! Premtoj, shumë shpejt do të shqyrtojmë kostot operacionale të lidhura me shtimin e këtyre proxyve. Por së pari, le të ndalemi dhe të shikojmë këtë ide të pavarësisë nga këndvështrimi i ndryshëm njerëzish.
Kush përfitohet nga service mesh?
Sa e pakëndshme që mund të jetë, për një teknologji që të bëhet një pjesë e rëndësishme e ekosistemit, ajo duhet të pranohet nga njerëzit. Pra, kush është i interesuar për service mesh? Kush përfiton nga përdorimi i saj?
Nëse po zhvilloni softuer modern serverësh, mund ta imagjinoni ekipin tuaj si një grup pronarësh shërbimesh, të cilët së bashku zhvillojnë dhe zbatojnë logjikën e biznesit, dhe pronarësh platforme, që merren me zhvillimin e platformës së brendshme që këto shërbime funksionojnë. Në organizatat e vogla, këto mund të jenë të njëjtat persona, por me rritjen e kompanisë, këto role zakonisht bëhen më të dukshme dhe madje ndahen në nën-role... (Këtu mund të thuhet shumë për natyrën në ndryshim të devops-it, ndikimin organizativ të mikro-shërbimeve etj. Por për momentin le ta pranojmë këto përshkrime si të vërteta).
Në këtë këndvështrim, përfitues të dukshëm të service mesh janë pronarët e platformës. Sepse në fund, qëllimi i ekipit të platformës është të krijojë një platformë të brendshme, ku pronarët e shërbimeve mund të zbatojnë logjikën e biznesit në një mënyrë që garanton maksimale pavarësinë e tyre nga detajet e errëta të operimit të saj. Service mesh jo vetëm që ofron mundësi, të cilat janë kritike për arritjen e këtij qëllimi: ajo e bën këtë në një mënyrë që, nga ana tjetër, nuk paraqet varësira për pronarët e shërbimeve.
Pronaret e shërbimeve gjithashtu përfitojnë, megjithëse në një mënyrë më të ndërmjetësuar. Qëllimi i pronarit të shërbimit është të jetë sa më produktiv në zbatimin e logjikës së procesit të biznesit, dhe sa më pak të ketë për të kujdesur për çështjet e operimit, aq më mirë. Në vend që të merret me implementimin, le të themi, të politikave të ripërsëritjeve ose TLS, ata mund të përqendrohen vetëm në detyrat e biznesit dhe të shpresojnë se platforma do të kujdeset për gjithçka tjetër. Për ta, kjo është një avantazh i madh.
Vlera organizative e kësaj ndarjeje mes pronarëve të platformës dhe shërbimeve është e vështirë të njihet shumë. Mendoj se ajo sjell të parin kontribut në vlerën e service mesh.
Ne e kemi marrë mësimin kur një nga adhuruesit e parë të Linkerd na tregoi se pse e zgjodhën service mesh: sepse ajo u lejon të 'minimizojnë bisedat'. Ja disa detaje: djemtë nga një kompani e madhe migruan platformën e tyre në Kubernetes. Duke qenë se aplikacioni punonte me informacione të ndjeshme, ata donin të enkriptojnë të gjitha komunikimet në klasterë. Megjithatë, situata u komplikuar me qindra shërbime dhe qindra ekipe zhvilluesish. Perspektiva e lidhjes me të gjithë dhe bindjes për të mbështetur TLS në planet e tyre nuk ishte aspak e këndshme për ta. Duke instaluar Linkerd, ata e shpërndanë përgjegjësinë nga zhvilluesit (nga këndvështrimi i të cilëve ishte një shqetësim i panevojshëm) te platformuesit, për të cilët ishte një prioritet i nivelit të lartë. Me fjalë të tjera, Linkerd po zgjidhte për ta jo vetëm njëproblem teknik, por një problem organizativ.
Në përmbledhje, service mesh është, më shumë se gjithçka, një zgjidhje jo teknike, por socio-teknike problemi. (Faleminderit për njohjen me këtë term.)
A do ta zgjidhë service mesh të gjitha problemet e mia?
Po. Në kuptimin, jo!
Duke parë klasat e tre funksioneve, të përmendura më sipër: besueshmëria, siguria dhe mbikëqyrja, bëhet e qartë që service mesh nuk është një zgjidhje e plotë për asnjërën nga këto probleme. Ndërsa Linkerd mund të dërgojë kërkesa të përsëritura (nëse di se ato janë idempotente), ai nuk është në gjendje të marrë vendime mbi atë që duhet të kthejë përdoruesit, nëse shërbimi ka rënë përfundimisht — këto vendime duhet t'i marrë aplikacioni. Linkerd mund të bëjë statistika të kërkesave të suksesshme, megjithatë ai nuk është në gjendje të shohë brenda shërbimit dhe të ofrojë metrikat e tij të brendshme — një mjet i tillë duhet të jetë në aplikacion. Dhe megjithëse Linkerd është në gjendje të organizojë mTLS, zgjidhjet e plota për sigurimin kërkojnë shumë më tepër.
Një nëngrup funksionesh në këto fusha, të ofruara nga service mesh, i përkasin karakteristikave të platformës. Me këtë kam parasysh funksione që:
- janë të pavarura nga logjika biznesore. Mënyra se si ndodhin histogramet e thirrjeve midis Foo dhe Bar nuk varet aspak nga pse Foo që thërret Bar.
- Është e vështirë të zbatohet siç duhet. Në Linkerd, përpjekjet e përsëritura parametrizohen nga gjëra të ndërlikuara si buxhetet e përsëritjeve (retry budgets), pasi një qasje e thjeshtë në zbatimin e gjërave të tilla do të çojë sigurisht në fenomenin e njohur si "stuhi kërkesash" (retry storm) dhe probleme të tjera të zakonshme për sistemet e shpërndara.
- Janë më efektive kur aplikohen në mënyrë uniforme. Mekanizmi TLS ka kuptim vetëm kur përdoret gjithandej.
Duke qenë se këto funksione zbatohen në nivelin e proxy (e jo në nivelin e aplikacionit), service mesh i ofron ato në nivelin platforma, e jo në atë të aplikacionit. Prandaj, nuk ka rëndësi se në cilin gjuhë janë shkruar shërbimet, cili është kuadri që ata përdorin, kush i shkroi ato dhe pse. Proxy-t funksionojnë jashtë të gjitha këtyre detajeve, dhe baza themelore e kësaj funksionaliteti, duke përfshirë detyrat e konfigurimit, përditësimit, operimit, mbajtjes, etj., mbetet ekskluzivisht në nivelin e platformës.
Shembuj të mundësive të service mesh
Në përfundim, do të doja të thosha se service mesh nuk është një zgjidhje e plotë për sigurimin e besueshmërisë, vëzhgueshmërisë ose sigurisë. Gjerësia e këtyre fushave implicon përfshirjen e detyrueshme të pronarëve të shërbimeve, ekipeve Ops/SRE dhe subjekteve të tjera të kompanisë. Service mesh ofron vetëm një "sipp" në nivelin e platformës për secilën nga këto fushat.
Pse service mesh është bërë kaq popullor tani?
Ndoshta, aktualisht po pyesni vetën: mirë, nëse service mesh është kaq e mirë, pse nuk filluam të shpërndanim miliona proxy në skenën që 10 vjet më parë?
Ka një përgjigje të thjeshtë për këtë pyetje: 10 vjet më parë të gjithë ndërtuan monolite, dhe service mesh nuk i nevojitej askujt. Kjo është e vërtetë, por, sipas mendimit tim, në një përgjigje të tillë humbet thelbi. Edhe 10 vjet më parë, koncepti i mikroshërbimeve si një qasje e potenciale për ndërtimin e sistemeve me shkallë të madhe u diskutua gjerësisht dhe u aplikua në kompanitë si Twitter, Facebook, Google dhe Netflix. Pershtypja e përgjithshme - së paku në ato pjesë të industrisë me të cilat kam kontaktuar - ishte se mikroshërbimet janë " mënyra e duhur" për ndërtimin e sistemeve të mëdha, edhe nëse ishte një punë e vështirë.
Sigurisht, ndonëse 10 vjet më parë kishte kompani që përdornin mikroshërbime, ato nuk i vendosnin proxy kudo që ishin për të formuar service mesh. Megjithatë, nëse e shqyrtoni me kujdes, ato bënin diçka të ngjashme: në shumë prej këtyre kompanive ishte e detyrueshme të përdorej një bibliotekë të veçantë të brendshme për ndërveprimin në rrjet (ndonjëherë e quajtur biblioteka e klientit të trashë, fat client library).
Netflix kishte Hysterix, Google kishte Stubby, Twitter kishte bibliotekën Finagle. Finagle, për shembull, ishte e detyrueshme për çdo shërbim të ri në Twitter. Ajo trajtonte si anën e klientit ashtu edhe serverit të lidhjeve, lejonte përsëritjen e kërkesave, mbështeste ruterimin e kërkesave, balancimin e ngarkesës dhe matjet. Ajo ofronte një nivel të konsoliduar të besueshmërisë dhe vëzhgueshmërisë për të gjithë stakun e Twitter, pavarësisht se çfarë bënte saktësisht shërbimi. Sigurisht, ajo funksiononte vetëm për gjuhët që mbështesin JVM dhe bazohej në modelin e programimit që duhej përdorur për të gjithë aplikacionin. Megjithatë, funksionalitetet e saj ishin pothuajse të ngjashme me ato të service mesh. (Në të vërtetë, versioni i parë i Linkerd ishte thjesht një Finagle i mb wrapped në formën e një proxy.)
Para kësaj dite, dhjetë vjet më parë nuk ekzistonin vetëm mikrositë, por edhe biblioteka të posaçme proto-service-mesh që zgjidhin të njëjtat probleme që zgjidh service mesh sot. Megjithatë, vetë service mesh nuk ekzistonte ende. Duhej të ndodhte një tjetër ndryshim para se ajo të shfaqej.
Dhe këtu është përgjigja më e thellë, e fshehur në një tjetër ndryshim që ka ndodhur gjatë dhjetë viteve të fundit: ka ndodhur një ulje dramatike e kostos së zhvillimit të mikrositëve. Kompanitë e përmendura më sipër që përdornin mikrositë dhjetë vjet më parë: Twitter, Netflix, Facebook, Google, ishin kompani me shkallë të madhe dhe burime të mëdha. Ato jo vetëm që kishin nevojë, por gjithashtu mundësi për të ndërtuar, zhvilluar dhe operuar aplikacione të mëdha në bazë të mikrositëve. Energji dhe përpjekje që inxhinierët e Twitter i kushtuan kalimit nga një qasje monolite në një qasje mikrositë janë thjesht befasuese. (Sinqerisht, ashtu si fakti që kjo ia doli.) Lloje të tilla manovrash infrastrukturore ishin të pamundura për kompanitë më të vogla.
Le të kalojmë në të tashmen. Sot ekzistojnë startupe ku raporti i mikrositëve me zhvilluesit është 5:1 (ose madje ), dhe më shumë se kaq, ata po i menaxhojnë me sukses! Nëse një startup prej 5 personash ka kapacitetin të operojë 50 mikrositë pa vështirësi, atëherë diçka me siguri ka ulur kostot e implementimit të tyre.
1500 mikrositë në Monzo; çdo rresht është një rregull rrjeti i caktuar, që lejon trafik
Ulja dramatike e kostove të operimit të mikrositëve është rezultat i një procesi: rritjes së popullaritetit të kontejnerëve dhe orkestratorëve. Kjo është thelbi i përgjigjes së thellë për pyetjen se çfarë ka kontribuar në shfaqjen e service mesh. E njëjta teknologji e bëri tërheqëse si service mesh ashtu edhe mikrositët: Kubernetes dhe Docker.
Pse? Epo, Docker zgjidh një problem të madh - problemin e paketimit. Duke paketuar aplikacionin dhe varësitë e tij (jo rrjetë) runtime në një kontejner, Docker e kthen aplikacionin në një njësi të ndërmjetësueshme që mund të vendoset dhe ekzekutohet kudo. Në të njëjtën kohë, ai e thjeshton ndjeshëm operimin multiligjore stack: pasi kontejneri është një njësi atomike ekzekutimi, për qëllimet e vendosjes dhe operimit nuk ka rëndësi se çfarë është brenda, qoftë aplikacion në JVM, Node, Go, Python apo Ruby. Thjesht e nisni atë, dhe gjithçka është në rregull.
Kubernetes e çon gjithçka në një nivel tjetër. Tani, kur ka shumë "gjëra ekzekutueshme" dhe shumë makina ku mund t'i ekzekutoni ato, lind nevoja për një mjet që është në gjendje t'i përputhë ato me njëri-tjetrin. Në një kuptim të gjerë, ju i jepni Kubernetes shumë kontejnerë dhe shumë makina, dhe ai i përputh ato me njëri-tjetrin (sigurisht, ky është një proces dinamik dhe gjithmonë në ndryshim: kontejnerët e rinj lëvizin nëpër sistem, makinat nisin dhe ndalen etj. Por Kubernetes e merr parasysh këtë).
Pas konfigurimit të Kubernetes, kostot për vendosjen dhe operimin e një shërbimi dallohen pak nga këto për dhjetë shërbime (në të vërtetë, ato janë pothuajse të njëjta edhe për 100 shërbime). Shtoni këtu kontejnerët si mekanizëm paketimi që inkurajon zbatimin multilinguistik dhe merrni një mori aplikacionesh të reja të realizuara në formën e mikrositëve, të shkruara në gjuhë të ndryshme - pikërisht mjedisi për të cilin service mesh është kështu përshtatur nga ana e saj.
Pra, aritëm në përgjigjen për pyetjen se pse ideja e service mesh u bë e njohur tani: ajo homogjenitet që Kubernetes ofron për shërbimet, është drejtpërdrejt e aplikueshme për detyrat operative përpara service mesh. Ju paketoni proxy në kontejnerë, i jepni Kubernetes detyrën t'i vendosë kudo që është e mundur, dhe voila! Në fund merrni service mesh, ndërsa e gjitha mekanika e vendosjes së saj menaxhohet nga Kubernetes. (Të paktën, nga një perspektivë e lartë. Natyrisht, në këtë proces ka një mori nuancash.)
Me një përmbledhje: arsyeja pse service mesh u bë e njohur tani dhe jo dhjetë vjet më parë është se Kubernetes dhe Docker jo vetëm që rritën ndjeshëm nevojën për të, duke e thjeshtuar implementimin e aplikacioneve si grupe mikrositësh multilinguistikë, por gjithashtu reduktuan ndjeshëm kostot e operimit të saj, duke siguruar mekanizma për vendosjen dhe mbështetje për parkingjet e proxy-ve sidecar.
Pse ka kaq shumë biseda rreth service mesh?
Kujdes: në këtë seksion, unë kam recourse në supozime të ndryshme, hamendje, spekulime dhe informacion brenda.
Duke kërkuar për frazën «service mesh», do të përballeni me një mori përmbajtjeje të ricikluar, projekte të çuditshme dhe një kaleidoskop të deformimeve që janë të merituara për dhomën e jehonës. Kjo është e zakonshme për çdo teknologji të re në modë, por në rastin e service mesh, problemi është veçanërisht i theksuar. Pse?
Epo, pjesërisht është faji im. Unë kam bërë gjithçka për të promovuar Linkerd dhe service mesh në çdo rast të mundshëm, përmes postimeve të pafundme në blog dhe artikuj si ky. Por unë nuk jam aq i fuqishëm. Për të përgjigjur seriozisht këtë pyetje, duhet të flasim pak për situatën e përgjithshme. Dhe për të folur për këtë, nuk mund të shmangim një projekt të caktuar: — një service mesh me burim të hapur, e zhvilluar në bashkëpunim me Google, IBM dhe Lyft.
(Këto tre kompani kanë role tërësisht të ndryshme: pjesëmarrja e Lyft duket se është vetëm me emrin; ata janë autorët e Envoy, por nuk e përdorin Istio dhe nuk marrin pjesë në zhvillimin e tij. IBM është e angazhuar në zhvillimin e Istio dhe e përdor atë. Google është aktivisht e angazhuar në zhvillimin e Istio, por, siç mund të gjykoj, në të vërtetë nuk e përdor.)
Projekti Istio është i njohur për dy karakteristika. Së pari, janë përpjekjet e mëdha marketingu që Google, në veçanti, i bën për ta promovuar. Sipas vlerësimeve të mia, shumica e njerëzve që janë të informuar për konceptin e service mesh tani e kanë mësuar këtë për herë të parë falë Istio. Karakteristika e dytë është se sa keq është pranuar Istio. Në këtë çështje, unë, natyrisht, kam interes, por duke u përpjekur të mbetem sa më objektiv të jetë e mundur, nuk mund ta injoroj këtë. , nuk është shumë karakteristik (edhe pse nuk është unik; më vjen në mend systemd, …) për një projekt me burim të hapur.
(Në praktikë, duket se Istio ka probleme jo vetëm me kompleksitetin dhe UX, por gjithashtu me performancën. Për shembull, gjatë , të kryer nga një palë të tretë, specialistët zbuluan situata në të cilat vonesat tail të Istio ishin 100 herë më të lartë se niveli i ngjashëm për Linkerd, si dhe situata me mungesë burimesh, kur Linkerd vazhdonte të funksiononte me sukses, ndërsa Istio ndalte plotësisht.)
Duke lënë mënjanë teoritë e mia mbi arsyet pse ndodhi kështu, unë besoj se hype i tepruar rreth service mesh përkthehet pikërisht në përfshirjen e Google. Saktësisht, për kombinimin e tri faktorëve kryesorë:
- promovimi agresiv i Istio nga Google;
- një qëndrim përgjegjës, kritik ndaj projektit;
- ngritja e shpejtë e fundit e popullaritetit të Kubernetes, kujtimet e të cilit janë ende të freskëta.
Së bashku, këto faktorë bashkohen në një ambient dehës, pa oksigjen, në të cilin aftësia për gjykim të arsyeshëm dobësohet, dhe mbetet vetëm një lloj i mrekullueshëm .
Nga këndvështrimi i Linkerd, kjo është... do ta përshkruaja si një të mirë të dyshimtë. Do të thosha se është e mrekullueshme që service mesh është bërë mainstream – gjë që nuk ndodhi në vitin 2016, kur Linkerd sapo kishte dalë dhe ishte vërtet e vështirë të tërhiqje vëmendjen e të tjerëve ndaj projektit. Tani nuk ka më këtë problem! Por ndihmues është se situata me service mesh sot është aq e ngatërruar, saqë është praktikisht e pamundur të kuptohet se cilat projekte vërtet i përkasin kategorisë së service mesh (pa përmendur se cili prej tyre është më i përshtatshmi për një rast të caktuar përdorimi). Kjo padyshim e pengon të gjithëve (dhe, sigurisht, në disa raste Istio ose ndonjë projekt tjetër është më i përshtatshëm se Linkerd, pasi ky i fundit nuk është ende një zgjidhje universale).
Nga ana e Linkerd, strategjia jonë ishte të injoronim zhurmën, të vazhdojmë të përqendrohemi në zgjidhjen e problemeve reale të komunitetit dhe, në thelb, të presim deri sa hype të qetësohet. Në fund të fundit, hype do të bie në rënie, dhe ne do të mund të vazhdojmë të punojmë në qetësi.
Në mesin e kësaj, të gjithë ne do të duhet të presim pak.
A do të më nevojitet service mesh si një inxhinier softueri modest?
Për të lidhur përgjigjen në këtë pyetje, do të ndihmojë anketa e mëposhtme:
A ju angazhoni vetëm në zbatimin e logjikës biznesore? Në këtë rast, service mesh nuk do t'ju nevojitet. Do të thosha, sigurisht, mund të jeni të interesuar për të, por idealisht service mesh nuk duhet të ndikojë direkt në asgjë në ambientin tuaj. Vazhdoni të punoni në atë për të cilën paguheni.
A mbani një platformë në një kompani që përdor Kubernetes? Po, ky rast, ju nevojitet një service mesh (natyrisht, nëse nuk po përdorni K8s vetëm për të drejtuar një monolit ose për përpunim grumbull, por atëherë do të doja të dija se pse ju nevojitet K8s). Me siguri do të përballeni me një situatë me shumë mikroshërbje, të shkruara nga njerëz të ndryshëm. Të gjitha këto ndërveprojnë me njëra-tjetrën dhe janë të lidhura në një rrjet të varësive runtime, dhe ju duhet të gjeni një mënyrë për t'u përballur me gjithçka këtë. Përdorimi i Kubernetes ju lejon të zgjidhni një service mesh që i përshtatet nevojave tuaja. Për këtë, shqyrtoni mundësitë dhe tiparet e tyre dhe përgjigjuni pyetjes nëse ndonjë projekt nga ato ekzistues u përshtatet juve (rekomandoj të filloni kërkimin me Linkerd).
A jeni duke u marrë me platformën në një kompani që NUK përdor Kubernetes, por përdor mikroshërbje? Në këtë rast, service mesh do t'ju jetë e dobishme, megjithatë përdorimi i saj do të jetë i komplikuar. Natyrisht, ju mund të imitojkë funksionimin e service mesh duke vendosur një sërë proxy, por avantazhi kryesor i Kubernetes është modeli i vendosjes: menaxhimi manual i këtyre proxy-ve do t'i kërkojë shumë më tepër kohë, energji dhe kostot.
A jeni përgjegjës për platformën në një kompani që punon me monolite? Në këtë rast, service mesh me siguri nuk ju nevojitet. Nëse po punoni me monolite (ose madje me grupe monolithesh) me modele ndërveprimi të qarta dhe shpesh të pandryshueshme, atëherë service mesh nuk do t'ju ofrojë shumë. Prandaj, mund ta injoroni dhe të shpresoni se do të zhduket si një makth...
Përfundimi
Ndoshta, nuk duhet ta quajmë service mesh "teknologjia më hype e botës" — ky nder i dyshimtë, ndoshta, i përket bitcoin-it ose AI-së. Ndoshta ajo është në pesë të parat. Por nëse kaloni përmes të gjitha zhurmës dhe gjëmës, bëhet e qartë se service mesh sjell përfitime reale për ata që krijojnë aplikacione në Kubernetes.
Do doja që të provonit Linkerd — instalimi i tij në klasterin Kubernetes (apo madje në Minikube në laptopin tuaj) , dhe do të mund ta shihni vetë për çfarë po flas.
FAQ
— Nëse unë do ta injoroj service mesh, a do të zhduket ajo?
— Më vjen keq ta them: service mesh do të mbetet me ne për një kohë të gjatë.
— Por unë NUK DUA të përdor service mesh!
— Mirë, atëherë nuk keni nevojë! Thjesht lexoni anketën time më lart për të kuptuar nëse duhet të njihni të paktën bazat e saj.
— A nuk është kjo një ESB/middleware i vjetër i njohur nën një erë të re?
— Mesh-i i shërbimit merret me logjikën operacionale, jo me atë semantike. e autobusit të shërbimeve të ndërmarrjes (). Ruajtja e këtij ndarjeje ndihmon mesh-in e shërbimit të shmangë fatin e njëjtë.
— Si ndryshon mesh-i i shërbimit nga portat e API-ve?
— Ekzistojnë miliona artikuj në këtë temë. Thjesht kërkoni në Google.
— Është Envoy një mesh shërbimi?
— Jo, Envoy nuk është një mesh shërbimi, është një server proxy. Mund të përdoret për të organizuar mesh-in e shërbimeve (dhe shumë gjëra të tjera — është një proxy për qëllime të përgjithshme). Por vetë ai nuk është një mesh shërbimi.
— A është Network Service Mesh një mesh shërbimi?
— Jo. Pavarësisht emrit, kjo nuk është një mesh shërbimi (si pasojë e marketingut të çuditshëm).
— A do të ndihmojë mesh-i i shërbimeve me sistemin tim reaktiv asinkron të bazuar në radhë mesazhesh?
— Jo, mesh-i i shërbimeve nuk do t'ju ndihmojë.
— Cilin mesh shërbimi duhet të përdor?
— , është e qartë.
— Artikulli është i tmerrshëm! / Autori duhet të tërhiqet!
— Ju lutem, ndani këtë lidhje me të gjithë miqtë e tu, në mënyrë që ata të mund të bindën për këtë!
Faleminderit
Siç mund ta keni kuptuar nga titulli, ky artikull ishte frymëzuar nga traktati fantastik i Jay Kreps «». Takova Jay-n dhjetë vjet më parë, kur intervistoja në LinkedIn, dhe që atëherë ai ka shërbyer si frymëzim për mua.
Ndërsa më pëlqen të quhem «zhvilluesi i Linkerd», realiteti është se unë jam më shumë një mbajtës i skedarit README.md në projekt. Sot për Linkerd punojnë , , njerëz, dhe ky projekt nuk do të kishte arritur pa pjesëmarrjen e mrekullueshme të komunitetit të kontribuesve dhe përdoruesve.
Dhe përfundimisht, një falënderim të veçantë krijuesit të Linkerd, (primus inter pares), i cili së bashku me mua u zhyt thellë në këtë tumult të mesh-it të shërbimeve disa vite më parë.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
