Shën. përkth.: Mesh-i shërbimeve është një fenomen që ende nuk ka një përkthim të qartë në gjuhën shqipe (më shumë se 2 vjet më parë, ne propozuam variantin "rrjet për shërbime", ndërsa më vonë disa kolegë filluan të promovonin intensively kombinimin "sito shërbimi"). Bisedat e vazhdueshme rreth kësaj teknologjie qon në një situatë ku elementët marketing dhe teknik janë ngushtësisht të lidhur. Ky material i mrekullueshëm nga një nga autorët e termit origjinal është krijuar për të ofruar qartësi për inxhinierët dhe jo vetëm.
Komiksi nga
Hyrje
Nëse jeni inxhinier software që punoni ndonjëherë në sistemet e backend, termini "mesh shërbimesh" ndoshta tashmë është fiksuar në mendjen tuaj gjatë dy viteve të fundit. Falë një satirike të çuditshme, kjo frazë po kap sektorin gjithnjë e më fort, ndërsa marketingu dhe ofertat e lidhura po rriten si një top bore që zbret poshtë një kodre pa treguar asnjë shenjë ngadalësimi.
Mesh-i shërbimeve ka lindur në ujërat e turbullta dhe tendencioze të ekosistemit cloud native. Fatkeqësisht, kjo do të thotë se një pjesë e rëndësishme e polemikës përkatëse varion nga "biseda e dobët" deri në — për të përdorur një term teknik — tërheqje e qartë. Por nëse e përjashtojmë gjithçka, mund të zbulojmë që mesh-i shërbimeve ka një funksion të vërtetë, të qartë dhe të rëndësishëm.
Në këtë publikim, do të përpiqem të bëj pikërisht këtë: të ofroj një udhëzues të ndershëm, të thellë dhe të orientuar për inxhinierët për mesh-in shërbimeve. Do të përpiqem të përgjigjem jo vetëm në pyetjen: «Çfarë është?», — por edhe «Pse?», si dhe «Pse pikërisht tani?». Përfundimisht, do të përpiqem të ilustroj arsyen se pse (sipër mendimit tim) kjo teknologji provoi hype të çmendur, që vetë është një histori interesante.
Kush jam unë?
Përshëndetje të gjithëve! Më quajnë . Jam një nga krijuesit e — projekti i parë i mesh-it të shërbimeve dhe projekti që është përgjegjës për shfaqjen e termit service mesh si i tillë (më falni, djem!). (Përkthe për: Për të thënë një fjalë, në fillim të shfaqjes së këtij termini, më shumë se 2.5 vjet më parë, ne tashmë kishim përkthyer një material të hershëm nga autori i njëjtë me titullin "».) Pjesa tjetër unë drejtoj — një startup që merret me krijimin e gjërave të tilla të mrekullueshme si Linkerd dhe .
Mund të imagjinoni se kam një opinion të formuar dhe subjektiv mbi këtë çështje. Megjithatë, do të përpiqem ta mbaj tendencën në minimum (përveç një seksioni: «Pse ka kaq shumë biseda për service mesh?», — në të cilin do të ndaj disa ide të mia të parapara). Po ashtu, do të bëj maksimumin për ta bërë këtë udhëzues sa më objektiv. Në shembujt konkretë do të mbështetem kryesisht në përvojën e Linkerd, duke treguar gjithashtu dallimet e njohura (nëse ka) në zbatimin e llojeve të tjera të service mesh.
Ok, është koha për të kaluar te gjërat interesante.
Çfarë është service mesh?
Pavarësisht gjithë bujës, struktura e service mesh është mjaft e thjeshtë. Ajo është thjesht një grumbull proxy-esh në userspace, të vendosura "afër" shërbimeve (më vonë do të flasim pak për atë çfarë do të thotë "afër"), plus një grup procesesh menaxhuese. Proxy-të së bashku kanë marrë emrin data plane, ndërsa proceset menaxhuese quhen control plane. Data plane kap thirrjet midis shërbimeve dhe bën "çdo gjë" me to; control plane, përkatësisht, koordinon sjelljen e proxy-ve dhe siguron qasje për ju, dmth. operatorin, në API, duke lejuar manipulimin e rrjetit dhe matjen e tij si një e tërë.
Çfarë janë këto proxy? Ato janë TCP proxy të kategorisë "Layer 7-aware" (dmth. "të njohura" nivelin 7 të modelit OSI) si HAProxy dhe NGINX. Mund të zgjidhni një proxy sipas preferencës tuaj; Linkerd përdor një proxy të shkruar në Rust, e quajtur . Ne e kemi ndërtuar atë posaçërisht për service mesh. Mesh të tjera preferojnë proxy të ndryshëm (Envoy është një zgjedhje e zakonshme). Megjithatë, zgjedhja e proxy është thjesht një çështje e zbatimit.
Cfarë bëjnë këto servera proxy? Është e qartë që ato proxyzojnë thirrjet në shërbime dhe nga ato (më saktë, ato shërbejnë si proxy dhe reverse proxy, duke përpunuar si thirrjet hyrëse, ashtu edhe ato dalëse). Dhe ato realizojnë një set funksionesh, të përqendruar në thirrjet midis shërbimeve. Ky fokus në trafik midis shërbimeve e dallon proxy-në e service mesh nga, le të themi, portat API ose proxy-të e hyrjes (këta të fundit përqendrohen në thirrjet që hyjnë në klaster nga bota e jashtme). (Shën. përkth.: krahasimi i kontrollorëve ekzistues të Ingress për Kubernetes, shumë prej të cilëve përdorin Envoy të përmendur më parë, shih në .)
Pra ndaj, me data plane jemi në rregull. Control plane është më e thjeshtë: është një grup komponentësh që sigurojnë gjithë mekanikën e nevojshme që data plane të funksionojë në mënyrë të koordinuar, duke përfshirë zbdiscoverimin e shërbimeve, lëshimin e çertifikatave TLS, agregimin e metrikeve etj. Data plane informon control plane për sjelljen e saj; nga ana e saj, control plane ofron një API që lejon ndryshimin dhe ndjekjen e sjelljes së data plane si një tërësi.
Më poshtë është një skemë e control plane dhe data plane në Linkerd. Siç shihet, control plane përfshin disa komponente të ndryshme, duke përfshirë një instancë Prometheus, e cila mbledh metrikat nga serverët proxy, si dhe komponente të tjera, të tilla si destination (zbdiscoverimi i shërbimeve), identity (qendra e çertifikimit, CA) dhe public-api (endpoint për web dhe CLI). Ndryshe, data plane përbëhet nga një linkerd-proxy afër një instancë aplikacioni. Kjo është vetëm një skemë logjike; në kushte reale të vendosjes, mund të keni tre replika të çdo komponente të control plane dhe qindra ose mijëra proxy në data plane.
(Katërkëndëshat e bluar në këtë skemë simbolizojnë kufijtë e pod-ve Kubernetes. Siç duket, kontejnerët me linkerd-proxy ndodhen në të njëjtin pod me kontejnerët e aplikacionit. Kjo skemë quhet sidecar-kontejner.)
Arkitektura e mesh-it të shërbimeve ka disa pasoja të rëndësishme. Së pari, pasi detyra e proxy-it është të kapë thirrjet midis shërbimeve, mesh-i i shërbimeve ka kuptim vetëm nëse aplikacioni juaj është krijuar mbi një grup shërbimesh. Mesh mund të mund të përdoret me monolite, por kjo është qartë e tepërt për një vetëm proxy, dhe funksionaliteti i saj me siguri nuk do të kërkohet.
Një pasojë tjetër e rëndësishme është se mesh-i i shërbimeve kërkon një numër të madh proxy-esh. Në të vërtetë, Linkerd lidh linkerd-proxy me çdo instancë të çdo shërbimi (implementime të tjera shtojnë proxy në çdo nyje/host/makina virtuale. Në çdo rast, kjo është mjaft.) Përdorimi kaq aktiv i proxy-ve vetvetiu sjell disa komplikime shtesë:
- Proxy-t në data plane duhet të jenë të shpejtë, pasi për çdo thirrje ka dy thirrje për proxy: një nga ana e klientit, një nga ana e serverit.
- Gjithashtu, proxy-t duhet të jenë të vogla dhe të lehta. Çdo një do të konsumojë burime memorjeje dhe CPU, dhe ky konsum do të rritet në mënyrë lineare me aplikacionin.
- Ju nevojitet një mekanizëm për të implementuar dhe përditësuar një numër të madh proxysh. Të bëni këtë manualisht nuk është një opsion.
Në përgjithësi, një service mesh duket kështu (të paktën, nga një lartësi fluturuese): ju implementoni një sërë proxysh në hapësirën e përdoruesit, të cilët "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.
Ka ardhur koha për pyetjen "Përse?"
Për çfarë është e nevojshme një service mesh?
Ata që përballen për herë të parë me idenë e service mesh-it, mund ta ndiejnë pak frikë. Strukturimi i service mesh-it do të thotë që jo vetëm do të rrisë vonesat në aplikacion, por gjithashtu do të konsumojnë burime dhe do të shtojnë një sërë mekanizmash të rinj në infrastrukturë. Së pari, ju instaloni service mesh-in, dhe më pas papritur zbuloni se duhet të menaxhoni qindra (nëse jo mijëra) proxysh. Pyetja është, kush do të pranojë të bëjë këtë?
Përgjigjja për këtë pyetje ka dy pjesë. Së pari, kostot operative të lidhura me implementimin e këtyre proxysh mund të ulen në masë të madhe falë disa ndryshimeve që po ndodhin në ekosistem (më shumë për këtë më vonë).
Së dyti, një strukturë e tillë — në të vërtetë është një mënyrë e shkëlqyer për të futur logjikë shtesë në sistem. Dhe jo vetëm sepse me ndihmën e service mesh-it mund të shtoni shumë funksione të reja, por edhe sepse kjo mund të bëhet pa ndërhyrë në ekosistemin. Në të vërtetë, e gjithë modeli i service mesh-it bazohet në këtë postulat: në një sistem me shumë shërbime, pavarësisht se çfarë bëjnë shërbimet individuale, trafiku në mes tyre është pika ideale për të shtuar funksionalitet.
Për shembull, në Linkerd (ashtu si në shumicën e mesh’ave) funksionaliteti është kryesisht i fokusuar në thirrjet HTTP, duke përfshirë HTTP/2 dhe gRPC*. Funksionaliteti është mjaft i pasur — mund të ndahet në tre kategori:
- Funksionet e lidhura me besueshmërinë.Rishikimet e kërkesave, kohët e pritjes, qasje kanari (ndarje/ridrejtim trafiku) etj.
- Funksionet e lidhura me monitorimin.Agregimi i treguesve të suksesit, vonesave dhe volumit të kërkesave për çdo shërbim ose drejtime të veçanta; ndërtimi i hartave topologjike të shërbimeve etj.
- Funksionet e lidhura me sigurinë.Mutual TLS, kontrolli i aksesit etj.
* Nga pikëpamja e Linkerd, gRPC praktikisht nuk dallon nga HTTP/2: thjesht, në ngarkesën e dobishme përdoret protobuf. Nga pikëpamja e zhvilluesit, këto dy gjëra, sigurisht, dallohet.
Shumë nga këto mekanizma veprojnë në nivelin e kërkesave (nga këtu edhe «L7-proxy»). Për shembull, nëse shërbimi Foo dërgon një thirrje HTTP te shërbimi Bar, linkerd-proxy në anën e Foo mund të bëjë një ekuilibrim inteligjent ngarkoje dhe të drejtojë thirrjet nga Foo në instancat e Bar në varësi të vonesës së vëzhguar; ai mund të përsërisë kërkesën nëse nevojitet (dhe nëse është idempotente); ai mund të regjistrojë kodin e përgjigjes dhe kohën e pritjes, etj. Në mënyrë të ngjashme, linkerd-proxy në anën e Bar mund të refuzojë kërkesën, nëse ajo nuk lejohet ose është tejkaluar kufiri i 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ë nisim një lidhje TLS, ndërsa linkerd-proxy në anën e Bar mund ta ndërpresë atë, dhe të dyja anët mund të kontrollojnë certifikatat TLS të njëra-tjetrës*. Kjo siguron jo vetëm enkriptim midis shërbimeve, por edhe një mënyrë të sigurt kriptografike për identifikimin e shërbimeve: Foo dhe Bar mund të «dëshmojnë» se janë ata që thonë se janë.
* «Njëra-tjetrës» do të thotë se certifikati i klientit gjithashtu kontrollohet (mutual TLS). Në TLS-in «klasik», për shembull, midis shfletuesit dhe serverit, zakonisht kontrollohet certifikati i vetëm një ane (serverit).
Pavarësisht nëse ata punojnë në nivelin e kërkesave apo lidhjeve, është e rëndësishme të theksohet se të gjitha funksionet e service mesh kanë karakter operacional Natyra. 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. Në këtë aspekt të rëndësishëm ne do të flasim më vonë, kur të diskutojmë për ESB dhe middleware.
Ky është seti i funksioneve që ofron service mesh. Lind pyetja: përse të mos i realizoni ato drejtpërdrejt në aplikacion? Dhe pse gjithsesi të angazhoheni me proxy?
Pse service mesh është një ide e mirë
Ndërsa mundësitë e service mesh kapin imagjinatën, vlera e saj kryesore në të vërtetë qëndron jo në funksionalitetet. Pas një fundi, ne mund të të realizoni ato drejtpërdrejt në aplikacion (më vonë do të shohim se çfarë ishte origjina e service mesh). Nëse përpiqemi ta shpreh këtë mendim me një fjali, vlera e service mesh është si vijon: ajo ofron funksionalitete që janë kritikisht të rëndësishme për funksionimin e softuerit modern të serverëve, në një mënyrë uniforme për të gjithë katin dhe të pavarur nga kodi i aplikacionit.
Le të analizojmë këtë fjali.
«Funksionalitete që janë kritikisht të rëndësishme për funksionimin e softuerit modern të serverëve». Nëse po krijoni një aplikacion server të transaksionit që është i lidhur me internetin publik, duke pranuar kërkesa nga bota e jashtme dhe duke iu përgjigjur atyre brenda një kohe të shkurtër – për shembull, një aplikacion web, një server API, madje edhe shumica dërrmuese e aplikacioneve moderne të tjera – dhe nëse e realizoni atë si një grup shërbimesh që ndërveprojnë sinjalisht me njëri-tjetrin, dhe nëse vazhdoni ta modernizoni këtë softuer, duke shtuar mundësi të reja, dhe nëse jeni të detyruar ta mbani këtë sistem në funksion gjatë procesit të modifikimit – në këtë rast ju uroj, po krijoni softuer modern server. Dhe këto funksionalitete të shkëlqyera, të renditura më sipër, me të vërtetë janë kritikisht të rëndësishme për ju. Aplikacioni duhet të jetë i besueshëm, i sigurt, dhe ju duhet të keni mundësinë të vëzhgoni atë që ai bën. Pikërisht këto çështje ndihmon të zgjidhë service mesh.
(OK, në paragrafin e mëparshëm, besimi im se ky qasje është mënyra moderne për të krijuar softuer server ka shpërthyer për një moment. Të tjerët preferojnë të zhvillojnë monolite, "mikroshërbime reaktive" dhe gjëra të tjera që nuk bien nën përkufizimin e dhënë më lart. Këto njerëz patjetër që kanë mendimin e tyre ndryshe nga i imi. Nga ana ime, mendoj se ata "nuk janë të drejtë" – megjithatë, në çdo rast service mesh për ta nuk është shumë e dobishme).
«Uniform për të gjithë katin». Funksionet që ofron service mesh nuk janë thjesht kritikisht të rëndësishme. Ato zbatohen për të gjithë shërbimet në aplikacion, pavarësisht nga gjuha në të cilën janë shkruar, cilin kornizë përdorin, kush i ka shkruar, si janë vendosur dhe nga të gjitha aspektet e tjera të zhvillimit dhe zbatimit të tyre.
«të pavarur nga kodi i aplikacionitFinally, the service mesh not only provides unified functionalities for the entire stack but does so in a way that does not require application modification. The fundamental basis of service mesh functionality, including tasks related to configuration, updates, operation, maintenance, and so on, exists entirely at the platform level and is independent of the application. The application can change without affecting the service mesh. Conversely, the service mesh can change without any involvement from the application.
In short, the service mesh not only provides vital functions but does so in a global, uniform, and application-independent manner. Therefore, while the functionality of the service mesh can be implemented in service code (for example, as a library included in each service), this approach will not ensure the homogeneity and independence that are so valuable in the case of a service mesh.
And all that is needed is to add a bunch of proxies! I promise, we will soon discuss the operational costs associated with adding these proxies. But first, let’s pause and look at this idea of independence from the perspective of various njerëzit.
Who benefits from a service mesh?
As inconvenient as it may be, for a technology to become an essential part of the ecosystem, it must be accepted by people. So who is interested in the service mesh? Who benefits from its use?
If you are developing modern server software, you can roughly envision your team as a group of service owners, who together develop and implement business logic, and platform owners, who are involved in developing the internal platform on which these services operate. In smaller organizations, these may be the same people, but as the company grows, these roles tend to become more defined and even split into sub-roles... (There is much to be said about the changing nature of DevOps, the organizational impact of microservices, etc. But for now, let’s accept these descriptions as given).
Nga kjo pikëpamje, përfituesit e dukshëm të service mesh janë pronarët e platformave. Në fund të fundit, qëllimi 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 në një mënyrë që garanton pavarësinë e tyre maksimale nga detajet e errëta të operacionit të saj. Service mesh jo vetëm që ofron mundësi kritikisht të rëndësishme për arritjen e kësaj qëllimi, por e bën këtë në një mënyrë që, nga ana tjetër, nuk imponon varësi mbi pronarët e shërbimeve.
Pronarët e shërbimeve gjithashtu përfitojnë, megjithëse në një 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 ai duhet të shqetësohet për çështjet e operimit, aq më mirë. Në vend që të angazhohet në zbatimin e, të themi, politikave të ripërsëritjes ose TLS, ata mund të përqendrohen ekskluzivisht në detyrat e biznesit dhe të shpresojnë që platforma do të kujdeset për gjithçka tjetër. Kjo është një avantazh i madh për ta.
Vlera organizative e këtij ndarjeje mes pronarëve të platformave dhe shërbimeve është e vështirë për t'u ekzagjeruar. Unë mendoj se ajo sjell kontributin në vlerën e service mesh.
Ne e mësuam këtë mësim kur një nga adhuruesit e parë të Linkerd na tregoi pse ata e zgjodhën service mesh: sepse ajo u lejoi atyre "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ë enkriptonin të gjitha komunikimet në klastere. Megjithatë, situata u komplikuar nga praninë e qindra shërbimeve dhe qindra ekipeve të zhvilluesve. Perspektiva për të kontaktuar të gjithë dhe për t'i bindur ata që të përfshinin mbështetje për TLS në planet e tyre aspak nuk i gëzonte ata. Duke instaluar Linkerd, ata transferuan përgjegjësinë nga zhvilluesit (nga perspektiva e të cilëve ishte një shqetësim i panevojshëm) te platformistët, për të cilët kjo ishte një prioritet i nivelit të lartë. Me fjalë të tjera, Linkerd zgjidhte për ta jo aq shumë një problem teknik, sa një problem organizativ.
Në përfundim, service mesh është më shumë një zgjidhje për një problem socio-teknik. (Faleminderit Cindy Sridharan за знакомство с этим термином.)
A do të zgjidhë service mesh të gjitha problemet e mia?
Po. Nënkuptoj, jo!
Nëse e shohim tri klasat e funksioneve të përmendura më lart: besueshmëria, siguria dhe vëzhgimi, bëhet e qartë se service mesh nuk është një zgjidhje për asnjë prej këtyre problemeve. Edhe pse Linkerd mund të dërgojë kërkesa të përsëritura (nëse dihet se ato janë idempotente), ai nuk është në gjendje të marrë vendime se çfarë t'i kthejë përdoruesit, nëse shërbimi ka rënë përfundimisht - këto vendime duhet t'i marrë aplikacioni. Linkerd mund të ndjekë statistikën e kërkesave të suksesshme, megjithatë ai nuk mund të shikojë brenda shërbimit dhe të ofrojë metrikat e tij të brendshme - një mjet i tillë duhet të jetë në aplikacion. Edhe pse Linkerd është në gjendje të organizojë mTLS, zgjidhjet e plota për siguri kërkojnë shumë më tepër.
Një nën-grup funksionesh në këto fusha, të ofruara nga service mesh, i përkasin karakteristikave të platformës. Duke nënkuptuar funksione që:
- Janë të pavarura nga logjika e biznesit. Mënyra se si ndërtohen histogramet e thirrjeve midis Foo dhe Bar nuk ka të bëjë aspak me atë pse Foo thërret Bar.
- Është e vështirë të realizohet saktë. Në Linkerd, përpjekjet e përsëritura janë parametrizuar nga gjëra të ndërlikuara siç janë buxhetet e përsëritjeve (retry budgets), pasi një qasje e drejtpërdrejtë në implementimin e këtyre gjërave me siguri do të çonte në një "stuhi kërkesash" (retry storm) dhe probleme të tjera që karakterizojnë sistemet e shpërndara.
- Janë më efektive kur aplikohen në mënyrë uniforme. Mekanizmi TLS ka kuptim vetëm kur aplikohet kudo.
Duke qenë se këto funksione implementohen në nivelin e proxy-t (dhe jo në nivelin e aplikacionit), service mesh i ofron ato në nivelin e platformës, dhe jo të aplikacionit. Prandaj, nuk ka rëndësi se në cilin gjuhë janë shkruar shërbimet, çfarë rame përdorin, kush i ka shkruar dhe pse. Proxyt punojnë përtej këtyre detajeve, dhe baza themelore e kësaj funksionaliteti, duke përfshirë detyrat e konfigurimit, përditësimit, funksionimit, mirëmbajtjes etj., i takon ekskluzivisht nivelit të platformës.
Shembuj të mundësive të service mesh
Duke përfunduar, dua të them se service mesh nuk është një zgjidhje e plotë për sigurimin e besueshmërisë, vëzhgueshmërisë ose sigurisë. Shtrirja e këtyre fushave implicon angazhimin e detyrueshëm të pronarëve të shërbimeve, ekipeve Ops/SRE dhe subjekteve të tjera të kompanisë. Service mesh ofron vetëm një "segment" në nivel platforme për secilën nga këto fusha.
Pse service mesh u bë popullore pikërisht tani?
Me siguri, në këtë moment po pyesni: mirë, nëse service mesh është kaq e mirë, pse nuk filluam të vendosnim miliona proxy në stack dhjetë vjet më parë?
Ka një përgjigje të thjeshtë për këtë pyetje: dhjetë vjet më parë, të gjithë ndërtuan monolite, dhe service mesh nuk i duheshim askujt. Kjo është e vërtetë, por, sipas mendimit tim, në një përgjigje të tillë humbet thelbi. Edhe dhjetë vjet më parë, koncepti i mikroshërbimeve si një qasje e ardhshme për ndërtimin e sistemeve të mëdha u diskutua gjerësisht dhe u përdor në kompani si Twitter, Facebook, Google dhe Netflix. Këndvështrimi i përgjithshëm - të paktën në ato pjesë të industrisë me të cilat kam kontaktuar - ishte se mikroshërbimet ishin " mënyra e duhur" për të ndërtuar sisteme të mëdha, edhe nëse kjo ishte jashtëzakonisht e vështirë.
Sigurisht, edhe pse dhjetë vjet më parë kishte kompani që shqyrtonin mikroshërbimet, ato nuk vendosnin proxy kudo për të formuar service mesh. Megjithatë, nëse e shikoni me kujdes, ato bënin diçka të ngjashme: në shumë nga këto kompani ishte e detyrueshme të përdorej një bibliotekë të veçantë të brendshme për ndërveprimin rrjetor (ndonjëherë e quajtur biblioteka e klientit të trashë, fat client library).
Netflix kishte Hystrix, 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 klientin ashtu edhe pjesën server të lidhjeve, lejonte rikonfirmimin e kërkesave, mbështeste rrugëzimin e kërkesave, balancimin e ngarkesës dhe matjet. Ajo siguronte një nivel të qëndrueshëm të besueshmërisë dhe vëzhgueshmërisë për gjithë stack-un e Twitter, pavarësisht nga ajo që bënte shërbimi. Sigurisht, ajo funksiononte vetëm për gjuhët JVM dhe bazohej në modelin e programimit që duhej të përdorej për të gjithë aplikacionin. Megjithatë, funksionalitetet e saj ishin pothuajse të njëjta me ato të service mesh. (Në të vërtetë, versioni i parë i Linkerd ishte thjesht Finagle, i mbështjellë në formën e një proxy.)
Prandaj, dhjetë vjet më parë, nuk kishte vetëm mikroshërbime, por edhe biblioteka të specializuara proto-service-mesh që zgjidhnin të njëjtat probleme që zgjidh sot service mesh. Megjithatë, service mesh nuk ekzistonte në atë kohë. Duhej të ndodhte një tjetër ndryshim përpara se ajo të shfaqej.
Dhe këtu qëndron përgjigjja më e thellë, e fshehur në një tjetër ndryshim që ndodhi gjatë viteve të fundit: ndodhi një rënie e menjëhershme e kostos së implementimit të mikroshërbimeve. Kompanitë e përmendura më sipër, që përdornin mikroshërbime dhjetë vjet më parë: Twitter, Netflix, Facebook, Google, ishin kompani me një masë dhe burime të mëdha. Ato kishin jo vetëm nevojë, por edhe mundësi për të krijuar, implementuar dhe operuar aplikacione të mëdha mbi bazën e mikroshërbimeve. Energji dhe përpjekje të shkakshme të inxhinierëve të Twitter për kalimin nga qasja monolite në atë mikroshërbimore janë thjesht mahnitëse. (Sinqerisht, si dhe fakti që kjo arriti.) Të tilla manovra infrastrukturore atëkohë ishin të pamundura për kompanitë më të vogla.
Le të kalojmë në të tashmen. Sot ekzistojnë startup-e ku raporti i mikroshërbimeve me zhvilluesit është 5:1 (apo edhe ), dhe më shumë se kaq, ata po i menaxhojnë me sukses! Nëse një startup me 5 persona është në gjendje, pa u lodhur, të operojë 50 mikroshërbime, atëherë diçka me siguri ka ulur kostot e implementimit të tyre.
1500 mikroshërbime në Monzo; çdo rresht është një rregull rrjeti i caktuar që lejon trafikun
Rënia e menjëhershme e kostos së operimit të mikroshërbimeve është rezultat i një procesi: rritjes së popullaritetit të kontejnerëve dhe orkestatorëve. Pikërisht këtu qëndron përgjigjja thelbësore në pyetjen se çfarë kontribuoi në shfaqjen e service mesh. E njëjta teknologji bëri që të dyja: service mesh dhe mikroshërbimet të ishin tërheqëse: Kubernetes dhe Docker.
Pse? Epo, Docker zgjidh një problem të madh — problemin e paketimit. Duke paketuar aplikacionin dhe varësitë e tij (jo rrjetore) runtime në një kontejner, Docker e kthen aplikacionin në një njësinë e ndërrueshme, që mund të vendoset dhe ekzekutohet kudo. Në të njëjtën kohë, ai thjeshton ndjeshëm operimin multilinguistik steka: pasi konteineri është një njësi atomare ekzekutimi, për qëllime vendosjeje dhe operimi nuk ka rëndësi se çfarë ndodhet brenda, qofshin aplikacione në JVM, Node, Go, Python ose Ruby. E thjesht e nisni atë, dhe mbaroi.
Kubernetes e çon gjithçka në një nivel të ri. Tani, kur ka shumë "gjëra që ekzekutohen" dhe shumë makina ku mund t'i nisni ato, lind nevoja për një mjet që mund t'i përputhë ato me njëra-tjetrën. Në një kuptim të gjerë, ju jepni Kubernetes shumë kontejnerë dhe shumë makina, dhe ai i përputh ato me njëra-tjetrën (sigurisht, ky është një proces dinamik dhe në vazhdimësi po ndryshon: kontejnerë të rinj lëvizin në sistem, makina nisën dhe ndalen etj. Megjithatë, Kubernetes e merr parasysh të gjithë këtë).
Pas konfigurimit të Kubernetes, shpenzimet e kohës për vendosjen dhe eksploatimin e një shërbimi dallohen pak nga shpenzimet për vendosjen dhe eksploatimin e dhjetë shërbimeve (në të vërtetë, ato janë pothuajse identike edhe për 100 shërbime). Shtoni në këtë kontejnerët si një mekanizëm paketimi që nxit realizimin shumëgjuhësh, dhe merrni një mori aplikacionesh të reja që realizohen në formën e mikrosherbimeve, të shkruara në gjuhë të ndryshme — pikërisht ajo mjedis që i përshtatet aq mirë service mesh.
Kështu, ne arritëm në përgjigjen e pyetjes se pse ideja e service mesh u bë e njohur tani: ajo uniformiteti që Kubernetes siguron për shërbimet, është direkt e zbatueshme për detyrat operacionale që i japin service mesh. Ju paketoni proxy-t në konteinerë, i jepni Kubernetes detyrën për t'i ngjitur kudo që është e mundur, dhe voila! Në përfundim merrni service mesh, ndërsa gjithë mekanika e saj e vendosjes menaxhohet nga Kubernetes. (Të paktën, nga një lartësi zogjsh. Natyrisht, në këtë proces ka shumë nuanca.)
Për të përmbledhur: 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 simplifikuar realizimin e aplikacioneve si grupe mikrosherbimesh shumëgjuhëshe, por gjithashtu reduktuan ndjeshëm kostot e saj të operimit, duke siguruar mekanizma për vendosjen dhe mbështetje të parqeve të proxy-eve sidecar.
Pse ka kaq shumë biseda rreth service mesh?
Kujdes: në këtë seksion unë përdor supozime, të dhëna, dhe informacione të brendshme.
Duke kërkuar për frazën "service mesh", do të gjejë shumë përmbajtje të ribërë të ulët dhe të çuditshme projektesh, si dhe një kaleidoskop të devijimeve, të denja për dhomat e jehonës. Kjo është tipike për çdo teknologji të re të modës, por në rastin e service mesh, problemi është veçanërisht i theksuar. Pse?
Epo, pjesërisht është faji im. Kam bërë çdo përpjekje për të promovuar Linkerd dhe service mesh në çdo mundësi, përmes një numri të pafund publikimesh në blog dhe artikuj si ky. Por unë nuk jam aq i fuqishëm. Për të vërtetuar këtë pyetje, duhet të flasim pak për situatën e përgjithshme. Dhe për ta bërë këtë, është e pamundur të mos përmendim një projekt: — një service mesh me burim të hapur, zhvilluar në bashkëpunim nga Google, IBM dhe Lyft.
(Këto tri kompani kanë role krejtësisht të ndryshme: përfshirja e Lyft, duket, përbëhet vetëm nga emri; ata janë autorë të Envoy, por nuk e përdorin Istio ose nuk ndihmojnë në zhvillimin e tij. IBM merr pjesë në zhvillimin e Istio dhe e përdor atë. Google merr pjesë aktivisht në zhvillimin e Istio, por, sa mund ta gjykoj, në të vërtetë nuk e përdor.)
Projekti Istio është i njohur për dy veçori. Së pari, janë përpjekjet e mëdha marketingu, që Google, sidomos, e bën për ta promovuar. Sipas vlerësimeve të mia, shumica e njerëzve që janë të informuar rreth konceptit të service mesh tani e kanë mësuar për herë të parë për të falë Istio. Veçoria e dytë është se sa keq është pranuar Istio. Në këtë çështje, unë, padyshim, jam një palë e interesuar, por duke u përpjekur të mbetem sa më objektiv, nuk mund të mos , jo shumë tipike (edhe pse jo unike: më vjen në mend systemd, …) për një projekt Open Source.
(Në praktikë, Istio duket se ka probleme jo vetëm me kompleksitetin dhe UX, por edhe me performancën. Për shembull, gjatë , të kryer nga një palë e tretë, specialistët zbuluan situata në të cilat tail latency e Istio ishte 100 herë më e lartë se e njëjta tregues për Linkerd, si dhe situata me mungesë resursesh, ku Linkerd vazhdoi të funksiononte me sukses, ndërsa Istio ndaloi plotësisht funksionimin.)
Duke anë tona teorik përse ndodhi kjo, unë mendoj se entuziazmi i jashtëzakonshëm rreth service mesh shpjegohet veçanërisht nga pjesëmarrja e Google. Në veçanti, nga kombinimi i tre faktorëve të mëposhtëm:
- nxitja e gjithanshme e Istio nga Google;
- reagimi i papëlqyer dhe kritik ndaj projektit;
- ngritja e shpejtë e fundit e popullaritetit të Kubernetes, kujtimet e të cilit janë ende të freskëta.
Së bashku këta faktorë bashkohen në një ambient dehës, pa oksigjen, në të cilin aftësia për gjykim racional dobësohet, dhe mbetet vetëm një lloj i mrekullueshëm .
Nga këndvështrimi i Linkerd, kjo… do ta përshkruaja si një të mirën e pamohueshme. Kam parasysh, është mbresëlënëse që service mesh ka hyrë në mjedisin kryesor - diçka që nuk ndodhi në 2016, kur Linkerd sapo kishte dalë e ishte vërtet e vështirë të tërhiqje vëmendjen e të tjerëve në projekt. Tani nuk ka një problem të tillë! Por e keqja është se situata me service mesh sot është aq e ndërlikuar, sa që është pothuajse e pamundur të kuptosh se cilat projekte vërtet i përkasin kategorisë service mesh (pa folur për të kuptuar se cili është më i përshtatshmi për një rast të caktuar përdorimi). Kjo, pa dyshim, pengon të gjithë (dhe, padyshim, në disa raste Istio ose një projekt tjetër është më i përshtatshëm se Linkerd, pasi ky i fundit nuk është një zgjidhje universale).
Nga ana e Linkerd, strategjia jonë përfshinte injorimin e zhurmës, vazhdimin e fokusit mbi zgjidhjen e problemeve reale të komunitetit dhe, në thelb, të prisnim derisa entuziazmi të qetësohej. Në fund të fundit, hype do të bjerë, dhe ne do të mund të vazhdojmë punën pa stres.
Megjithatë, të gjithë ne do të duhet të presim pak më shumë.
A do të jetë e dobishme service mesh për mua, një inxhinier software modest?
Me këtë pyetje do të ndihmojë një pyetësor i mëposhtëm:
A jeni duke u përfshirë ekskluzivisht në implementimin e logjikës biznesore? Në këtë rast, service mesh nuk do t'ju nevojitet. Do të thotë, sigurisht, mund t'ju interesojë, por idealisht service mesh nuk duhet të ndikojë drejtpërdrejt në asgjë në mjedisin tuaj. Vazhdoni të punoni mbi atë për të cilën paguheni.
A mbani një platformë në kompaninë e cila përdor Kubernetes? Po, në këtë rast, ju nevojitet një service mesh (sigurisht, nëse nuk po përdorni K8s thjesht për të drejtuar një monolit ose për përpunimin e grumbullit – por atëherë do doja të pyesja, përse ju nevojitet K8s). Me shumë gjasa, do të gjendeni në një situatë me shumë mikrosherbime, të shkruara nga njerëz të ndryshëm. Të gjitha ato ndërveprojnë me njëra-tjetrën dhe janë të lidhura në një grumbull varësish runtime, dhe ju nevojitet një mënyrë për të menaxhuar gjithçka këtë. Përdorimi i Kubernetes lejon të zgjidhni një service mesh “bëni për ju”. Për këtë, hidhni një sy mundësive dhe karakteristikave të tyre dhe përgjigjuni pyetjes nëse ndonjë projekt nga ata është i përshtatshëm për ju (rekomandoj të filloni hulumtimin me Linkerd).
A jeni përgjegjës për platformën në një kompani që NUK përdor Kubernetes, por përdor mikrosherbime? Në këtë rast, service mesh do t'ju jetë e dobishme, megjithatë përdorimi i saj do të jetë i komplikuar. Sigurisht, mund të imitoni funksionimin e service mesh, duke vendosur një mori proxy, por një përparësi e rëndësishme e Kubernetes është modeli i deploy-it: menaxhimi i këtyre proxy-ve me dorë do të kërkojë shumë më tepër kohë, mund dhe burime.
A jeni përgjegjës për platformën në një kompani që punon me monolite? Në këtë rast, service mesh ndoshta nuk ju nevojitet. Nëse po punoni me monolite (ose madje me grupe monolitesh), që kanë modele ndërveprimi të qarta dhe që ndryshojnë rrallë, atëherë service mesh nuk do t'ju ofrojë shumë. Pra, mund të thoni thjesht se nuk e keni vënë re dhe të shpresoni se ajo do të largohet si një makth...
Përfundim
Ndoshta, nuk duhet ta quajmë service mesh "teknologjia më e hype-uar në botë" – kjo çmim i dyshimtë ndoshta i përket bitcoinit ose AI-së. Ndoshta ajo është në pesë të parat. Por nëse kaloni përmes shtresave të zhurmës dhe zhurmë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ë shihni vetë se për çfarë flas.
FAQ
-- Nëse unë do ta injoroj service mesh, a do të largohet ajo?
-- Duhet t'ju mërzitem: service mesh është me ne për një kohë të gjatë.
-- Por UNË NUK DUA të përdor service mesh!
-- Mirë, atëherë mos e përdorni! Thjesht lexoni anketën time më lart për të kuptuar nëse duhet të njihem edhe me bazat e saj.
-- A është kjo një ESB/middleware e vjetër e njohur në një sos të ri?
— Shërbimi i rrjetit merret me logjikën operacionale, jo me kuptimin. e busit të shërbimeve të ndërmarrjes (). Ruajtja e këtij ndarjeje ndihmon shërbimin e rrjetit të shmangë të njëjtin fat.
— Si dallohet shërbimi i rrjetit nga portat API?
— Ekzistojnë një milion artikuj në këtë temë. Thjesht kërkoni në Google.
— A është Envoy shërbim rrjeti?
— Jo, Envoy nuk është një shërbim rrjeti, është një server proxy. Ai mund të përdoret për organizimin e shërbimit të rrjetit (dhe shumë gjëra të tjera — është një proxy i përgjithshëm). Por vetë ai nuk është një shërbim rrjeti.
— A është Network Service Mesh një shërbim rrjeti?
— Jo. Pavarësisht emrit, kjo nuk është një shërbim rrjeti (çfarë mrekullie e marketingut!).
— A do të ndihmojë shërbimi i rrjetit me sistemin tim reaktiv asinkron të bazuar në radhë mesazhesh?
— Jo, shërbimi i rrjetit nuk do t'ju ndihmojë.
— Cilin shërbim rrjeti duhet të përdor?
— , e qartë si drita.
— Artikulli është një katastrofë! / Autori për në plehra!
— Ju lutem, ndani linkun me të gjithë miqtë që ata të mund ta verifikojnë këtë!
Faleminderit
Siç mund ta merrni me mend nga emri, ky artikull u frymëzua nga traktati fantastik i Jay Kreps «». E kam takuar Jay-in dhjetë vjet më parë, kur isha intervistuar në LinkedIn, dhe që atëherë ai ka qenë një burim frymëzimi për mua.
Megjithatë, unë e dua të quaj veten « zhvilluesi i Linkerd», realiteti është se unë jam më shumë një mbajtës i dosjes README.md në projekt. Sot për Linkerd punojnë , , njerëz, dhe ky projekt nuk do të ishte arritur pa kontributin e shkëlqyer 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 shumë vite më parë u zhyt thellë në gjithë këtë zhurmë me shërbimin e rrjetit.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
