Shënim. përkth.: Rrjeta e shërbimit është një fenomen që nuk ka ende një përkthim të qëndrueshëm në Rusisht (më shumë se 2 vjet më parë ne ofruam opsionin "rrjetë për shërbime", dhe pak më vonë, disa kolegë filluan të promovojnë në mënyrë aktive kombinimin "sitë e shërbimit") . Biseda e vazhdueshme për këtë teknologji ka çuar në një situatë në të cilën komponentët e marketingut dhe teknikë janë shumë të ndërthurur. Ky material i mrekullueshëm nga një prej autorëve të termit origjinal synon të sjellë qartësi tek inxhinierët dhe jo vetëm.
Komik nga
Paraqitje
Nëse jeni një inxhinier softuerësh që punoni diku në fushën e sistemeve të pasme, termi "rrjeta e shërbimit" ndoshta tashmë është ngulitur fort në mendjen tuaj gjatë dy viteve të fundit. Falë një rastësie të çuditshme, kjo frazë po pushton industrinë gjithnjë e më shumë, dhe zhurma dhe ofertat promovuese të lidhura me to po rriten si një top bore, duke fluturuar poshtë kodrës dhe duke mos treguar shenja ngadalësimi.
Rrjeta e shërbimit lindi në ujërat e turbullta, tendencioze të ekosistemit vendas të reve. Fatkeqësisht, kjo do të thotë se shumica e polemikave që e rrethojnë variojnë nga "llafaza me kalori të ulët" në - për të përdorur termin teknik - marrëzi të hapura. Por nëse filtroni të gjithë zhurmën, mund të zbuloni se rrjeta e shërbimit ka një funksion shumë real, të caktuar dhe të rëndësishëm.
Në këtë postim, unë do të përpiqem të bëj pikërisht këtë: të ofroj një udhëzues të ndershëm, të thellë, të orientuar nga inxhinieri për rrjetën e shërbimit. Unë do t'i përgjigjem më shumë sesa pyetjes: "Cfare eshte?", - por gjithashtu "Pse?"Dhe "Pse tani?". Së fundi, do të përpiqem të përshkruaj pse (për mendimin tim) kjo teknologji e veçantë ka shkaktuar një zhurmë kaq të çmendur, e cila në vetvete është një histori interesante.
Kush jam une
Pershendetje te gjitheve! Unë quhem . Unë jam një nga krijuesit - projekti i parë i rrjetës së shërbimit dhe projekti që është fajtor për shfaqjen e termit rrjetë shërbimi si i tillë (më falni djema!). (Shënim përkth.: Nga rruga, në agimin e shfaqjes së këtij termi, më shumë se 2,5 vjet më parë, ne kemi përkthyer tashmë materialin e hershëm të të njëjtit autor të quajtur "".) Unë gjithashtu drejtoj është një startup që ndërton gjëra interesante të rrjetës së shërbimit si Linkerd dhe .
Ju ndoshta mund të merrni me mend se unë kam një mendim shumë të njëanshëm dhe subjektiv për këtë çështje. Sidoqoftë, do të përpiqem të mbaj paragjykimet në minimum (me përjashtim të një seksioni: "Pse flitet kaq shumë për rrjetën e shërbimit?", - në të cilën unë megjithatë do të ndaj idetë e mia të paramenduara). Gjithashtu do të bëj çmos për ta bërë këtë udhëzues sa më objektiv. Në shembuj specifikë, unë do të mbështetem kryesisht në përvojën e Linkerd-it, duke vënë në dukje dallimet (nëse ka) që di në zbatimin e llojeve të tjera të rrjetës së shërbimit.
Mirë, është koha për të kaluar te trajtimet.
Çfarë është një rrjetë shërbimi?
Pavarësisht gjithë zhurmës, rrjeta e shërbimit është strukturor mjaft e thjeshtë. Është vetëm një grup proxies të hapësirës së përdoruesve të vendosura "pranë" shërbimeve (do të flasim pak për "afër" më vonë), plus një grup procesesh kontrolli. Përfaqësuesit thirren kolektivisht plani i të dhënave, dhe quhen proceset e kontrollit aeroplani i kontrollit. Plani i të dhënave përgjon thirrjet ndërmjet shërbimeve dhe bën "çdo gjë të ndryshme" me to; rrafshi i kontrollit, përkatësisht, koordinon sjelljen e proxy-it dhe ju ofron akses, d.m.th. operatori, në API, duke lejuar që rrjeti të manipulohet dhe matet në tërësi.
Çfarë është ky përfaqësues? Ky është një përfaqësues TCP i kategorisë "Layer 7-aware". (d.m.th. "duke marrë parasysh" shtresën e 7-të të modelit OSI) si HAProxy dhe NGINX. Ju mund të zgjidhni një përfaqësues sipas dëshirës tuaj; Linkerd përdor një përfaqësues Rust, të emërtuar në mënyrë të pakomplikuar . Ne e kemi përpiluar atë posaçërisht për rrjetën e shërbimit. Rrjetat e tjera preferojnë përfaqësues të tjerë (Envoy është një zgjedhje e zakonshme). Sidoqoftë, zgjedhja e një përfaqësuesi është vetëm një çështje zbatimi.
Çfarë bëjnë këta proxy server? Natyrisht, ata kryejnë thirrjet proxy drejt dhe nga shërbimet (në mënyrë të rreptë, ata veprojnë si proxy dhe anasjelltas proxy, duke trajtuar si thirrjet hyrëse ashtu edhe ato dalëse). Dhe ata zbatojnë një grup funksionesh që fokusohet në thirrjet между shërbimet. Ky fokus në trafikun ndërmjet shërbimeve është ajo që e dallon një përfaqësues të rrjetës së shërbimit nga, të themi, portat e hyrjes API ose përfaqësuesit e hyrjes (kjo e fundit fokusohet në thirrjet që vijnë në grup nga bota e jashtme). (Shënim. përkth.: Për një krahasim të kontrollorëve ekzistues të Kubernetes Ingress, shumë prej të cilëve përdorin të Dërguarin e përmendur tashmë, shih .)
Pra, ne kuptuam planin e të dhënave. Plani i kontrollit është më i thjeshtë: është një grup përbërësish që ofrojnë të gjithë mekanikën që i nevojitet planit të të dhënave për të punuar në mënyrë të koordinuar, duke përfshirë zbulimin e shërbimit, lëshimin e certifikatës TLS, grumbullimin e metrikës, etj. Plani i të dhënave informon planin e kontrollit për sjellja e tij; nga ana tjetër, rrafshi i kontrollit ofron një API që ju lejon të ndryshoni dhe gjurmoni sjelljen e planit të të dhënave në tërësi.
Më poshtë është një diagram i planit të kontrollit dhe planit të të dhënave në Linkerd. Siç mund ta shihni, plani i kontrollit përfshin disa komponentë të ndryshëm, duke përfshirë një shembull Prometheus që mbledh metrikë nga serverët proxy, si dhe komponentë të tjerë si p.sh. destination (zbulimi i shërbimit), identity (autoriteti i certifikatës, CA) dhe public-api (pikat fundore për ueb dhe CLI). Në të kundërt, plani i të dhënave është një përfaqësues i thjeshtë lidhës pranë shembullit të aplikacionit. Ky është vetëm një diagram logjik; në një vendosje të botës reale, mund të keni tre kopje të secilit komponent të planit të kontrollit dhe qindra ose mijëra përfaqësues në planin e të dhënave.
(Kutitë blu në këtë diagram përfaqësojnë kufijtë e Kubernetes pods. Ju mund të shihni se kontejnerët me linkerd-proxy janë në të njëjtin pod si kontejnerët e aplikacionit. Kjo skemë njihet si enë anësore.)
Arkitektura e rrjetës së shërbimit ka disa implikime të rëndësishme. Së pari, meqenëse detyra e një përfaqësuesi është të përgjojë thirrjet midis shërbimeve, një rrjet shërbimi ka kuptim vetëm nëse aplikacioni juaj është ndërtuar për një grup shërbimesh. rrjetë një mund të përdorni me monolite, por kjo është qartësisht e tepërt për hir të një përfaqësuesi të vetëm, dhe funksionaliteti i tij nuk ka gjasa të jetë në kërkesë.
Një tjetër pasojë e rëndësishme është se rrjeta e shërbimit kërkon i madh numri i përfaqësuesve. Në fakt, Linkerd lidh një proxy-linkerd për çdo shembull të çdo shërbimi (zbatimet e tjera shtojnë një përfaqësues në çdo nyje/host/VM. Kjo është shumë gjithsesi). Një përdorim i tillë aktiv i një përfaqësuesi në vetvete mbart një sërë komplikimesh shtesë:
- Përfaqësuesit në planin e të dhënave duhet të jenë shpejtë, sepse për çdo telefonatë ka disa thirrje drejt përfaqësuesit: një në anën e klientit, një në anën e serverit.
- Gjithashtu, përfaqësuesit duhet të jenë i vogël и peshë e lehtë. Secili do të konsumojë memorie dhe burime CPU, dhe ky konsum do të rritet në mënyrë lineare me aplikacionin.
- Do t'ju duhet një mekanizëm për të vendosur dhe përditësuar një numër të madh proxy. Të bësh atë me dorë nuk është një opsion.
Në përgjithësi, rrjeta e shërbimit duket kështu (të paktën nga pamja e syve të shpendëve): ju vendosni një grup proxies të hapësirës së përdoruesve që "bëjnë diçka" me trafikun e brendshëm, ndër-shërbim dhe përdorni planin e kontrollit për t'i monitoruar dhe menaxhuar ato.
Është koha për pyetjen "Pse?"
Për çfarë shërben rrjeta e shërbimit?
Për ata që kanë hasur për herë të parë idenë e një rrjetë shërbimi, është e falshme të jenë pak të frikësuar. Dizajni i rrjetës së shërbimit do të thotë që jo vetëm që do të rrisë vonesën e aplikimit, por gjithashtu do të rrisë konsumoj burimet dhe do të shtojë një mori mekanizmash të rinj në infrastrukturë. Fillimisht krijoni një rrjetë shërbimi dhe më pas e gjeni papritur veten që keni nevojë të shërbeni qindra (nëse jo mijëra) përfaqësuesish. Pyetja është kush do të dalë vullnetar për këtë?
Përgjigja për këtë pyetje ka dy pjesë. Së pari, kostot e transaksionit që lidhen me vendosjen e këtyre përfaqësuesve mund të reduktohen ndjeshëm për shkak të disa ndryshimeve që ndodhin në ekosistem (më shumë për këtë më vonë).
Së dyti, një pajisje e tillë është në fakt një mënyrë e shkëlqyer për të futur logjikë shtesë në sistem. Dhe jo vetëm sepse mund të shtohen shumë veçori të reja duke përdorur rrjetën e shërbimit, por edhe sepse mund të bëhet pa ndërhyrë në ekosistemin. Në fakt, i gjithë modeli i rrjetës së shërbimit bazohet në këtë postulat: në një sistem multiservice, pa marrë parasysh çfarë bëj shërbimet individuale, trafiku mes tyre është pika ideale për të shtuar funksionalitetin.
Për shembull, në Linkerd (si në shumicën e rrjetave) funksionaliteti fokusohet kryesisht në thirrjet HTTP, duke përfshirë HTTP/2 dhe gRPC*. Funksionaliteti është mjaft i pasur - mund të ndahet në tre klasa:
- Karakteristikat e ngjashme besueshmëria. Kërkesat për riprovim, afatet kohore, afrimi me kanarinë (ndarja/ridrejtimi i trafikut), etj.
- Karakteristikat e ngjashme monitorimi. Përmbledhja e niveleve të suksesit, vonesave dhe vëllimeve të kërkesave për çdo shërbim ose destinacione individuale; ndërtimi i hartave topologjike të shërbimeve etj.
- Karakteristikat e ngjashme sigurinë. TLS reciproke, kontrolli i aksesit, etj.
* Nga këndvështrimi i Linkerd-it, gRPC praktikisht nuk ndryshon nga HTTP/2: ai thjesht përdor protobuf në ngarkesë. Nga këndvështrimi i zhvilluesit, këto dy gjëra, natyrisht, janë të ndryshme.
Shumë prej këtyre mekanizmave funksionojnë në nivelin e kërkesës (prandaj "proxy L7"). Për shembull, nëse shërbimi Foo bën një thirrje HTTP në shiritin e shërbimit, përfaqësuesi lidhës në anën e Foo mund të ngarkojë në mënyrë inteligjente dhe të drejtojë thirrjet nga rastet e Foo në Bar bazuar në vonesën e vëzhguar; mund ta përsërisë kërkesën nëse është e nevojshme (dhe nëse është i pafuqishëm); ai mund të regjistrojë kodin e përgjigjes dhe afatin, e kështu me radhë. Në mënyrë të ngjashme, proxy-likerd në anën e Bar mund të refuzojë një kërkesë nëse nuk lejohet ose nëse tejkalohet kufiri i kërkesës; mund të rregullojë vonesën nga ana e tij, etj.
Proxies mund të "bëjnë diçka" edhe në nivelin e lidhjes. Për shembull, një përfaqësues lidhës në anën Foo mund të inicojë një lidhje TLS dhe një përfaqësues lidhës në anën e shiritit mund ta përfundojë atë dhe të dyja palët mund të verifikojnë certifikatat TLS të njëra-tjetrës*. Kjo siguron jo vetëm kriptim midis shërbimeve, por edhe një mënyrë kriptografike të sigurt për të identifikuar shërbimet: Foo dhe Bar mund të "dëshmojnë" se janë ata që thonë se janë.
* "Mik i një miku" do të thotë që certifikata e klientit është gjithashtu e verifikuar (TLS e ndërsjellë). Në TLS "klasike", për shembull, midis një shfletuesi dhe një serveri, zakonisht verifikohet certifikata e vetëm njërës anë (serveri).
Pavarësisht nëse ato funksionojnë sipas kërkesës ose nivelit të lidhjes, është e rëndësishme të theksohet se të gjitha tiparet e rrjetës së shërbimit janë operacionale karakter. Linkerd nuk është në gjendje të transformojë semantikën e ngarkesës, të tilla si shtimi i fushave në një fragment JSON ose bërja e ndryshimeve në një protobuf. Ne do të flasim për këtë veçori të rëndësishme më vonë kur të flasim për ESB dhe Middleware.
Ky është grupi i veçorive që ofron rrjeta e shërbimit. Shtrohet pyetja: pse të mos i zbatoni ato drejtpërdrejt në aplikacion? Dhe pse të ngatërrohesh fare me një përfaqësues?
Pse një rrjetë shërbimi është një ide e mirë
Ndërsa aftësitë e rrjetës së shërbimit janë magjepsëse, vlera e saj kryesore nuk qëndron në veçoritë. Në fund ne Mund zbatojini ato drejtpërdrejt në aplikacion (më vonë do të shohim se kjo ishte origjina e rrjetës së shërbimit). Për ta thënë me një fjali, vlera e një rrjetë shërbimi është: ai ofron funksionalitet kritik për ekzekutimin e softuerit modern të serverit në një mënyrë konsistente, të gjerë, me kod aplikimi-agnostik.
Le ta analizojmë këtë propozim.
«Funksionet kritike për ekzekutimin e softuerit modern të serverit". Nëse po ndërtoni një aplikacion serveri transaksional të lidhur me internetin publik që pranon kërkesa nga bota e jashtme dhe u përgjigjet atyre në një kohë të shkurtër - për shembull, një aplikacion ueb, një server API dhe shumicën dërrmuese të aplikacioneve të tjera moderne - dhe nëse e zbatoni atë si një grup shërbimesh që ndërveprojnë në mënyrë sinkrone me njëri-tjetrin, dhe nëse jeni duke e përmirësuar vazhdimisht këtë softuer, duke shtuar veçori të reja dhe nëse jeni të detyruar ta mbani këtë sistem në gjendje pune gjatë modifikimit - në këtë rast, urime , po krijoni softuer modern të serverit . Dhe të gjitha ato veçori të shkëlqyera të listuara më sipër, në fakt rezultojnë të jenë kritike për ju. Aplikacioni duhet të jetë i besueshëm, i sigurt dhe ju duhet të jeni në gjendje të shihni se çfarë po bën. Janë këto pyetje që rrjeta e shërbimit ndihmon për të zgjidhur.
(Në rregull, bindja ime se kjo qasje është mënyra moderne për të ndërtuar softuer serverësh ka hyrë në paragrafin e mëparshëm. 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 ndoshta kanë mendim që ndryshon nga i imi, dhe nga ana tjetër, unë besoj se janë "të gabuar" - megjithëse në çdo rast, rrjeta e shërbimit nuk është shumë e dobishme për ta).
«Uniformë për të gjithë pirgun". Karakteristikat e ofruara nga rrjeta e shërbimit nuk janë vetëm kritike. Ato aplikohen për të gjitha shërbimet në aplikacion, pavarësisht se në cilën gjuhë janë shkruar, çfarë kornize përdorin, kush i ka shkruar, si janë vendosur dhe të gjitha hollësitë e tjera të zhvillimit dhe përdorimit të tyre.
«Kodi i aplikacionit është i pavarur". Së fundi, rrjeta e shërbimit jo vetëm që ofron funksionalitet të qëndrueshëm në të gjithë grumbullin, por e bën këtë në një mënyrë që nuk kërkon redaktim të aplikacionit. Baza themelore e funksionalitetit të rrjetës së shërbimit, duke përfshirë detyrat e konfigurimit, përditësimit, funksionimit, mirëmbajtjes, etj., është thjesht në nivelin e platformës dhe është i pavarur nga aplikacioni. Aplikacioni mund të ndryshojë pa ndikuar në rrjetën e shërbimit. Nga ana tjetër, rrjeta e shërbimit mund të ndryshojë pa asnjë ndërhyrje aplikimi.
Me pak fjalë, rrjeta e shërbimit jo vetëm që ofron funksionalitet jetik, por e bën këtë në një mënyrë globale, uniforme dhe të pavarur nga aplikacioni. Dhe kështu, ndërsa funksionaliteti i një rrjeti shërbimi mund të zbatohet në kodin e shërbimit (për shembull, si një bibliotekë e përfshirë me çdo shërbim), kjo qasje nuk do të sigurojë uniformitetin dhe pavarësinë që është kaq e vlefshme në rastin e një rrjetë shërbimi. .
Dhe gjithçka që duhet të bëni është të shtoni një mori proxies! Unë premtoj se shumë shpejt do të shikojmë kostot operative që lidhen me shtimin e këtyre proxy-ve. Por së pari, le të ndalemi dhe të shohim këtë ide të pavarësisë nga këndvështrimi i të ndryshmeve njerëz.
Kë ndihmon rrjeta e shërbimit?
Sado e papërshtatshme të jetë, në mënyrë që një teknologji të bëhet pjesë e rëndësishme e ekosistemit, ajo duhet të pranohet nga njerëzit. Pra, kush është i interesuar për një rrjetë shërbimi? Kush përfiton nga përdorimi i tij?
Nëse zhvilloni softuer modern të serverëve, mund ta imagjinoni afërsisht ekipin tuaj si një grup pronarët e shërbimevetë cilët së bashku zhvillojnë dhe zbatojnë logjikën e biznesit, dhe pronarët e platformëspërfshirë në zhvillimin e platformës së brendshme në të cilën funksionojnë këto shërbime. Në organizata të vogla, këta mund të jenë të njëjtët njerëz, por ndërsa kompania rritet, këto role priren të bëhen më të theksuara dhe madje të ndahen në nën-role ... (Këtu mund të thuhet shumë për ndryshimin e natyrës së devops, ndikimi organizativ i mikroshërbimeve etj.) n. Por tani për tani, le t'i marrim si të mirëqenë këto përshkrime).
Nga ky këndvështrim, përfituesit e qartë të rrjetës së shërbimit janë pronarët e platformës. Në fund të fundit, qëllimi përfundimtar i ekipit të platformës është të krijojë një platformë të brendshme në të cilën pronarët e shërbimeve mund të zbatojnë logjikën e biznesit dhe ta bëjnë atë në një mënyrë që garanton pavarësinë e tyre maksimale nga detajet e zymta të funksionimit të saj. Rrjeta e shërbimit jo vetëm që ofron aftësitë kritike për arritjen e këtij qëllimi, por e bën këtë në një mënyrë që, nga ana tjetër, nuk imponon asnjë varësi nga pronarët e shërbimeve.
Përfitojnë edhe pronarët e shërbimeve, ndonëse në mënyrë më indirekte. 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ë shqetësohet për çështjet operacionale, aq më mirë. Në vend që të zbatojnë, të themi, politikat e riprovimit ose TLS, ata mund të fokusohen vetëm te biznesi dhe shpresojnë që platforma të kujdeset për pjesën tjetër. Për ta, ky është një avantazh i madh.
Vlera organizative e një ndarjeje të tillë midis pronarëve të platformave dhe shërbimeve nuk mund të mbivlerësohet. Unë mendoj se ajo kontribuon kryesore kontribut në vlerën e rrjetës së shërbimit.
Ne e mësuam këtë mësim kur një tifoz i hershëm i Linkerd na tha pse ata zgjodhën rrjetën e shërbimit: sepse kjo i lejoi ata të "vazhdonin të flisnin në minimum". Këtu janë disa detaje: djemtë nga një kompani e madhe migruan platformën e tyre në Kubernetes. Meqenëse aplikacioni punonte me informacione të ndjeshme, ata donin të kodonin të gjitha komunikimet në grupe. Megjithatë, situata u ndërlikua nga prania e qindra shërbimeve dhe qindra ekipeve të zhvillimit. Perspektiva për të kontaktuar të gjithë dhe për t'i bindur ata që të përfshijnë mbështetjen për TLS në planet e tyre nuk i pëlqeu aspak. Duke instaluar Linkerd, ata migruan përgjegjësi nga zhvilluesit (nga këndvështrimi i të cilëve ishte telashe e panevojshme) deri te platformuesit, për të cilët kjo ishte një përparësi e nivelit të lartë. Me fjalë të tjera, Linkerd nuk po zgjidhte për ta një problem teknik, sa një problem organizativ.
Me pak fjalë, rrjeta e shërbimit nuk është, përkundrazi, një zgjidhje teknike, por socio-teknike Problemet. (Faleminderit për futjen e këtij termi.
A do t'i zgjidhë rrjeta e shërbimit të gjitha problemet e mia?
Po. Dua të them, jo!
Duke parë tre klasat e veçorive të përshkruara më sipër - besueshmëria, siguria dhe vëzhgueshmëria - bëhet e qartë se rrjeta e shërbimit nuk është një zgjidhje e plotë për asnjë nga këto probleme. Megjithëse Linkerd mund të dërgojë kërkesa të përsëritura (nëse e di se ato janë të pafuqishme), nuk është në gjendje të marrë vendime se çfarë t'i kthejë përdoruesit nëse shërbimi përfundimisht ka rënë - vendime të tilla duhet të merren nga aplikacioni. Linkerd mund të mbajë statistika për kërkesat e suksesshme, por nuk është në gjendje të shikojë shërbimin dhe të sigurojë matjet e tij të brendshme - një aplikacion duhet të ketë një paketë të tillë mjetesh. Dhe ndërsa Linkerd është i aftë të presë mTLS, zgjidhjet e plota të sigurisë kërkojnë shumë më tepër.
Një nëngrup i veçorive në këto zona të ofruara nga rrjeta e shërbimit janë të lidhura me veçoritë e platformës. Me këtë nënkuptoj funksionet që:
- I pavarur nga logjika e biznesit. Mënyra në të cilën janë ndërtuar histogramet e thirrjeve midis Foo dhe Bar është plotësisht e pavarur nga fakti nëse pse Foo e quan Bar.
- Vështirë për t'u zbatuar në mënyrë korrekte. Në Linkerd, riprovimet parametrizohen me të gjitha llojet e gjërave të bukura si buxhetet e riprovës. (provo sërish buxhetet), meqenëse një qasje e thjeshtë ndaj zbatimit të gjërave të tilla me siguri do të çojë në shfaqjen e të ashtuquajturit "orteku i kërkesave" (provo sërish stuhi) dhe probleme të tjera specifike për sistemet e shpërndara.
- Më efektive kur aplikohet vazhdimisht. Mekanizmi TLS ka kuptim vetëm nëse zbatohet kudo.
Për shkak se këto veçori zbatohen në shtresën proxy (dhe jo në shtresën e aplikacionit), rrjeta e shërbimit i ekspozon ato në platformë, jo aplikacionet. Kështu, nuk ka rëndësi se në cilën gjuhë janë shkruar shërbimet, çfarë kornize përdorin, kush i ka shkruar dhe pse. Proxies funksionojnë përtej të gjitha këtyre detajeve dhe baza themelore e këtij funksioni, duke përfshirë detyrat e konfigurimit, përditësimit, funksionimit, mirëmbajtjes, etj., qëndron vetëm në nivelin e platformës.
Shembuj të aftësive të rrjetës së shërbimit
Si përmbledhje, një rrjetë shërbimi nuk është një zgjidhje e plotë për besueshmërinë, vëzhgimin ose sigurinë. Shtrirja e këtyre fushave nënkupton pjesëmarrjen e detyrueshme të pronarëve të shërbimeve, ekipeve të Ops/SRE dhe aktorëve të tjerë të kompanisë. Rrjeta e shërbimit ofron vetëm një "fetë" në nivelin e platformës për secilën nga këto zona.
Pse rrjeta e shërbimit është bërë e njohur pikërisht tani?
Ju ndoshta po pyesni veten tani: OK, nëse rrjeta e shërbimit është kaq e mirë, pse nuk filluam vendosjen e miliona përfaqësuesve në rafte dhjetë vjet më parë?
Ka një përgjigje banale për këtë pyetje: dhjetë vjet më parë të gjithë ndërtuan monolite dhe askush nuk kishte nevojë për një rrjetë shërbimi. Kjo është e vërtetë, por për mendimin tim, kjo përgjigje nuk ka kuptim. Edhe dhjetë vjet më parë, koncepti i mikroshërbimeve si një mënyrë premtuese për të krijuar sisteme në shkallë të gjerë u diskutua dhe u aplikua gjerësisht në kompani si Twitter, Facebook, Google dhe Netflix. Perceptimi i përgjithshëm - të paktën në pjesët e industrisë me të cilat kam qenë në kontakt - ishte se mikroshërbimet janë "mënyra e duhur" për të ndërtuar sisteme të mëdha, edhe nëse ishte shumë e vështirë.
Natyrisht, megjithëse kishte kompani që shfrytëzonin mikroshërbime dhjetë vjet më parë, ato nuk ngjitën proxy kudo që të mundnin për të formuar një rrjetë shërbimi. Megjithatë, nëse shikoni nga afër, ata bënë diçka të ngjashme: shumë prej këtyre kompanive detyruan përdorimin e një biblioteke të brendshme speciale për rrjetëzim (nganjëherë e quajtur biblioteka e klientëve të trashë, biblioteka e klientëve të trashë).
Netflix kishte Hysterix, Google kishte Stubby, Twitter kishte bibliotekën Finagle. Finagle, për shembull, ka qenë i detyrueshëm për çdo shërbim të ri në Twitter. Ai trajtonte lidhjet si nga ana e klientit ashtu edhe nga serveri, lejoi kërkesa të përsëritura, mbështeti drejtimin e kërkesave, balancimin e ngarkesës dhe matjen. Ai siguroi një shtresë të qëndrueshme besueshmërie dhe vëzhgimi në të gjithë grupin e Twitter, pavarësisht se çfarë po bënte shërbimi. Sigurisht, ai funksiononte vetëm për gjuhët JVM dhe bazohej në një model programimi që duhej të përdorej për të gjithë aplikacionin. Sidoqoftë, funksionaliteti i tij ishte pothuajse i njëjtë me atë të rrjetës së shërbimit. (Në fakt, versioni i parë i Linkerd ishte vetëm Finagle i mbështjellë në formë proxy.)
Kështu, dhjetë vjet më parë nuk kishte vetëm mikroshërbime, por edhe biblioteka të veçanta me rrjetë proto-shërbimi që zgjidhin të njëjtat probleme që zgjidh sot rrjeta e shërbimit. Sidoqoftë, rrjeta e shërbimit nuk ekzistonte atëherë. Duhej të kishte një ndryshim tjetër përpara se ajo të shfaqej.
Dhe këtu qëndron përgjigja më e thellë, e fshehur në një ndryshim tjetër që ka ndodhur gjatë 10 viteve të fundit: ka pasur një rënie të mprehtë në koston e vendosjes së mikroshërbimeve. Kompanitë e përmendura më lart që përdornin mikroshërbime një dekadë më parë—Twitter, Netflix, Facebook, Google—ishin kompani të shkallës së madhe dhe burimeve të mëdha. Ata jo vetëm që kishin nevojën, por edhe aftësinë për të ndërtuar, vendosur dhe operuar aplikacione të mëdha të bazuara në mikroshërbime. Energjia dhe përpjekja që inxhinierët e Twitter kanë bërë për të kaluar nga një qasje monolitike në atë të mikroshërbimeve janë të mahnitshme. (Sinqerisht, siç ishte fakti që funksionoi.) Ky lloj manovrimi në infrastrukturë ishte atëherë i pamundur për kompanitë më të vogla.
Le të kalojmë në të tashmen. Sot ka startup ku raporti i mikroshërbimeve ndaj zhvilluesve është 5:1 (ose madje ), dhe për më tepër, ata i përballojnë me sukses! Nëse një startup prej 5 personash është në gjendje të operojë 50 mikroshërbime pa u sforcuar, atëherë diçka e uli qartë koston e zbatimit të tyre.
1500 mikroshërbime në Monzo; çdo linjë është një rregull i përcaktuar i rrjetit që lejon trafikun
Ulja dramatike e kostos së funksionimit të mikroshërbimeve është rezultat i një procesi të vetëm: Popullariteti në rritje i kontejnerëve и orkestruesit. Kjo është pikërisht përgjigja e thellë për pyetjen se çfarë kontribuoi në shfaqjen e rrjetës së shërbimit. E njëjta teknologji i bëri tërheqëse rrjetin e shërbimit dhe mikroshërbimet: Kubernetes dhe Docker.
Pse? Epo, Docker zgjidh një problem të madh - problemin e paketimit. Duke paketuar një aplikacion dhe varësitë e tij (jo-rrjetore) të kohës së funksionimit në një kontejner, Docker e kthen aplikacionin në një njësi të këmbyeshme që mund të mbahet dhe të ekzekutohet kudo. Në të njëjtën kohë, ajo thjeshton shumë funksionimin. shumëgjuhëshe stack: Meqenëse një kontejner është një njësi atomike e ekzekutimit, nuk ka rëndësi se çfarë është brenda për qëllime vendosjeje dhe operacionale, nëse është një aplikacion JVM, Node, Go, Python ose Ruby. Ju thjesht e drejtoni atë dhe kaq.
Kubernetes çon gjithçka në nivelin tjetër. Tani që ka një mori "gjërash të ekzekutueshme" dhe shumë makina për t'i përdorur ato, ka nevojë për një mjet që mund t'i përshtatë ato me njëra-tjetrën. Në një kuptim të gjerë, ju i jepni Kubernetes shumë kontejnerë dhe shumë makineri, dhe i përputh ato me njëra-tjetrën (natyrisht, ky është një proces dinamik dhe vazhdimisht në ndryshim: kontejnerët e rinj lëvizin nëpër sistem, makinat nisin dhe ndalojnë, etj. Megjithatë, Kubernetes i merr parasysh të gjitha këto).
Pasi të konfigurohet Kubernetes, koha që duhet për vendosjen dhe funksionimin e një shërbimi nuk është shumë e ndryshme nga kostoja e vendosjes dhe funksionimit të dhjetë shërbimeve (në fakt, është pothuajse e njëjtë për 100 shërbime). Shtojini kësaj kontejnerë si një mekanizëm paketimi që inkurajon zbatimin shumëgjuhësh, dhe do të keni një sërë aplikacionesh të reja të zbatuara si mikroshërbime të shkruara në shumë gjuhë, pikërisht atë lloj mjedisi për të cilin rrjeta e shërbimit është aq e përshtatshme.
Pra, kemi ardhur te përgjigjja e pyetjes se pse ideja e një rrjetë shërbimi është bërë e njohur tani: uniformiteti që Kubernetes ofron për shërbimet është drejtpërdrejt i zbatueshëm për detyrat operacionale me të cilat përballet rrjeta e shërbimit. Ju paketoni proxies në kontejnerë, i jepni Kubernetes detyrën për t'i ngjitur ato kudo që të jetë e mundur, dhe voila! Në dalje, ju merrni një rrjetë shërbimi, ndërsa Kubernetes kontrollon të gjithë mekanikën e vendosjes së saj. (Të paktën nga këndvështrimi i një zogu. Sigurisht, ka shumë nuanca në këtë proces.)
Për ta përmbledhur: arsyeja pse rrjeta e shërbimit u bë e njohur tani dhe jo dhjetë vjet më parë është se Kubernetes dhe Docker jo vetëm që u rritën ndjeshëm nevojë në të, duke thjeshtuar zbatimin e aplikacioneve si grupe mikroshërbimesh shumëgjuhëshe, por edhe reduktuar ndjeshëm shpenzimet për funksionimin e tij duke ofruar mekanizma për vendosjen dhe mirëmbajtjen e parqeve proxy car.
Pse flitet kaq shumë për rrjetën e shërbimit?
Kujdes: Në këtë seksion, unë përdor të gjitha llojet e supozimeve, hamendjeve, trillimeve dhe informacioneve të brendshme.
Kërkimi për "rrjetën e shërbimit" do të shfaqë një mori përmbajtjesh të ricikluara, me kalori të ulët, projekte të çuditshme dhe një kaleidoskop shtrembërimi të denjë për një dhomë jehone. Çdo teknologji e re e modës e ka këtë, por në rastin e rrjetës së shërbimit, problemi është veçanërisht i mprehtë. Pse?
Epo, është pjesërisht faji im. Kam bërë çmos për të promovuar Linkerd dhe rrjetin e shërbimit në çdo rast, përmes postimeve të panumërta në blog dhe artikujve si ky. Por unë nuk jam aq i fuqishëm. Për t'iu përgjigjur vërtet kësaj pyetjeje, duhet të flasim pak për situatën e përgjithshme. Dhe është e pamundur të flasim për të pa përmendur një projekt: është një rrjetë shërbimi me burim të hapur i zhvilluar bashkërisht nga Google, IBM dhe Lyft.
(Këto tre kompani kanë role shumë të ndryshme: përfshirja e Lyft duket se kufizohet vetëm me emrin; ata autorë Envoy por nuk përdorin ose janë të përfshirë në zhvillimin e Istio. IBM është e përfshirë në zhvillimin e Istio dhe e përdor atë. Google është shumë i përfshirë në zhvillimin e Istio, por me sa mund të them, nuk e përdor në të vërtetë.)
Projekti Istio shquhet për dy gjëra. Së pari, është përpjekja e madhe e marketingut që Google, në veçanti, bën në promovimin e saj. Vlerësoj se shumica e njerëzve aktualisht të vetëdijshëm për konceptin e rrjetës së shërbimit mësuan fillimisht për të falë Istio. Karakteristika e dytë është se sa keq u prit Istio. Në këtë çështje, unë, padyshim, jam një palë e interesuar, por duke u përpjekur të mbetem sa më objektive, nuk mund të mos , jo shumë specifike (edhe pse jo unike: systemd vjen në mendje, ...) për një projekt me burim të hapur.
(Në praktikë, Istio duket se ka probleme jo vetëm me kompleksitetin dhe UX, por edhe me performancën. Për shembull, gjatë të kryera nga një palë e tretë, ekspertët gjetën situata në të cilat vonesa e bishtit të Istio ishte 100 herë më e lartë se ajo e Linkerd, si dhe situata me mungesë burimesh, kur Linkerd vazhdoi të funksiononte me sukses dhe Istio pushoi plotësisht së funksionuari.)
Duke lënë mënjanë teoritë e mia se pse ndodhi kjo, unë besoj se zhurma jashtë shkallës rreth rrjetës së shërbimit është për shkak të përfshirjes së Google. Përkatësisht, një kombinim i tre faktorëve të mëposhtëm:
- promovimi obsesiv i Istio nga Google;
- qëndrimi i duhur mosmiratues, kritik ndaj projektit;
- popullariteti në rritje i fundit i Kubernetes, kujtimi i të cilit është ende i freskët.
Së bashku, këta faktorë bashkohen në një lloj mjedisi dehës, anoksik, në të cilin aftësia për gjykim racional zvogëlohet, duke lënë vetëm një shumëllojshmëri të çuditshme .
Nga këndvështrimi i Linkerdit, kjo është… Unë do ta përshkruaja atë si një bekim të përzier. Dua të them, është e mrekullueshme që rrjeta e shërbimit ka hyrë në rrjedhën kryesore - gjë që nuk ndodhi në vitin 2016 kur u shfaq për herë të parë Linkerd dhe ishte vërtet e vështirë për të tërhequr vëmendjen e njerëzve mbi projektin. Tani nuk ka një problem të tillë! Por lajmi i keq është se situata e rrjetës së shërbimit është kaq konfuze sot sa është pothuajse e pamundur të kuptosh se cilat projekte i përkasin me të vërtetë kategorisë së rrjetës së shërbimit (le më të kuptosh se cili është më i miri për një rast të veçantë përdorimi). Kjo sigurisht i pengon të gjithëve (dhe definitivisht në disa raste Istio ose një projekt tjetër është më i mirë se Linkerd, pasi ky i fundit nuk është një zgjidhje e vetme për të gjithë).
Nga ana e Linkerd-it, strategjia jonë ka qenë të injorojmë zhurmën, të vazhdojmë të fokusohemi në zgjidhjen e problemeve reale në komunitet dhe në thelb të presim që zhurma të shuhet. Përfundimisht zhurma do të ulet dhe ne mund të vazhdojmë të punojmë në paqe.
Deri atëherë, të gjithë do të duhet të jemi të durueshëm.
A do të jetë e dobishme rrjeta e shërbimit për mua, një inxhinier modest softuerësh?
Pyetësori i mëposhtëm do të ndihmojë në përgjigjen e kësaj pyetjeje:
Merreni ekskluzivisht me zbatimin e logjikës së biznesit? Në këtë rast, rrjeta e shërbimit nuk do të jetë e dobishme për ju. Kjo është, natyrisht, ju mund të jeni të interesuar për të, por në mënyrë ideale, rrjeta e shërbimit nuk duhet të ndikojë drejtpërdrejt në asgjë në mjedisin tuaj. Vazhdoni të punoni për atë për të cilën paguheni.
A mbani një platformë në një kompani që përdor Kubernetes? Po, në këtë rast ju duhet një rrjetë shërbimi (natyrisht, nëse nuk po përdorni K8 vetëm për të ekzekutuar një përpunim monolit ose grumbull - por atëherë do të doja të pyesja pse keni nevojë për K8). Me shumë mundësi, do të gjendeni në një situatë me shumë mikroshërbime të shkruara nga njerëz të ndryshëm. Ata të gjithë ndërveprojnë me njëri-tjetrin dhe janë të lidhur në një lëmsh varësish nga koha e funksionimit, dhe ju duhet të gjeni një mënyrë për t'u marrë me gjithë këtë. Përdorimi i Kubernetes ju lejon të zgjidhni një rrjetë shërbimi "për veten tuaj". Për ta bërë këtë, njihuni me aftësitë dhe veçoritë e tyre dhe përgjigjuni pyetjes nëse ndonjë nga projektet e disponueshme ju përshtatet fare (unë rekomandoj të filloni kërkimin tuaj me Linkerd).
A po drejtoni një platformë për një kompani që NUK përdor Kubernetes por përdor mikroshërbime? Në këtë rast, rrjeta e shërbimit do të jetë e dobishme për ju, por përdorimi i saj do të jetë jo i parëndësishëm. Natyrisht ju mund të imitoj rrjetë shërbimi duke pritur një grup proxies, por një avantazh i rëndësishëm i Kubernetes është pikërisht modeli i vendosjes: mirëmbajtja manuale e këtyre proxy-ve do të kërkojë shumë më tepër kohë, përpjekje dhe kosto.
Jeni në krye të platformës në një kompani që punon me monolite? Në këtë rast, ndoshta nuk keni nevojë për një rrjetë shërbimi. Nëse jeni duke punuar me monolite (ose edhe grupe monolitesh) që kanë modele ndërveprimi të përcaktuara mirë dhe rrallëherë në ndryshim, atëherë rrjeta e shërbimit ka pak për t'ju ofruar. Kështu që ju thjesht mund ta injoroni atë dhe të shpresoni se do të zhduket si një ëndërr e keqe...
Përfundim
Ndoshta, rrjeta e shërbimit ende nuk duhet të quhet "teknologjia më e reklamuar në botë" - ky nder i dyshimtë ndoshta i përket bitcoin ose AI. Ndoshta ajo është në pesëshen e parë. Por nëse kaloni shtresat e zhurmës dhe zhurmës, bëhet e qartë se rrjeta e shërbimit sjell përfitime reale për ata që krijojnë aplikacione në Kubernetes.
Unë do të doja që ju të provoni Linkerd - duke e instaluar atë në një grup Kubernetes (ose edhe Minikube në një laptop) dhe ju mund ta shihni vetë se për çfarë po flas.
FAQ
- Nëse e shpërfill rrjetën e shërbimit, a do të zhduket?
- Më duhet t'ju zhgënjej: rrjeta e shërbimit është me ne për një kohë të gjatë.
— Por unë NUK DUA të përdor një rrjetë shërbimi!
- Epo, nuk është e nevojshme! Thjesht lexoni pyetësorin tim më sipër për të parë nëse duhet të paktën të njiheni me bazat e tij.
— A nuk është ESB/middleware i vjetër i mirë me një salcë të re?
- Rrjeta e shërbimit merret me logjikën operacionale, jo semantike. autobus i shërbimit të ndërmarrjes (). Mbajtja e kësaj ndarjeje ndihmon rrjetën e shërbimit të shmangë të njëjtin fat.
- Si ndryshon rrjeta e shërbimit nga portat API?
Ka një milion artikuj mbi këtë temë. Thjesht google.
A është Envoy një rrjetë shërbimi?
- Jo, Envoy nuk është një rrjetë shërbimi, është një server proxy. Mund të përdoret për të organizuar një rrjetë shërbimi (dhe shumë më tepër - është një përfaqësues për qëllime të përgjithshme). Por në vetvete, nuk është një rrjetë shërbimi.
- Network Service Mesh - a është rrjetë shërbimi?
- Jo. Pavarësisht emrit, kjo nuk është një rrjetë shërbimi (si ju pëlqejnë mrekullitë e marketingut?).
- A do të ndihmojë rrjeta e shërbimit me sistemin tim reaktiv asinkron bazuar në radhën e mesazheve?
- Jo, rrjeta e shërbimit nuk do t'ju ndihmojë.
- Cilën rrjetë shërbimi duhet të përdor?
- , pa tru.
- Artikulli është i frikshëm! / Autori - në sapun!
— Ju lutemi shpërndajeni lidhjen me të gjithë miqtë tuaj në mënyrë që ata të binden për këtë!
Mirënjohje
Siç mund ta merrni me mend nga titulli, ky artikull u frymëzua nga traktati fantastik i Jay Kreps "". Jam takuar me Jay-n dhjetë vjet më parë ndërsa po bëja një intervistë në Linked In dhe ai ka qenë një frymëzim për mua që atëherë.
Ndërsa më pëlqen ta quaj veten një "zhvillues Linkerd", realiteti është se unë jam më shumë një mbajtës i skedarit README.md në një projekt. Duke punuar në Linkerd sot , , njerëz, dhe ky projekt nuk do të ishte i mundur pa komunitetin e mahnitshëm të kontribuesve dhe përdoruesve.
Dhe së fundi, falënderim i veçantë për krijuesin e Linkerd, (primus inter pares), i cili bashkë me mua shumë vite më parë u zhyt me kokë në gjithë këtë bujë me rrjetën e shërbimit.
PS nga përkthyesi
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «"?
- «"?
- «'.
Burimi: www.habr.com