Notu. transl.: Serva maŝo estas fenomeno, kiu ankoraŭ ne havas stabilan tradukon en la rusan (antaŭ pli ol 2 jaroj ni proponis la opcion "maŝo por servoj", kaj iom poste kelkaj kolegoj komencis aktive reklami la kombinaĵon "serva kribrilo"). Konstanta parolado pri ĉi tiu teknologio kondukis al situacio en kiu la merkatado kaj teknikaj komponantoj estas tro proksime interplektitaj. Ĉi tiu mirinda materialo de unu el la aŭtoroj de la originala termino celas provizi klarecon por inĝenieroj kaj aliaj.
Bildstrio de
Enkonduko
Se vi estas programaro-inĝeniero laboranta ie en la backend-sistema spaco, la esprimo "serva maŝo" verŝajne jam firme enradikiĝis en via menso dum la pasintaj du jaroj. Dank' al stranga koincido, ĉi tiu frazo pli kaj pli transprenas la industrion, kaj la furoraĵo kaj reklamaj ofertoj asociitaj kun ĝi kreskas kiel neĝbulo fluganta malsupren kaj ne montras signojn de malrapidiĝo.
Servomaŝo naskiĝis en la malklaraj, partiaj akvoj de la nuba indiĝena ekosistemo. Bedaŭrinde, ĉi tio signifas, ke granda parto de la polemiko ĉirkaŭ ĝi iras de "malkaloria babilado" ĝis - por uzi teknikan terminon - tute sensencaĵo. Sed se vi tratranĉas la tutan bruon, vi trovos, ke la servomaŝo havas tre realan, difinitan kaj gravan funkcion.
En ĉi tiu afiŝo, mi provos fari ĝuste tion: provizi honestan, profundan, inĝenier-fokusitan gvidilon al servomaŝo. Mi ne nur respondos la demandon: "Kio ĝi estas?", - sed ankaŭ "Kial?"Kaj "Kial nun?". Fine, mi provos skizi kial (laŭ mi) ĉi tiu aparta teknologio kaŭzis tian frenezan eksciton, kio estas interesa rakonto en si mem.
Кто я?
Saluton al ĉiuj! Mia nomo estas . Mi estas unu el la kreintoj — la plej unua serva retprojekto kaj la projekto, kiu kulpas pri la apero de la termino servmaŝo kiel tia (pardonu infanojn!). (Notu transl.: Cetere, je la tagiĝo de la apero de ĉi tiu termino, antaŭ pli ol 2,5 jaroj, ni jam tradukis la fruan materialon de la sama aŭtoro titolita “".) Mi ankaŭ estras estas starto, kiu kreas bonegajn servajn maŝaĵojn kiel Linkerd kaj .
Vi verŝajne povas diveni, ke mi havas tre partian kaj subjektivan opinion pri ĉi tiu afero. Tamen, mi provos minimumigi biason (krom unu sekcio: "Kial oni tiom parolas pri servomaŝo?", - en kiu mi ankoraŭ kundividos miajn antaŭkonceptitajn ideojn). Mi ankaŭ faros mian plejeblon por fari ĉi tiun gvidilon kiel eble plej objektiva. Por specifaj ekzemploj, mi ĉefe fidos je la sperto de Linkerd, dum mi atentigas diferencojn (se ekzistas) pri kiuj mi konas en la efektivigo de aliaj servaj rettipoj.
Bone, tempo por pluiri al la bonaĵoj.
Kio estas servomaŝo?
Malgraŭ la tuta ekzaktado, la strukturo de la serva reto estas sufiĉe simpla. Ĉi tio estas nur aro da uzantspacaj prokuriloj situantaj "apud" la servoj (ni iom parolos pri tio, kio estas "apud" poste), plus aro da kontrolprocezoj. La prokuriloj estas kolektive nomitaj datumaviadilo, kaj la kontrolprocezoj estas nomitaj kontrolaviadilo. La datenaviadilo kaptas vokojn inter servoj kaj faras "ĉiajn malsamajn aferojn" kun ili; La kontrolaviadilo, sekve, kunordigas la konduton de la prokurilo kaj disponigas aliron por vi, t.e. funkciigisto, al la API, permesante al la reto esti manipulita kaj mezurita kiel tutaĵo.
Kia prokurilo estas ĉi tio? Ĉi tio estas Tavolo 7-konscia TCP-prokurilo (t.e. "konsiderante" tavolon 7 de la OSI-modelo) kiel HAProxy kaj NGINX. Vi povas elekti prokurilon laŭ via plaĉo; Linkerd uzas Rust-prokurilon, simple nomitan . Ni kunmetis ĝin specife por servo maŝo. Aliaj maŝoj preferas aliajn prokurojn (Envoy estas ofta elekto). Tamen, elekti prokurilon estas nur afero de efektivigo.
Kion faras ĉi tiuj prokuraj serviloj? Evidente, ili prokuras vokojn al kaj de servoj (strikte parolante, ili funkcias kiel prokuriloj kaj inversaj prokuriloj, pritraktante kaj envenantajn kaj elirantajn vokojn). Kaj ili efektivigas funkciojn, kiu fokusiĝas al vokoj inter la servoj. Ĉi tiu fokuso pri trafiko inter servoj estas tio, kio distingas servan retprokurilon de, ekzemple, API-enirejoj aŭ enirprokuriloj (ĉi-lastaj fokusoj pri vokoj venantaj en la areton de la ekstera mondo). (Notu. transl.: Por komparo de ekzistantaj Ingress-regiloj por Kubernetes, multaj el kiuj uzas la jam menciitan Envoy, vidu .)
Do, ni ordigis la datumaviadilon. La kontrolaviadilo estas pli simpla: ĝi estas aro de komponentoj kiuj disponigas ĉiujn mekanikojn kiujn la datenaviadilo bezonas funkcii en kunordigita maniero, inkluzive de servo-malkovro, emisiado de TLS-atestiloj, metrika agregado, ktp. La datumaviadilo informas la kontrolaviadilon pri ĝia konduto; siavice, la kontrolaviadilo provizas API, kiu permesas vin ŝanĝi kaj kontroli la konduton de la datumaviadilo entute.
Malsupre estas diagramo de la kontrolaviadilo kaj datenaviadilo en Linkerd. Kiel vi povas vidi, la kontrolaviadilo inkluzivas plurajn malsamajn komponentojn, inkluzive de Prometheus-instanco, kiu kolektas metrikojn de prokuraj serviloj, same kiel aliajn komponentojn kiel ekzemple destination (serva malkovro), identity (atestila aŭtoritato, CA) kaj public-api (finpunktoj por retejo kaj CLI). En kontrasto, la datumaviadilo estas simpla linkerd-proxy apud la aplikaĵa petskribo. Ĉi tio estas nur logika diagramo; En reala monda deplojo, vi eble havas tri kopiojn de ĉiu kontrolebena komponento kaj centojn aŭ milojn da prokuriloj en la datumaviadilo.
(La bluaj rektanguloj en ĉi tiu diagramo simbolas la limojn de Kubernetes podoj. Vi povas vidi ke la ujoj kun linkerd-proxy estas en la sama pod kiel la aplikaĵujoj. Ĉi tiu skemo estas konata kiel sidecar ujo.)
Serva mesh-arkitekturo havas plurajn gravajn implicojn. Unue, ĉar la tasko de prokurilo estas kapti vokojn inter servoj, servomaŝo nur havas sencon se via aplikaĵo estis kreita por certa aro da servoj. Maŝo povas uzi kun monolitoj, sed ĉi tio estas klare superflua pro unu sola prokurilo, kaj ĝia funkcieco verŝajne ne estos postulata.
Alia grava konsekvenco estas, ke la servo maŝo postulas grandega nombro da prokuriloj. Fakte, Linkerd ligas linkerd-proxy al ĉiu okazo de ĉiu servo (aliaj efektivigoj aldonas prokurilon al ĉiu nodo/gastiganto/virtuala maŝino. Tio estas multe ĉiuokaze). Tia aktiva uzo de prokuriloj en si mem portas kelkajn pliajn komplikaĵojn:
- Prokuroj en la datumaviadilo devas esti rapida, ĉar por ĉiu voko estas paro da vokoj al la prokurilo: unu ĉe la klientflanko, unu ĉe la servilo.
- Ankaŭ prokuriloj devus esti malgranda и malpeza. Ĉiu konsumos memoron kaj CPU-resursojn, kaj ĉi tiu konsumo kreskos linie kun la aplikaĵo.
- Vi bezonos mekanismon por disfaldi kaj ĝisdatigi grandan nombron da prokuriloj. Fari ĝin permane ne estas eblo.
Ĝenerale, servomaŝo aspektas jene (almenaŭ el birdorigardo): vi deplojas amason da uzantspacaj prokuriloj kiuj "faras ion" kun interna, inter-serva trafiko, kaj uzas kontrolaviadilon por kontroli kaj administri ilin.
Nun estas tempo demandi la demandon "Kial?"
Por kio utilas servomaŝo?
Tiuj, kiuj unue renkontis la ideon de servomaŝo, povus esti pardonitaj, ke ili sentas sin iom maltrankvilaj. La serva retdezajno signifas, ke ĝi ne nur pliigos latencian en la aplikaĵo, sed ankaŭ konsumi rimedoj kaj aldonos amaso da novaj mekanismoj en la infrastrukturo. Unue vi starigas servomaŝon, kaj tiam subite vi bezonas servi centojn (se ne milojn) da prokuriloj. La demando estas, kiu propravole faros tion?
La respondo al ĉi tiu demando havas du partojn. Unue, la transakciaj kostoj asociitaj kun deplojado de ĉi tiuj prokuriloj povas esti signife reduktitaj danke al iuj ŝanĝoj okazantaj en la ekosistemo (pli pri tio poste).
Due, tia aparato estas efektive bonega maniero enkonduki plian logikon en la sistemon. Ne nur ĉar servomaŝo povas aldoni multajn novajn funkciojn, sed ankaŭ ĉar ĝi povas esti farita sen malhelpi la ekosistemon. Fakte, la tuta servo-maŝo-modelo baziĝas sur ĉi tiu premiso: en multiserva sistemo, negrave kio fari individuaj servoj, trafiko inter ili estas la ideala punkto por aldoni funkciojn.
Ekzemple, en Linkerd (kiel en la plej multaj retoj) la funkcieco estas koncentrita ĉefe al HTTP-vokoj, inkluzive de HTTP/2 kaj gRPC*. La funkcieco estas sufiĉe riĉa - ĝi povas esti dividita en tri klasojn:
- Trajtoj rilataj al fidindeco. Ripetaj petoj, paŭzoj, kanaria aliro (trafikdividado/alidirekto), ktp.
- Trajtoj rilataj al monitorado. Agregado de sukcesprocentoj, prokrastoj kaj petaj volumoj por ĉiu servo aŭ individuaj direktoj; konstruado de topologiaj mapoj de servoj, ktp.
- Trajtoj rilataj al sekureco. Reciproka TLS, alirkontrolo, ktp.
* El la vidpunkto de Linkerd, gRPC preskaŭ ne diferencas de HTTP/2: ĝi nur uzas protobuf en la utila ŝarĝo. El la vidpunkto de programisto, la du aferoj estas, kompreneble, malsamaj.
Multaj el tiuj mekanismoj funkcias je la peta nivelo (tial la "L7-prokurilo"). Ekzemple, se la Foo-servo faras HTTP-vokon al la Bar-servo, la linkerd-proxy sur la Foo-flanko povas elfari inteligentan ŝarĝan ekvilibron kaj direkti vokojn de Foo al Bar-okazoj bazitaj sur la observita latencia; ĝi povas ripeti la peton se necese (kaj se ĝi estas idempotenta); ĝi povas registri la respondkodon kaj eltempon, ktp. Simile, linkerd-proxy ĉe la Bar-flanko povas malakcepti peton se ĝi ne estas permesita aŭ la petolimo estas superita; povas registri malfruon siaflanke, ktp.
Prokuriloj povas "fari ion" ankaŭ ĉe la koneksa nivelo. Ekzemple, linkerd-proxy ĉe la Foo-flanko povas iniciati TLS-konekton, kaj linkerd-proxy ĉe la Bar-flanko povas ĉesigi ĝin, kaj ambaŭ flankoj povas kontroli la TLS-atestilojn de unu la alian*. Ĉi tio provizas ne nur ĉifradon inter servoj, sed ankaŭ kriptografie sekuran manieron identigi servojn: Foo kaj Bar povas "pruvi" ke ili estas kiuj ili diras ke ili estas.
* "Reciproka amiko" signifas, ke la klientatestilo ankaŭ estas kontrolita (reciproka TLS). En "klasika" TLS, ekzemple inter retumilo kaj servilo, la atestilo de nur unu flanko (la servilo) estas kutime kontrolita.
Sendepende de ĉu ili funkcias je la peta aŭ koneksa nivelo, estas grave emfazi, ke ĉiuj servomaŝo-funkcioj estas funkcianta karaktero. Linkerd ne kapablas transformi la semantikon de la utila ŝarĝo - ekzemple, aldonante kampojn al JSON-fragmento aŭ farante ŝanĝojn al protobuf. Pri ĉi tiu grava funkcio ni parolos poste, kiam ni parolos pri ESB kaj mezvaro.
Ĉi tiu estas la aro de funkcioj, kiujn proponas servomaŝo. La demando ŝprucas: kial ne efektivigi ilin rekte en la aplikaĵo? Kaj kial entute ĝeni prokurilo?
Kial servo mesh estas bona ideo
Dum la kapabloj de servomaŝo estas ekscitaj, ĝia kerna valoro fakte ne kuŝas en siaj trajtoj. En la fino ni Povas efektivigi ilin rekte en la aplikaĵo (ni poste vidos, ke ĉi tio estis la origino de la servo-maŝo). Por provi resumi ĝin en unu frazo, la valoro de servomaŝo estas: ĝi provizas funkciojn kritikajn por funkcii modernan servilan programon en konsekvenca maniero tra la tuta stako kaj sendepende de aplika kodo.
Ni analizu ĉi tiun proponon.
«Trajtoj kritikaj por funkcii modernan servilan programon" Se vi kreas transakcian servilan aplikaĵon, kiu estas konektita al la publika Interreto, akceptas petojn de la ekstera mondo kaj respondas al ili en mallonga tempo - ekzemple, TTT-aplikaĵo, API-servilo kaj la vasta plimulto de aliaj modernaj aplikoj. - kaj se vi efektivigas ĝin kiel aron da servoj, kiuj sinkrone interagas unu kun la alia, kaj se vi konstante ĝisdatigas ĉi tiun programaron, aldonante novajn funkciojn, kaj se vi estas devigitaj konservi ĉi tiun sistemon en funkciado dum la modifa procezo - en ĉi tiu kazo, gratulon, vi kreas modernan servilan programon. Kaj ĉiuj ĉi tiuj bonegaj funkcioj listigitaj supre efektive rezultas kritikaj por vi. La aplikaĵo devas esti fidinda, sekura, kaj vi devas povi observi, kion ĝi faras. Ĉi tiuj estas ĝuste la demandoj, kiujn servo mesh helpas solvi.
(Bone, la antaŭa alineo ankoraŭ inkluzivas mian kredon, ke ĉi tiu aliro estas la moderna maniero krei servilan programon. Aliaj preferas evoluigi monolitojn, "reaktivajn mikroservojn" kaj aliajn aferojn, kiuj ne estas sub la difino donita supre. Ĉi tiuj homoj verŝajne havas sian opinio estas malsama ol mia. Siavice mi opinias, ke ili estas "malĝustaj" - kvankam ĉiukaze la serva maŝo ne estas tre utila por ili).
«Uniformo por la tuta stako" La funkcieco provizita de servomaŝo ne estas nur misi-kritika. Ili validas por ĉiuj servoj en la aplikaĵo, sendepende de kia lingvo ili estas skribitaj, kia kadro ili uzas, kiu skribis ilin, kiel ili estis deplojitaj, kaj ajnaj aliaj subtilecoj de ilia evoluo kaj uzo.
«Sendepende de aplika kodo" Fine, servomaŝo ne nur provizas konsekvencan funkciecon tra la tuta stako, ĝi faras tion en maniero, kiu ne postulas, ke la aplikaĵo estu redaktita. La fundamenta bazo de servomaŝo-funkcieco, inkluzive de taskoj por agordo, ĝisdatigo, operacio, prizorgado, ktp., loĝas tute ĉe la platformnivelo kaj estas sendependa de la aplikaĵo. La aplikaĵo povas ŝanĝiĝi sen tuŝi la servan maŝon. Siavice, la servo-maŝo povas ŝanĝiĝi sen ia partopreno de la aplikaĵo.
Mallonge, servomaŝo ne nur provizas esencan funkciecon, sed ankaŭ faras tion en tutmonda, unuforma kaj aplikaĵ-sendependa maniero. Kaj tiel, kvankam servomaŝo funkcieco povas esti efektivigita en servokodo (ekzemple, kiel biblioteko inkluzivita en ĉiu servo), tiu aliro ne provizos la unuformecon kaj sendependecon kiuj estas tiel valoraj en la kazo de servomaŝo.
Kaj ĉio, kion vi bezonas fari, estas aldoni amason da prokuriloj! Mi promesas, ke ni rigardos la funkciajn kostojn asociitajn kun aldono de ĉi tiuj prokuriloj tre baldaŭ. Sed unue ni haltu kaj rigardu ĉi tiun ideon de sendependeco de malsamaj perspektivoj. personoj.
Kiun servo mesh helpas?
Kiel ajn maloportuna ĝi povas esti, por ke teknologio fariĝu grava parto de la ekosistemo, ĝi devas esti akceptita de homoj. Kiu do interesiĝas pri servo-maŝo? Kiu profitas de ĝia uzo?
Se vi disvolvas modernan servilan programon, vi povas proksimume pensi pri via teamo kiel grupo servaj posedantojkiuj kune disvolvas kaj efektivigas komercan logikon, kaj posedantoj de platformoj, evoluigante la internan platformon sur kiu ĉi tiuj servoj funkcias. En malgrandaj organizoj, ĉi tiuj povas esti la samaj homoj, sed dum la kompanio kreskas, ĉi tiuj roloj tendencas fariĝi pli prononcitaj kaj eĉ dividitaj en subrolojn... (Estas multo por diri ĉi tie pri la ŝanĝiĝanta naturo de devopoj, la organiza efiko de mikroservoj ktp.) n. Sed nuntempe ni prenu ĉi tiujn priskribojn kiel donitajn).
De ĉi tiu vidpunkto, la klaraj profitantoj de la servo-maŝo estas la platformaj posedantoj. Post ĉio, finfine la celo de la platforma teamo estas krei internan platformon, sur kiu servaj posedantoj povas efektivigi komercan logikon kaj fari tion en maniero, kiu certigas, ke ili estas kiel eble plej sendependaj de la malklaraj detaloj de ĝia operacio. Ne nur servomaŝo ofertas kapablojn kritikajn por atingi ĉi tiun celon, ĝi faras tion en maniero kiel kiu siavice ne trudas dependecojn al servposedantoj.
Servaj posedantoj ankaŭ profitas, kvankam en pli nerekta maniero. La celo de la serva posedanto estas esti kiel eble plej produktiva en la efektivigo de la logiko de la komerca procezo, kaj ju malpli li devas zorgi pri operaciaj aferoj, des pli bone. Anstataŭ devi trakti efektivigon, ekzemple, reprovi politikojn aŭ TLS, ili povas koncentriĝi nur pri komercaj celoj kaj esperi, ke la platformo prizorgas la reston. Ĉi tio estas granda avantaĝo por ili.
La organiza valoro de tia divido inter la posedantoj de platformoj kaj servoj ne povas esti supertaksita. Mi pensas, ke ŝi kontribuas la ĉefa kontribuo al la valoro de la servomaŝo.
Ni lernis ĉi tiun lecionon kiam frua Linkerd-adoranto diris al ni kial ili elektis servomaŝon: ĉar ĝi permesis al ili "teni la parolantan butikon al minimumo." Jen kelkaj detaloj: la uloj de unu granda kompanio migris sian platformon al Kubernetes. Ĉar la aplikaĵo traktis sentemajn informojn, ili volis ĉifri ĉiujn komunikadojn tra la aretoj. Tamen, la situacio estis komplikita pro la ĉeesto de centoj da servoj kaj centoj da evoluigaj teamoj. La perspektivo kontakti ĉiujn kaj konvinki ilin inkluzivi TLS-subtenon en iliaj planoj tute ne feliĉigis ilin. Post instalo de Linkerd, ili translokiĝis respondeco de programistoj (de kies vidpunkto tio estis nenecesa problemo) ĝis platformistoj, por kiuj ĉi tio estis plej alta prioritato. Alivorte, Linkerd solvis por ili ne tiom teknikan problemon, kiom organizan.
Resume, servomaŝo estas pli solvo, ne teknika, sed soci-teknika Problemoj. (Dankon por enkonduki ĉi tiun terminon.)
Ĉu servomaŝo solvos ĉiujn miajn problemojn?
Jes. Mi volas diri, ne!
Se vi rigardas la tri klasojn de funkcioj skizitaj supre - fidindeco, sekureco kaj observeblo - evidentiĝas, ke servomaŝo ne estas kompleta solvo al iu el ĉi tiuj problemoj. Dum Linkerd povas reeldoni petojn (se ĝi scias, ke ili estas idempotentaj), ĝi estas nekapabla fari decidojn pri kio reveni al la uzanto se la servo konstante malsukcesis - tiuj decidoj devas esti faritaj de la aplikaĵo. Linkerd povas konservi statistikojn pri sukcesaj petoj, sed ĝi ne kapablas rigardi la servon kaj disponigi ĝiajn internajn metrikojn - la aplikaĵo devas havi tiajn ilojn. Kaj kvankam Linkerd kapablas organizi mTLS, plenrajtaj sekurecaj solvoj postulas multe pli.
Subaro de la funkcioj en ĉi tiuj areoj ofertitaj de la servomaŝo rilatas al platformaj trajtoj. Per ĉi tio mi celas funkciojn kiuj:
- Sendepende de komerca logiko. La maniero kiel alvokohistogramoj inter Foo kaj Bar estas konstruitaj estas tute sendependa de kial Foo vokas Bar.
- Malfacile efektivigi ĝuste. En Linkerd, reprovoj estas parametrizitaj kun ĉiaj luksaj aferoj kiel reprovi buĝetoj (reprovi buĝetojn), ĉar nesofistika, alfronta aliro al efektivigo de tiaj aferoj certe kondukos al la apero de tiel nomata "lavango de petoj" (reprovi ŝtormon) kaj aliaj problemoj karakterizaj por distribuitaj sistemoj.
- Plej efika kiam aplikata unuforme. La TLS-mekanismo nur havas sencon se ĝi estas aplikata ĉie.
Ĉar ĉi tiuj funkcioj estas efektivigitaj ĉe la prokura nivelo (kaj ne ĉe la aplikaĵnivelo), la servomaŝo provizas ilin ĉe la platformo, ne aplikoj. Tiel, ne gravas en kiu lingvo la servoj estas skribitaj, kia kadro ili uzas, kiu skribis ilin kaj kial. Prokuriloj funkcias ekster ĉiuj ĉi tiuj detaloj, kaj la fundamenta bazo de ĉi tiu funkcio, inkluzive de taskoj por agordo, ĝisdatigo, funkciado, prizorgado ktp., situas nur sur la platforma nivelo.
Ekzemploj de servomaŝo-kapabloj
Por resumi, servomaŝo ne estas kompleta solvo por fidindeco, observeblo aŭ sekureco. La amplekso de ĉi tiuj areoj postulas la partoprenon de servposedantoj, Ops/SRE-teamoj kaj aliaj firmaaj entoj. La servomaŝo nur provizas platform-nivelan "tranĉaĵon" por ĉiu el ĉi tiuj areoj.
Kial servomaŝo fariĝis populara nun?
Nun vi verŝajne scivolas: bone, se la serva maŝo estas tiel bona, kial ni ne komencis deploji milionojn da prokuriloj en la stako antaŭ dek jaroj?
Estas banala respondo al ĉi tiu demando: antaŭ dek jaroj ĉiuj konstruis monolitojn, kaj neniu bezonis servomaŝon. Ĉi tio estas vera, sed laŭ mi ĉi tiu respondo maltrafas. Eĉ antaŭ dek jaroj, la koncepto de mikroservoj kiel promesplena maniero konstrui grandskalajn sistemojn estis vaste diskutita kaj aplikata ĉe kompanioj kiel Twitter, Facebook, Google kaj Netflix. La ĝenerala vidpunkto - almenaŭ en la partoj de la industrio kun kiuj mi kontaktis - estis ke mikroservoj estis la "ĝusta maniero" konstrui grandajn sistemojn, eĉ se ĝi estis diable malfacila.
Kompreneble, kvankam antaŭ dek jaroj ekzistis kompanioj funkciigantaj mikroservojn, ili ne algluis prokurojn ĉie ili povis por formi servan reton. Tamen, se vi atente rigardas, ili faris ion similan: multaj el ĉi tiuj kompanioj postulis la uzon de speciala interna biblioteko por retkomunikado (kelkfoje nomata dika klienta biblioteko, dika klienta biblioteko).
Netflix havis Hysterix, Google havis Stubby, Twitter havis la bibliotekon Finagle. Finagle, ekzemple, estis deviga por ĉiu nova servo en Twitter. Ĝi pritraktis kaj la klient- kaj servilflankon de ligoj, permesis ripetajn petojn, apogis petovojigon, ŝarĝbalancadon kaj mezuradon. Ĝi disponigis konsekvencan tavolon de fidindeco kaj observeblo tra la tuta Twitter-stako, sendepende de tio, kion la servo faris. Kompreneble, ĝi funkciis nur por JVM-lingvoj kaj baziĝis sur programa modelo, kiu devis esti uzata por la tuta aplikaĵo. Tamen, ĝia funkcieco estis preskaŭ la sama kiel tiu de la servomaŝo. (Fakte, la unua versio de Linkerd estis simple Finagle envolvita en prokura formo.)
Tiel, antaŭ dek jaroj ekzistis ne nur mikroservoj, sed ankaŭ specialaj proto-servaj-retaj bibliotekoj, kiuj solvis la samajn problemojn, kiujn servas-maŝo solvas hodiaŭ. Tamen, la servomaŝo mem ne ekzistis tiam. Devis esti unu plia deĵoro antaŭ ol ŝi aperis.
Kaj ĉi tie kuŝas la pli profunda respondo, kaŝita en alia ŝanĝo, kiu okazis dum la lastaj 10 jaroj: la kosto de disfaldi mikroservoj draste malpliiĝis. La supre menciitaj kompanioj, kiuj uzis mikroservojn antaŭ dek jaroj—Twitter, Netflix, Facebook, Google—estis firmaoj de grandega skalo kaj grandegaj rimedoj. Ili ne nur havis la bezonon, sed ankaŭ la kapablon konstrui, deploji kaj funkciigi grandajn mikroserv-bazitajn aplikojn. La energio kaj penado, kiujn Twitter-inĝenieroj metis por transiri de monolita al mikroserva aliro, estas mirindaj. (Por esti juste, ankaŭ la fakto, ke ĝi sukcesis.) Tiuj specoj de infrastrukturaj manovroj tiam estis maleblaj por pli malgrandaj firmaoj.
Rapide antaŭen al la nuntempo. Estas noventreprenoj hodiaŭ, kie la proporcio de mikroservoj al programistoj estas 5:1 (aŭ eĉ ), kaj kio estas pli, ili sukcesas trakti ilin! Se 5-persona starto povas facile funkciigi 50 mikroservojn, tiam io klare reduktis la koston de ilia efektivigo.
1500 mikroservoj en Monzo; ĉiu linio estas preskribita retoregulo kiu permesas trafikon
La rimarkinda redukto de la kosto de funkciado de mikroservoj estas la rezulto de unu procezo: kreskanta populareco de ujoj и orkestroistoj. Ĉi tio estas ĝuste la profunda respondo al la demando, kio kontribuis al la apero de la servo-maŝo. La sama teknologio faris kaj servajn retojn kaj mikroservojn allogaj: Kubernetes kaj Docker.
Kial? Nu, Docker solvas unu grandan problemon - la pakproblemon. Enpakante aplikaĵon kaj ĝiajn (ne-retajn) rultempajn dependecojn en ujon, Docker igas la aplikaĵon interŝanĝeblan unuon kiu povas esti gastigita kaj rulita ie ajn. Samtempe ĝi multe simpligas operacion plurlingva Stako: Ĉar ujo estas atomunuo de ekzekuto, por deplojo kaj funkciaj celoj, ne gravas kio estas ene, ĉu ĝi estas JVM, Node, Go, Python aŭ Ruby-aplikaĵo. Vi nur lanĉas ĝin kaj jen ĝi.
Kubernetes portas ĉion al la sekva nivelo. Nun, ke ekzistas tunoj da "aĵoj por ruli" kaj tunoj da maŝinoj por ruli ilin, estas bezono de ilo kiu povas korelacii ilin unu kun la alia. En larĝa signifo, vi donas al Kubernetes multajn ujojn kaj multajn maŝinojn, kaj ĝi mapas ilin unu kontraŭ la alia (kompreneble, tio estas dinamika kaj ĉiam ŝanĝiĝanta procezo: novaj ujoj moviĝas ĉirkaŭ la sistemo, maŝinoj startas kaj haltas. , ktp. Tamen, Kubernetes konsideras ĉion ĉi ).
Post kiam Kubernetes estas agordita, la tempokosto por disfaldi kaj funkciigi unu servon malmulte diferencas de la kosto por disfaldi kaj funkciigi dek servojn (fakte, ĝi estas preskaŭ la sama por 100 servoj). Aldonu al ĉi tio ujojn kiel pakaĵan mekanismon, kiu instigas plurlingvan efektivigon, kaj vi havas amason da novaj aplikoj efektivigitaj en formo de mikroservoj skribitaj en malsamaj lingvoj - ĝuste la speco de medio, por kiu servomaŝo estas tiel bone taŭga.
Do ni venas al la respondo al la demando, kial la ideo de servo-maŝo fariĝis populara nun: la homogeneco, kiun Kubernetes provizas por servoj, rekte aplikas al la funkciaj defioj alfrontantaj servo-reto. Vi pakas la prokurojn en ujojn, donas al Kubernetes la taskon alglui ilin kie ajn ĝi povas, kaj voila! Kiel rezulto, vi ricevas servomaŝon, dum ĉiuj mekanikoj de ĝia deplojo estas administritaj de Kubernetes. (Almenaŭ el birda vido. Kompreneble, estas multaj nuancoj al ĉi tiu procezo.)
Resume: la kialo, ke la servomaŝoj populariĝis nun, kaj antaŭ ne dek jaroj, estas, ke Kubernetes kaj Docker ne nur signife pliiĝis. bezonas en ĝi, simpliginte la efektivigon de aplikoj kiel aroj de plurlingvaj mikroservoj, sed ankaŭ signife reduktita kostoj por ĝia operacio, disponigante mekanismojn por deploji kaj subtenante kromĉarajn prokurflotojn.
Kial oni tiom parolas pri servomaŝo?
Предупреждение: En ĉi tiu sekcio mi uzas ĉiajn supozojn, konjektojn, elpensaĵojn kaj internajn informojn.
Serĉu "servan maŝon" kaj vi trovos multon da reciklita malkaloria enhavo, strangajn projektojn kaj kalejdoskopon de distordo inda je eĥa ĉambro. Ajna nova teknologio faras tion, sed en la kazo de servomaŝo la problemo estas aparte akra. Kial?
Nu, parto de ĝi estas mia kulpo. Mi multe laboris por promocii Linkerd kaj la servan mesh ĉiun ŝancon, kiun mi ricevas per sennombraj blogaj afiŝoj kaj artikoloj kiel ĉi tiu. Sed mi ne estas tiom potenca. Por vere respondi ĉi tiun demandon, ni devas iomete paroli pri la ĝenerala situacio. Kaj estas neeble paroli pri ĝi sen mencii unu projekton: estas malfermfonteca servomaŝo evoluigita kune fare de Google, IBM kaj Lyft.
(La tri firmaoj havas tre malsamajn rolojn: la implikiĝo de Lyft ŝajnas esti nur en nomo; ili estas la verkintoj de Envoy, sed ne uzas aŭ partoprenas en la evoluo de Istio. IBM estas implikita en kaj uzas la evoluon de Istio. Guglo estas aktive implikita en la evoluo de Istio. evoluo , sed fakte ne uzas ĝin laŭ mia opinio.)
La projekto Istio estas rimarkinda pro du aferoj. Unue, estas la enorma merkatika penado, kiun Guglo, precipe, faras por reklami ĝin. Mi taksus, ke la plej multaj homoj konsciaj pri la servo-maŝo-koncepto hodiaŭ unue lernis pri ĝi per Istio. La dua afero estas kiom malbone akceptita Istio estis. En ĉi tiu afero, mi evidente estas interesita, sed provante resti kiel eble plej objektiva, mi ankoraŭ ne povas helpi , ne tre distinga (kvankam ne unika: systemd venas al la menso, ...) por Open Source projekto.
(Praktike, Istio ŝajnas havi problemojn ne nur pri komplekseco kaj UX, sed ankaŭ pri rendimento. Ekzemple, dum En triaparta studo, esploristoj trovis situaciojn en kiuj la vosta latenteco de Istio estis 100 fojojn pli alta ol tiu de Linkerd, same kiel resursmalsatajn situaciojn kie Linkerd daŭre funkciis sukcese dum Istio ĉesis funkcii tute.)
Forlasante miajn teoriojn pri kial tio okazis, mi kredas, ke la superforta ekscito ĉirkaŭ la servomaŝo estas klarigita per la partopreno de Guglo. Nome, kombinaĵo de la sekvaj tri faktoroj:
- La trudema reklamado de Guglo de Istio;
- responda malaproba, kritika sinteno al la projekto;
- la lastatempa meteika pliiĝo de populareco de Kubernetes, kies memoroj estas ankoraŭ freŝaj.
Kune ĉi tiuj faktoroj kombinas por krei mirindan, senoksigenan medion en kiu la kapablo por racia juĝo estas malfortigita, kaj nur la stranga vario restas. .
El la perspektivo de Linkerd, ĉi tio estas... kion mi priskribus kiel miksitan benon. Mi volas diri, estas bonege, ke servomaŝo eniris la ĉeftendencon tiel, kiel ĝi ne faris en 2016 kiam Linkerd unue komenciĝis kaj estis vere malfacile igi homojn atenti la projekton. Nun tia problemo ne ekzistas! Sed la malbona novaĵo estas, ke la serva maŝo-pejzaĝo estas tiom konfuza hodiaŭ, ke estas preskaŭ neeble kompreni, kiuj projektoj efektive apartenas al la serva maŝo-kategorio (ne parolu kompreni, kiu estas plej taŭga por aparta uzokazo). Ĉi tio certe estas interkonsento por ĉiuj (kaj certe estas iuj kazoj kie Istio aŭ alia projekto pli taŭgas ol Linkerd, ĉar ĉi-lasta ankoraŭ ne estas universala solvo).
Flanke de Linkerd, nia strategio estis ignori la bruon, daŭre koncentriĝi pri solvado de realaj komunumaj problemoj, kaj esence atendi ke la ekzaltiĝo formortos. Finfine, la ekzaltiĝo trankviliĝos kaj ni povas daŭrigi labori trankvile.
Intertempe ni ĉiuj devos iom pacienci.
Ĉu servomaŝo estos utila al mi, humila programaro-inĝeniero?
La sekva demandaro helpos vin respondi ĉi tiun demandon:
Ĉu vi nur okupiĝas pri efektivigado de komerca logiko? En ĉi tiu kazo, la servo maŝo ne estos utila al vi. Tio estas, kompreneble, ke vi eble interesiĝos pri ĝi, sed ideale la servomaŝo ne rekte tuŝu ion en via medio. Daŭre laboru pri tio, por kio vi estas pagita.
Ĉu vi subtenas la platformon ĉe kompanio, kiu uzas Kubernetes? Jes, ĉi-kaze vi bezonas servomaŝon (krom se, kompreneble, vi uzas K8s nur por ruli monoliton aŭ grupan prilaboradon - sed tiam mi ŝatus demandi kial vi bezonas K8s). Vi verŝajne finos kun multaj mikroservoj skribitaj de malsamaj homoj. Ili ĉiuj interagas unu kun la alia kaj estas ligitaj en miksaĵon de rultempaj dependecoj, kaj vi devas trovi manieron trakti ĉion. Uzante Kubernetes ebligas al vi elekti servomaŝon "por vi mem". Por fari tion, familiariĝu kun iliaj kapabloj kaj funkcioj kaj respondu la demandon ĉu iu el la disponeblaj projektoj taŭgas por vi (mi rekomendas komenci vian esploradon kun Linkerd).
Ĉu vi estas platforma kompanio ĉe kompanio, kiu NE uzas Kubernetes sed uzas mikroservojn? En ĉi tiu kazo, servo maŝo estos utila al vi, sed ĝia uzo estos ne-banala. Kompreneble vi povas imiti labora servo mesh metante amason da prokuriloj, sed grava avantaĝo de Kubernetes estas la deploja modelo: permane konservi ĉi tiujn prokurojn postulos multe pli da tempo, peno kaj elspezo.
Ĉu vi respondecas pri la platformo en kompanio, kiu laboras kun monolitoj? En ĉi tiu kazo, vi verŝajne ne bezonas servomaŝon. Se vi laboras kun monolitoj (aŭ eĉ kolektoj de monolitoj) kiuj havas bone difinitajn kaj malofte ŝanĝantajn interagajn ŝablonojn, tiam servo maŝo havos malmulton por oferti al vi. Do vi povas simple ignori ĝin kaj esperi, ke ĝi malaperos kiel malbona sonĝo...
konkludo
Verŝajne, servo-maŝo ankoraŭ ne devus esti nomita "la plej fama teknologio en la mondo" - ĉi tiu dubinda honoro verŝajne apartenas al Bitcoin aŭ AI. Ŝi verŝajne estas en la unuaj kvin. Sed se vi tratranĉas la tavolojn de bruo, evidentiĝas, ke la servomaŝo alportas realajn avantaĝojn al tiuj, kiuj konstruas aplikojn sur Kubernetes.
Mi ŝatus, ke vi provu Linkerd - instali ĝin sur Kubernetes-grupo (aŭ eĉ Minikube sur tekkomputilo) , kaj vi mem povas vidi pri kio mi parolas.
Oftaj Demandoj
— Se mi ignoras la servomaŝon, ĉu ĝi malaperos?
— Mi devas seniluziigi vin: servo mesh estas ĉe ni delonge.
- Sed mi NE VOLAS uzi servomaŝon!
- Nu, ne necesas! Nur legu mian demandaron supre por kompreni ĉu vi almenaŭ devus konatiĝi kun ĝiaj bazaĵoj.
— Ĉu ĉi tiu ne estas bona malnova ESB/mezaĵo kun nova saŭco?
— Servomaŝo traktas operacian logikon, ne semantikan. entreprena servobuso (). Konservi ĉi tiun disigon helpas la servomaŝon eviti la saman sorton.
— Kiel serva maŝo diferencas de API-enirejoj?
— Estas miliono da artikoloj pri ĉi tiu temo. Nur Google ĝin.
— Sendito estas servomaŝo?
- Ne, Envoy ne estas servomaŝo, ĝi estas prokura servilo. Ĝi povas esti uzata por organizi servomaŝon (kaj multe pli - ĝi estas ĝenerala celo prokurilo). Sed en si mem ĝi ne estas servomaŝo.
— Network Service Mesh estas servomaŝo?
- Ne. Malgraŭ la nomo, ĉi tio ne estas servomaŝo (kiel vi ŝatas merkatajn miraklojn?).
— Ĉu servo maŝo helpos kun mia mesaĝvico-bazita reaktiva nesinkrona sistemo?
- Ne, servo maŝo ne helpos vin.
— Kiun servomaŝon mi uzu?
- , neniu cerbumo.
— La artikolo fias! / La aŭtoro estas bonvena!
— Bonvolu dividi la ligilon al ĝi kun ĉiuj viaj amikoj, por ke ili povu vidi ĝin!
Dankoj
Kiel vi eble divenis el la titolo, ĉi tiu artikolo estis inspirita de la mirinda traktaĵo de Jay Kreps "" Mi renkontis Jay antaŭ dek jaroj kiam mi intervjuis lin ĉe Linked In kaj li estis inspiro por mi ekde tiam.
Dum mi ŝatas nomi min "Linkerd-programisto", la realeco estas, ke mi estas pli prizorganto de la dosiero README.md en projekto. Linkerd estas prilaborata hodiaŭ , , homoj, kaj ĉi tiu projekto ne estus okazinta sen la partopreno de mirinda komunumo de kontribuantoj kaj uzantoj.
Kaj finfine, specialan dankon al la kreinto de Linkerd, (primus inter pares), kiu kune kun mi antaŭ multaj jaroj plonĝis kapantaŭen en ĉi tiun tutan tumulton kun servomaŝo.
PS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com