Athugið. þýð.: Þjónustunet er fyrirbæri sem hefur ekki enn stöðuga þýðingu á rússnesku (fyrir meira en 2 árum buðum við upp á valkostinn „möskva fyrir þjónustu“ og nokkru síðar fóru sumir samstarfsmenn að kynna samsetninguna „þjónustusigti“ virkan). . Stöðugt tal um þessa tækni hefur leitt til þess að markaðssetning og tæknilegir þættir eru of nátengdir. Þetta dásamlega efni frá einum af höfundum upprunalega hugtaksins er ætlað að gera verkfræðingum skýrleika en ekki aðeins.
Teiknimynd frá
Inngangur
Ef þú ert hugbúnaðarverkfræðingur sem vinnur einhvers staðar á sviði bakendakerfa hefur hugtakið „þjónustunet“ líklega þegar fest sig í sessi í huga þínum undanfarin ár. Þökk sé undarlegri tilviljun er þessi setning að taka yfir iðnaðinn í auknum mæli og efla og tengd kynningartilboð stækka eins og snjóbolti, fljúga niður brekkuna og sýna engin merki um að hægt sé.
Þjónustunetið fæddist í gruggugu, tilhneigingu vatni hins skýjaða vistkerfis. Því miður þýðir þetta að mikið af deilunni í kringum það spannar allt frá „kaloríusnauðri þvaður“ til — til að nota tæknilega hugtakið — hreint kjaftæði. En ef þú síar út allan hávaðann geturðu komist að því að þjónustunetið hefur mjög raunverulega, ákveðna og mikilvæga virkni.
Í þessari færslu mun ég reyna að gera einmitt það: veita heiðarlega, ítarlega, verkfræðingamiðaða leiðbeiningar um þjónustunetið. Ég ætla að svara fleiru en spurningunni: "Hvað það er?", - en einnig "Af hverju?"Og "Af hverju núna?". Að lokum ætla ég að reyna að útskýra hvers vegna (að mínu mati) þessi tiltekna tækni hefur valdið svona brjálæðislegu hype, sem í sjálfu sér er áhugaverð saga.
Hver er ég?
Hæ allir! Ég heiti . Ég er einn af höfundunum - allra fyrsta þjónustumöskvaverkefnið og verkefninu sem er um að kenna útliti hugtaksins þjónustunet sem slík (fyrirgefðu krakkar!). (Athugið þýðing.: Við the vegur, í dögun útlits þessa hugtaks, fyrir meira en 2,5 árum síðan, þýddum við þegar snemma efni sama höfundar sem heitir "".) Ég leiða líka er gangsetning sem smíðar flotta þjónustumesh hluti eins og Linkerd og .
Þú getur sennilega giskað á að ég hafi mjög hlutdræga og huglæga skoðun á þessu máli. Hins vegar mun ég reyna að halda hlutdrægni í lágmarki (að undanskildum einum kafla: "Af hverju er svona mikið talað um þjónustunetið?", - þar sem ég mun engu að síður deila fyrirframgefnum hugmyndum mínum). Ég mun líka gera mitt besta til að gera þessa handbók eins hlutlægan og mögulegt er. Í sérstökum dæmum mun ég aðallega treysta á reynslu Linkerd, en benda á þann mun (ef einhver er) sem ég veit um í útfærslu annarra tegunda þjónustumöskva.
Allt í lagi, það er kominn tími til að halda áfram að skemmtuninni.
Hvað er þjónustunet?
Þrátt fyrir allt efla, þjónustunetið er uppbygging frekar einfalt. Þetta er bara fullt af notendarýmisumboðum sem staðsettir eru "við hliðina á" þjónustu (við munum tala aðeins um "nálægt" síðar), auk setts af stjórnunarferlum. Umboðsmenn eru kallaðir sameiginlega gagnaplan, og eftirlitsferlarnir eru kallaðir stjórn flugvél. Gagnaflugvélin hlerar símtöl á milli þjónustu og gerir „allt annað“ við þær; stýriplanið, í sömu röð, samhæfir hegðun umboðsins og veitir þér aðgang, þ.e. rekstraraðila, við API, sem gerir kleift að vinna með netið og mæla það í heild sinni.
Hvað er þetta umboð? Þetta er TCP umboð í flokknum „Layer 7-aware“ (þ.e. "að taka tillit til" 7. lags OSI líkansins) eins og HAProxy og NGINX. Þú getur valið umboð að vild; Linkerd notar Rust proxy, óbrotið nefnt . Við höfum tekið það saman sérstaklega fyrir þjónustunetið. Aðrir möskva kjósa aðra umboð (Envoy er algengur kostur). Hins vegar er það bara spurning um útfærslu að velja umboð.
Hvað gera þessir proxy-þjónar? Augljóslega eru þeir umboðssímtöl til og frá þjónustu (strangt tiltekið, þeir virka sem umboð og andstæða umboð, meðhöndla bæði inn- og útsímtöl). Og þeir innleiða eiginleikasett sem einbeitir sér að símtölum между þjónusta. Þessi áhersla á umferð á milli þjónustu er það sem aðgreinir þjónustumöskva umboð frá td API gáttum eða inngönguumboðum (síðarnefndu einbeitir sér að símtölum sem koma inn í þyrpinguna frá umheiminum). (Athugið. þýð.: Fyrir samanburð á núverandi Kubernetes Ingress stýringar, sem margir hverjir nota áðurnefndan sendifulltrúa, sjá .)
Svo við komumst að gagnaplaninu. Stýriplanið er einfaldara: það er sett af íhlutum sem veita alla aflfræði sem gagnaflugvélin þarf til að virka á samræmdan hátt, þar á meðal þjónustuuppgötvun, TLS vottorðsútgáfu, mælikvarðasöfnun osfrv. Gagnaplanið upplýsir stjórnvélina um hegðun þess; aftur á móti veitir stjórnplanið API sem gerir þér kleift að breyta og fylgjast með hegðun gagnaplansins í heild sinni.
Hér að neðan er skýringarmynd af stjórnplaninu og gagnaplaninu í Linkerd. Eins og þú sérð inniheldur stjórnplanið nokkra mismunandi íhluti, þar á meðal Prometheus tilvik sem safnar mælingum frá proxy-þjónum, auk annarra íhluta eins og destination (þjónustuuppgötvun), identity (vottorðsyfirvald, CA) og public-api (endapunktar fyrir vef og CLI). Aftur á móti er gagnaplanið einfalt tengt umboð við hlið forritatilviksins. Þetta er bara rökfræðileg skýringarmynd; í raunverulegri uppsetningu gætirðu haft þrjár eftirlíkingar af hverjum íhluta stjórnflugvélarinnar og hundruð eða þúsundir umboðsmanna í gagnaplaninu.
(Bláu reitirnir á þessari skýringarmynd tákna landamæri Kubernetes fræbelgjana. Þú getur séð að ílátin með linked-proxy eru í sama belg og forritsílátin. Þetta kerfi er þekkt sem hliðarvagnagámur.)
Þjónustunetsarkitektúrinn hefur nokkra mikilvæga þýðingu. Í fyrsta lagi, þar sem starf umboðsmanns er að hlera símtöl á milli þjónustu, er þjónustunet aðeins skynsamlegt ef forritið þitt var byggt fyrir mengi þjónustu. möskva maður getur nota með einlitum, en þetta er greinilega óþarfi vegna eins umboðs og ólíklegt er að virkni þess sé eftirsótt.
Önnur mikilvæg afleiðing er sú að þjónustunetið krefst risastórt fjölda umboðsmanna. Í raun, Linkerd keðjur linked-proxy við hvert tilvik af hverri þjónustu (aðrar útfærslur bæta umboði við hvern gestgjafa/hýsil/VM. Það er mikið samt). Slík virk notkun umboðs hefur í för með sér fjölda viðbótar fylgikvilla:
- Umboðsmenn í gagnaplaninu ættu að vera hratt, vegna þess að fyrir hvert símtal eru nokkur símtöl til umboðsins: eitt á biðlarahlið, eitt á miðlarahlið.
- Einnig verða umboð að vera lítill и léttur. Hver mun neyta minnis- og örgjörvaauðlinda og þessi neysla mun vaxa línulega með forritinu.
- Þú þarft kerfi til að dreifa og uppfæra fjölda umboða. Að gera það handvirkt er ekki valkostur.
Almennt séð lítur þjónustunetið svona út (a.m.k. frá fuglasjónarmiði): þú setur upp fullt af notendarýmisumboðum sem "gera eitthvað" með innri, milliþjónustuumferð, og notar stjórnplanið til að fylgjast með og stjórna þeim.
Það er kominn tími á spurninguna "Af hverju?"
Til hvers er þjónustunet?
Fyrir þá sem fyrst kynntust hugmyndinni um þjónustunet, þá er það fyrirgefanlegt að vera svolítið agndofa. Þjónustunetshönnunin þýðir að það mun ekki aðeins auka biðtíma forrita, heldur mun það líka neyta auðlindir og mun bæta við fullt af nýjum aðferðum í innviðum. Fyrst seturðu upp þjónustunet, og svo finnurðu skyndilega að þú þarft að þjóna hundruðum (ef ekki þúsundum) umboðsmanna. Spurningin er hver mun bjóða sig fram í þessu?
Svarið við þessari spurningu hefur tvo hluta. Í fyrsta lagi er hægt að draga verulega úr viðskiptakostnaði sem tengist uppsetningu þessara umboða vegna nokkurra breytinga sem eiga sér stað í vistkerfinu (meira um þetta síðar).
Í öðru lagi er slíkt tæki í raun frábær leið til að koma viðbótarrökfræði inn í kerfið. Og ekki aðeins vegna þess að hægt er að bæta við mörgum nýjum eiginleikum með því að nota þjónustunetið, heldur líka vegna þess að það er hægt að gera það án þess að trufla vistkerfið. Reyndar er allt þjónustunetslíkanið byggt á þessari forsendu: í fjölþjónustukerfi, sama hvað gera einstaklingsþjónusta, umferð milli þeirra er kjörinn punktur til að bæta við virkni.
Til dæmis, í Linkerd (eins og í flestum möskva) beinist virkni fyrst og fremst að HTTP símtölum, þar á meðal HTTP/2 og gRPC*. Virknin er nokkuð rík - henni má skipta í þrjá flokka:
- Tengdir eiginleikar áreiðanleiki. Reyndu aftur beiðnir, tímamörk, kanarí aðflug (umferðarskipting/framvísun) o.s.frv.
- Tengdir eiginleikar eftirlit. Söfnun árangurshlutfalls, tafa og beiðnamagns fyrir hverja þjónustu eða einstaka áfangastaði; smíði staðfræðileg kort af þjónustu o.fl.
- Tengdir eiginleikar öryggi. Gagnkvæm TLS, aðgangsstýring o.fl.
* Frá sjónarhóli Linkerd er gRPC nánast ekkert frábrugðið HTTP/2: það notar bara protobuf í hleðslunni. Frá sjónarhóli þróunaraðila eru þessir tveir hlutir auðvitað ólíkir.
Mörg þessara aðferða starfa á beiðnistigi (þess vegna "L7 umboðið"). Til dæmis, ef þjónusta Foo hringir í HTTP símtal til þjónustustikunnar, getur linked-proxy hlið Foo hlaðið álagsjafnvægi á skynsamlegan hátt og vísað símtölum frá Foo til Bar tilvikum byggt á leynd sem sést; það getur endurtekið beiðnina ef nauðsyn krefur (og ef hún er veikburða); hann getur skráð svarkóðann og tímamörk og svo framvegis. Á sama hátt getur linked-umboðið á Bar-hliðinni hafnað beiðni ef það er ekki leyft eða ef farið er yfir beiðnirmörkin; getur lagað seinkunina af sinni hálfu o.s.frv.
Umboðsmenn geta líka „gert eitthvað“ á tengingarstigi. Til dæmis getur tengt umboð á Foo hliðinni komið af stað TLS tengingu, og tengt umboð á Bar hliðinni getur lokað henni og báðar hliðar geta sannreynt TLS vottorð hvors annars*. Þetta veitir ekki aðeins dulkóðun á milli þjónustu, heldur einnig dulmálslega örugga leið til að bera kennsl á þjónustu: Foo og Bar geta "sannað" að þeir séu þeir sem þeir segjast vera.
* „Vinur vinar“ þýðir að vottorð viðskiptavinar er einnig staðfest (gagnkvæm TLS). Í „klassískum“ TLS, til dæmis, á milli vafra og netþjóns, er vottorð aðeins annarrar hliðar (þjónsins) venjulega staðfest.
Hvort sem þeir starfa á beiðni- eða tengingarstigi, er mikilvægt að leggja áherslu á að allir þjónustumöskvaeiginleikar séu það rekstrarhæft karakter. Linkerd getur ekki umbreytt merkingarfræði farmsins, eins og að bæta sviðum við JSON brot eða gera breytingar á frumefni. Við munum tala um þennan mikilvæga eiginleika síðar þegar við tölum um ESB og millihugbúnað.
Þetta er safn eiginleika sem þjónustunetið býður upp á. Spurningin vaknar: af hverju ekki að innleiða þau beint í umsókninni? Og hvers vegna að skipta sér af umboði yfirleitt?
Hvers vegna þjónustunet er góð hugmynd
Þó að hæfileikar þjónustunetsins séu grípandi, liggur aðalgildi þess í raun ekki í eiginleikum. Að lokum við Dós innleiða þau beint í forritinu (síðar munum við sjá að þetta var uppruni þjónustunetsins). Til að setja það í eina setningu er gildi þjónustunets: það býður upp á virkni sem er mikilvæg til að keyra nútíma netþjónahugbúnað á samræmdan, allan stafla, forritakóða-agnostískan hátt.
Við skulum greina þessa tillögu.
«Aðgerðir sem eru mikilvægar til að keyra nútíma netþjónahugbúnað". Ef þú ert að byggja viðskiptamiðlaraforrit sem er tengt við almenna internetið sem tekur við beiðnum frá umheiminum og svarar þeim innan skamms tíma - til dæmis vefforrit, API netþjón og langflest önnur nútíma forrit - og ef þú innleiðir það sem safn af þjónustu sem hefur samstillt samskipti sín á milli, og ef þú ert stöðugt að uppfæra þennan hugbúnað, bæta við nýjum eiginleikum og ef þú neyðist til að halda þessu kerfi í virku ástandi meðan á breytingarferlinu stendur - í þessu tilviki, til hamingju, þú ert að búa til nútíma netþjónahugbúnað. Og allir þessir frábæru eiginleikar sem taldir eru upp hér að ofan reynast þér í raun mikilvægir. Forritið verður að vera áreiðanlegt, öruggt og þú verður að geta séð hvað það er að gera. Það eru þessar spurningar sem þjónustunetið hjálpar til við að leysa.
(Allt í lagi, sannfæring mín um að þessi nálgun sé nútímaleg leið til að byggja upp netþjónahugbúnað hefur smeygt sér inn í fyrri málsgrein. Aðrir kjósa að þróa monolith, "reactive microservices" og annað sem fellur ekki undir skilgreininguna hér að ofan. Þetta fólk hefur líklega skoðun sem er frábrugðið mínum, og aftur á móti tel ég að þeir séu "rangir" - þó að þjónustunetið sé í öllum tilvikum ekki mjög gagnlegt fyrir þá).
«Samræmd fyrir allan stafla". Eiginleikar þjónustunetsins eru ekki bara mikilvægir. Þær eiga við um alla þjónustu í forriti, óháð því á hvaða tungumáli hún er skrifuð, hvaða ramma þær nota, hver skrifaði þær, hvernig þær voru notaðar og allar aðrar fíngerðir í þróun þeirra og notkun.
«Umsóknarkóði óháður". Að lokum veitir þjónustunetið ekki aðeins samræmda virkni yfir allan stafla, það gerir það á þann hátt að ekki þarf að breyta forritinu. Grundvallargrundvöllur virkni þjónustunets, þ.mt verkefnin við að stilla, uppfæra, reka, viðhalda osfrv., er eingöngu á vettvangsstigi og er óháð forritinu. Forritið getur breyst án þess að hafa áhrif á þjónustunetið. Aftur á móti getur þjónustunetið breyst án nokkurrar afskipta af forritinu.
Í stuttu máli, þjónustunetið veitir ekki aðeins mikilvæga virkni heldur gerir það það á alþjóðlegan, samræmdan og umsóknaróháðan hátt. Og svo, þó að hægt sé að útfæra virkni þjónustunets í þjónustukóðann (til dæmis sem bókasafn sem fylgir hverri þjónustu), mun þessi nálgun ekki veita þá einsleitni og sjálfstæði sem er svo dýrmætt þegar um þjónustunet er að ræða. .
Og allt sem þú þarft að gera er að bæta við fullt af umboðum! Ég lofa, mjög fljótlega munum við skoða rekstrarkostnaðinn sem fylgir því að bæta við þessum umboðum. En fyrst skulum við staldra við og skoða þessa hugmynd um sjálfstæði frá sjónarhóli ýmissa fólk.
Hverjum hjálpar þjónustunetið?
Eins óþægilegt og það kann að vera, til þess að tækni geti orðið mikilvægur hluti af vistkerfinu, verður hún að vera samþykkt af fólki. Svo hver hefur áhuga á þjónustuneti? Hver hagnast á notkun þess?
Ef þú þróar nútíma netþjónahugbúnað geturðu í grófum dráttum ímyndað þér liðið þitt sem hóp þjónustueigendursem saman þróa og innleiða viðskiptarökfræði, og pallaeigendurþátt í þróun innri vettvangsins sem þessi þjónusta keyrir á. Í litlum stofnunum getur þetta verið sama fólkið, en eftir því sem fyrirtækið stækkar hafa þessi hlutverk tilhneigingu til að verða meira áberandi og jafnvel skipt í undirhlutverk ... (Hér er margt að segja um breytilegt eðli devops, skipulagsáhrif örþjónustu o.s.frv.) n. En í bili skulum við taka þessar lýsingar sem sjálfsögðum hlut).
Frá þessu sjónarhorni eru skýrir notendur þjónustunetsins eigendur pallsins. Þegar öllu er á botninn hvolft er lokamarkmið vettvangsteymis að búa til innri vettvang þar sem þjónustueigendur geta innleitt viðskiptarökfræði og gert það á þann hátt sem tryggir hámarks sjálfstæði þeirra frá ljótum smáatriðum starfseminnar. Þjónustunetið býður ekki aðeins upp á hæfileikana sem eru mikilvægir til að ná þessu markmiði, það gerir það á þann hátt sem aftur á móti setur enga ósjálfstæði á þjónustueigendur.
Þjónustueigendur hagnast líka, þó með óbeinum hætti. Markmið þjónustueiganda er að vera eins afkastamikill og hægt er við að innleiða rökfræði viðskiptaferlisins og því minni sem hann þarf að hafa áhyggjur af rekstrarlegum málum, því betra. Í stað þess að framfylgja, segjum, endurreyna stefnur eða TLS, geta þeir einbeitt sér eingöngu að fyrirtækinu og vona að vettvangurinn sjái um afganginn. Fyrir þá er þetta stór kostur.
Skipulagsgildi slíkrar skiptingar milli eigenda palla og þjónustu verður ekki ofmetið. Ég held að hún leggi sitt af mörkum Helstu framlag til verðmæti þjónustunetsins.
Við lærðum þessa lexíu þegar aðdáandi Linkerd sagði okkur hvers vegna þeir völdu þjónustunetið: vegna þess að það gerði þeim kleift að „halda áfram að tala í lágmarki“. Hér eru nokkrar upplýsingar: krakkar frá einu stóru fyrirtæki fluttu vettvang sinn til Kubernetes. Þar sem forritið vann með viðkvæmar upplýsingar vildu þeir dulkóða öll samskipti í þyrpingunum. Hins vegar var ástandið flókið vegna nærveru hundruða þjónustu og hundruð þróunarteyma. Möguleikarnir á að hafa samband við alla og sannfæra þá um að hafa stuðning við TLS í áætlunum sínum gladdi þá alls ekki. Með því að setja upp Linkerd fluttu þeir ábyrgð frá þróunaraðilum (frá hverra sjónarhorni var það óþarfa vandræði) til vettvangsspilara, fyrir hverja þetta var forgangsverkefni. Með öðrum orðum, Linkerd var að leysa fyrir þá ekki svo mikið tæknilegt vandamál heldur skipulagsvandamál.
Í stuttu máli er þjónustunetið frekar ekki tæknileg lausn, heldur félags-tæknileg Vandamál. (Þakka þér fyrir fyrir að kynna þetta kjörtímabil.
Mun þjónustunetið leysa öll vandamál mín?
Já. Ég meina, nei!
Þegar litið er á þrjá flokka eiginleika sem lýst er hér að ofan - áreiðanleiki, öryggi og athuganleiki - verður ljóst að þjónustunetið er ekki fullkomin lausn á neinu af þessum vandamálum. Þrátt fyrir að Linkerd geti sent endurteknar beiðnir (ef það veit að þær eru vanmáttar), þá er það ekki í aðstöðu til að taka ákvarðanir um hverju á að skila til notandans ef þjónustan hefur endanlega hætt - slíkar ákvarðanir verða að vera teknar af umsókninni. Linkerd getur haldið tölfræði um árangursríkar beiðnir, en það er ekki fær um að skoða þjónustuna og veita innri mælikvarða hennar - forrit ætti að hafa slíkt verkfærasett. Og þó að Linkerd sé fær um að hýsa mTLS, krefjast fullgildar öryggislausnir miklu meira.
Hlutmengi eiginleika á þessum svæðum sem þjónustunetið býður upp á tengist vettvangseiginleikar. Með þessu á ég við aðgerðir sem:
- Óháð viðskiptarökfræði. Leiðin sem símtölur eru smíðuð á milli Foo og Bar er algjörlega óháð því hvort hvers vegna Foo hringir í Bar.
- Erfitt að útfæra rétt. Í Linkerd eru endurtilraunir stilltar með alls kyns fínu efni eins og fjárhagsáætlunum fyrir endurtekningar. (reyna aftur fjárhagsáætlun), þar sem einfaldur nálgun við framkvæmd slíkra hluta mun vafalaust leiða til þess að svokallað "snjóflóð beiðna" komi upp (reyna aftur storm) og önnur vandamál sem tengjast dreifðum kerfum.
- Áhrifaríkasta þegar það er notað stöðugt. TLS vélbúnaðurinn er aðeins skynsamlegur ef hann er notaður alls staðar.
Vegna þess að þessir eiginleikar eru útfærðir á umboðslaginu (en ekki á forritalaginu), afhjúpar þjónustunetið þá á pallur, ekki forrit. Þannig skiptir ekki máli á hvaða tungumáli þjónusturnar eru skrifaðar, hvaða ramma þær nota, hver skrifaði þær og hvers vegna. Umboðsmenn vinna umfram allar þessar upplýsingar og grundvallargrundvöllur þessarar virkni, þar á meðal verkefnin við að stilla, uppfæra, reka, viðhalda osfrv., liggur eingöngu á vettvangsstigi.
Dæmi um getu þjónustunets
Í stuttu máli, þjónustunet er ekki heildarlausn fyrir áreiðanleika, athuganleika eða öryggi. Umfang þessara svæða felur í sér lögboðna þátttöku þjónustueigenda, Ops / SRE teyma og annarra hagsmunaaðila fyrirtækisins. Þjónustunetið veitir aðeins „sneið“ á vettvangsstigi fyrir hvert þessara svæða.
Hvers vegna hefur þjónustunetið orðið vinsælt núna?
Þú ert líklega að velta því fyrir þér núna: Allt í lagi, ef þjónustunetið er svona gott, hvers vegna byrjuðum við ekki að dreifa milljónum umboðsmanna á staflanum fyrir tíu árum?
Það er banalt svar við þessari spurningu: fyrir tíu árum byggðu allir einlita og enginn þurfti þjónustunet. Þetta er rétt, en að mínu mati missir þetta svar marks. Jafnvel fyrir tíu árum síðan var hugmyndin um örþjónustu sem vænlega leið til að búa til stórfelld kerfi til umræðu og beitt í fyrirtækjum eins og Twitter, Facebook, Google og Netflix. Almenna viðhorfið - að minnsta kosti í þeim hlutum iðnaðarins sem ég hef verið í sambandi við - var að örþjónusta væri „rétta leiðin“ til að byggja upp stór kerfi, jafnvel þótt það væri fjandi erfitt.
Auðvitað, þó að það væru fyrirtæki sem nýttu sér smáþjónustu fyrir tíu árum síðan, festu þau ekki umboð alls staðar sem þau gátu til að mynda þjónustunet. Hins vegar, ef þú lítur vel, gerðu þeir eitthvað svipað: mörg þessara fyrirtækja skyldu nota sérstakt innra bókasafn fyrir netkerfi (stundum kallað feita viðskiptavinasafnið, feitur viðskiptavinur bókasafn).
Netflix var með Hysterix, Google átti Stubby, Twitter var með Finagle bókasafnið. Finagle, til dæmis, hefur verið skylda fyrir hverja nýja þjónustu á Twitter. Það annaðist bæði biðlara- og netþjónahlið tenginganna, leyfði endurteknum beiðnum, studdu beiðnaleiðingu, álagsjafnvægi og mælingu. Það veitti stöðugt lag af áreiðanleika og sjáanleika yfir allan Twitter stafla, sama hvað þjónustan var að gera. Auðvitað virkaði það aðeins fyrir JVM tungumál og var byggt á forritunarlíkani sem þurfti að nota fyrir allt forritið. Hins vegar var virkni þess næstum sú sama og þjónustunetsins. (Reyndar var fyrsta útgáfan af Linkerd bara Finagle vafin inn í umboðsform.)
Þannig voru fyrir tíu árum ekki aðeins örþjónustur, heldur einnig sérstök frum-þjónustu-möskva bókasöfn sem leystu sömu vandamál og þjónustunetið leysir í dag. Hins vegar var þjónustunetið sjálft ekki til þá. Það varð að vera önnur vakt áður en hún birtist.
Og þetta er þar sem dýpri svarið liggur, falið í annarri breytingu sem hefur átt sér stað á undanförnum 10 árum: það hefur verið mikill samdráttur í kostnaði við að koma upp örþjónustu. Fyrirtækin sem nefnd eru hér að ofan sem notuðu örþjónustur fyrir áratug síðan - Twitter, Netflix, Facebook, Google - voru fyrirtæki í gríðarstórum stíl og mikið fjármagn. Þeir höfðu ekki aðeins þörfina heldur einnig getu til að smíða, dreifa og reka stór forrit byggð á örþjónustu. Orkan og fyrirhöfnin sem Twitter verkfræðingar hafa lagt í að færa sig úr einhæfri nálgun yfir í smáþjónustu er ótrúleg. (Heiðarlega, eins og sú staðreynd að það virkaði.) Svona innviðastjórnun var þá ómöguleg fyrir smærri fyrirtæki.
Færum okkur til nútímans. Í dag eru til sprotafyrirtæki þar sem hlutfall örþjónustu og þróunaraðila er 5:1 (eða jafnvel ), og þar að auki, þeir takast á við þau með góðum árangri! Ef 5 manna gangsetning er fær um að reka 50 örþjónustur án þess að þenjast, þá hefur eitthvað greinilega dregið úr kostnaði við innleiðingu þeirra.
1500 örþjónustur í Monzo; hver lína er ávísuð netregla sem leyfir umferð
Stórkostleg lækkun á kostnaði við rekstur örþjónustu er afleiðing af einu ferli: vaxandi vinsældir gáma и hljómsveitarstjórar. Þetta er einmitt djúpa svarið við spurningunni um hvað stuðlaði að tilkomu þjónustunetsins. Sama tækni gerði bæði þjónustunetið og örþjónustuna aðlaðandi: Kubernetes og Docker.
Hvers vegna? Jæja, Docker leysir eitt stórt vandamál - vandamálið við umbúðir. Með því að pakka forriti og (non-net) keyrslutímaháðum þess í gám, breytir Docker forritinu í breytilega einingu sem hægt er að hýsa og keyra hvar sem er. Á sama tíma einfaldar það reksturinn mjög. fjöltyngt stafla: Þar sem gámur er atómeining fyrir framkvæmd, skiptir ekki máli hvað er inni, hvort sem það er JVM, Node, Go, Python eða Ruby forrit, til dreifingar og rekstrar. Þú bara keyrir það og það er það.
Kubernetes tekur allt á næsta stig. Nú þegar það er fullt af "keyranlegum hlutum" og margar vélar til að keyra þá á, þá er þörf fyrir tól sem getur jafnað þá við hvert annað. Í víðum skilningi gefur þú Kubernetes marga gáma og margar vélar og það passar þá innbyrðis (auðvitað er þetta kraftmikið og stöðugt breytilegt ferli: nýir gámar fara um kerfið, vélar fara í gang og stoppa o.s.frv. Kubernetes tekur allt þetta með í reikninginn).
Þegar Kubernetes hefur verið sett upp er tíminn sem það tekur að dreifa og reka eina þjónustu ekki mikið frábrugðinn kostnaði við að dreifa og reka tíu þjónustur (reyndar er það nánast það sama fyrir 100 þjónustur). Bættu við þetta ílát sem pökkunarkerfi sem hvetur til fjöltyngdra innleiðingar, og þú ert með fullt af nýjum forritum útfærð sem örþjónustur skrifuð á mörgum tungumálum, einmitt þess konar umhverfi sem þjónustunetið hentar svo vel.
Svo komum við að svarinu við spurningunni um hvers vegna hugmyndin um þjónustunet hefur orðið vinsæl núna: einsleitnin sem Kubernetes veitir þjónustu á beint við um rekstrarverkefnin sem þjónustunetið stendur frammi fyrir. Þú pakkar umboðum í gáma, gefur Kubernetes það verkefni að festa þá hvar sem hægt er, og voila! Fyrir vikið færðu þjónustunet, á meðan Kubernetes stjórnar öllum vélbúnaði uppsetningar þess. (Að minnsta kosti frá sjónarhorni fugla. Auðvitað eru mörg blæbrigði í þessu ferli.)
Til að draga saman: ástæðan fyrir því að þjónustunetið varð vinsælt núna og ekki fyrir tíu árum síðan er sú að Kubernetes og Docker jukust ekki aðeins verulega þörf í því, einfaldar innleiðingu forrita sem sett af fjöltyngdri örþjónustu, en einnig verulega dregið úr kostnaður fyrir rekstur þess með því að útvega kerfi til að dreifa og viðhalda umboðsgörðum fyrir hliðarvagna.
Hvers vegna er svona mikið talað um þjónustunetið?
Viðvörun: Í þessum kafla gríp ég til alls kyns forsendna, getgáta, uppspuna og innherjaupplýsinga.
Leit að „þjónustuneti“ mun birta fullt af endurunnu, kaloríuinnihaldi, skrýtnum verkefnum og kaleidoscope af bjögun sem er verðugt bergmálshólf. Öll töff ný tækni hefur þetta, en þegar um er að ræða þjónustunetið er vandamálið sérstaklega bráð. Hvers vegna?
Jæja, það er að hluta til mér að kenna. Ég hef gert mitt besta til að kynna Linkerd og þjónustunetið við hvert tækifæri, í gegnum ótal bloggfærslur og greinar eins og þessa. En ég er ekki svo öflugur. Til að svara þessari spurningu í raun og veru þurfum við að tala aðeins um almennar aðstæður. Og það er ómögulegt að tala um það án þess að nefna eitt verkefni: er opinn uppspretta þjónustunet sem er þróað í sameiningu af Google, IBM og Lyft.
(Þessi þrjú fyrirtæki hafa mjög mismunandi hlutverk: Aðkoma Lyfts virðist takmarkast við nafnið eitt; þau skrifa Sendiherra en nota ekki eða taka þátt í þróun Istio. IBM tekur þátt í þróun Istio og notar það. Google er mjög mikið þátt í þróun Istio, en eftir því sem ég kemst næst, notar hann það ekki.)
Istio verkefnið er athyglisvert fyrir tvennt. Í fyrsta lagi er það hið mikla markaðsátak sem Google, sérstaklega, leggur í kynningu sína. Ég áætla að flestir sem eru meðvitaðir um þjónustunetshugmyndina hafi fyrst lært um það þökk sé Istio. Annað atriðið er hversu illa var tekið á móti Istio. Í þessu máli er ég augljóslega hagsmunaaðili, en að reyna að vera eins hlutlægur og mögulegt er get ég samt ekki annað en , ekki mjög sérstakur (þó ekki einstakt: systemd kemur upp í hugann, ...) fyrir Open Source verkefni.
(Í reynd virðist Istio eiga í vandræðum ekki aðeins með flækjustig og UX, heldur einnig með frammistöðu. Til dæmis, á meðan unnin af þriðja aðila, fundu sérfræðingar aðstæður þar sem töf Istio var 100 sinnum hærri en Linkerd, sem og aðstæður með skorti á fjármagni, þegar Linkerd hélt áfram að virka með góðum árangri og Istio hætti algjörlega að virka.)
Sé sleppt kenningum mínum um hvers vegna þetta gerðist, þá tel ég að efla utan mælikvarða í kringum þjónustunetið sé vegna þátttöku Google. Nefnilega sambland af eftirfarandi þremur þáttum:
- þráhyggju kynning á Istio af Google;
- viðeigandi vanþóknun, gagnrýnin afstaða til verkefnisins;
- miklar vinsældir Kubernetes að undanförnu, sem enn er í fersku minni.
Saman renna þessir þættir saman í eins konar vímuefni, anoxandi umhverfi þar sem getu til skynsamlegrar dómgreindar er veikt og aðeins dásamleg fjölbreytni er eftir. .
Frá sjónarhóli Linkerd er þetta... ég myndi lýsa því sem blendinni blessun. Ég meina, það er frábært að þjónustunetið sé komið inn í almenna strauminn - sem var ekki raunin árið 2016 þegar Linkerd kom fyrst fram og það var mjög erfitt að ná athygli fólks á verkefnið. Nú er ekkert slíkt vandamál! En slæmu fréttirnar eru þær að ástandið í þjónustumöskvunum er svo ruglingslegt í dag að það er næstum ómögulegt að átta sig á hvaða verkefni raunverulega tilheyra þjónustumöskvunum (hvað þá að finna út hver er bestur fyrir tiltekið notkunartilvik). Þetta kemur vissulega í veg fyrir alla (og örugglega í sumum tilfellum er Istio eða annað verkefni betra en Linkerd, þar sem hið síðarnefnda er ekki einhlít lausn).
Frá hlið Linkerd hefur stefna okkar verið að hunsa hávaðann, halda áfram að einbeita sér að því að leysa raunveruleg vandamál í samfélaginu og í rauninni bíða eftir að eflanir dvíni. Á endanum mun eflanir hjaðna og við getum haldið áfram að vinna í friði.
Þangað til þá verðum við öll að vera þolinmóð.
Mun þjónustunetið nýtast mér, hógværum hugbúnaðarverkfræðingi?
Eftirfarandi spurningalisti mun hjálpa til við að svara þessari spurningu:
Tekur þú eingöngu við innleiðingu viðskiptarökfræði? Í þessu tilviki mun þjónustunetið ekki nýtast þér. Það er auðvitað, þú gætir haft áhuga á því, en helst ætti þjónustunetið ekki að hafa bein áhrif á neitt í umhverfi þínu. Haltu áfram að vinna í því sem þú færð borgað fyrir.
Ertu með vettvang í fyrirtæki sem notar Kubernetes? Já, í þessu tilfelli þarftu þjónustunet (auðvitað, ef þú ert ekki að nota K8s bara til að keyra monolith eða lotuvinnslu - en þá langar mig að spyrja hvers vegna þú þarft K8s). Líklegast muntu finna sjálfan þig í aðstæðum með margar örþjónustur skrifaðar af mismunandi fólki. Þeir hafa allir samskipti sín á milli og eru bundin í flækju af keyrsluháðum, og þú þarft að finna leið til að takast á við þetta allt. Notkun Kubernetes gerir þér kleift að velja þjónustunet „fyrir sjálfan þig“. Til að gera þetta skaltu kynna þér getu þeirra og eiginleika og svara spurningunni um hvort eitthvað af tiltækum verkefnum henti þér yfirhöfuð (ég mæli með að hefja rannsóknir þínar með Linkerd).
Ertu að reka vettvang fyrir fyrirtæki sem notar EKKI Kubernetes en notar örþjónustur? Í þessu tilviki mun þjónustunetið nýtast þér, en notkun þess verður ekki léttvæg. Auðvitað máttu það herma eftir þjónustunet með því að hýsa fullt af umboðum, en mikilvægur kostur Kubernetes er einmitt dreifingarlíkanið: handvirkt viðhald á þessum umboðum mun krefjast miklu meiri tíma, fyrirhafnar og kostnaðar.
Ert þú í forsvari fyrir vettvang í fyrirtæki sem vinnur með einlita? Í þessu tilviki þarftu líklega ekki þjónustunet. Ef þú ert að vinna með einlita (eða jafnvel sett af einlitum) sem hafa vel skilgreint og sjaldan breytilegt samskiptamynstur, þá hefur þjónustunetið lítið að bjóða þér. Svo þú getur bara hunsað það og vona að það hverfi eins og vondur draumur...
Ályktun
Sennilega ætti þjónustunetið samt ekki að vera kallað „mesta hátækni í heimi“ - þessi vafasömu heiður tilheyrir líklega bitcoin eða gervigreind. Kannski er hún í topp fimm. En ef þú brýtur í gegnum lögin af hávaða og þvættingi, þá verður ljóst að þjónustunetið færir þeim sem búa til forrit í Kubernetes raunverulegan ávinning.
Ég vil að þú prófir Linkerd - að setja það upp í Kubernetes klasa (eða jafnvel Minikube á fartölvu) og þú getur séð sjálfur hvað ég er að tala um.
FAQ
- Ef ég hunsa þjónustunetið, mun það hverfa?
- Ég hlýt að valda þér vonbrigðum: þjónustunetið er hjá okkur í langan tíma.
— En ég VIL EKKI nota þjónustunet!
— Jæja, það er ekki nauðsynlegt! Lestu bara spurningalistann minn hér að ofan til að sjá hvort þú ættir að minnsta kosti að kynna þér grunnatriði hans.
— Er það ekki gamla góða ESB/millibúnaður með nýrri sósu?
- Þjónustunet fjallar um rekstrarrökfræði, ekki merkingarfræði. fyrirtækjaþjónusturúta (). Að halda þessum aðskilnaði hjálpar þjónustunetinu að forðast sömu örlög.
- Hvernig er þjónustunet frábrugðið API-gáttum?
Það eru milljón greinar um þetta efni. Googlaðu bara.
Er Envoy þjónustunet?
- Nei, Envoy er ekki þjónustunet, það er proxy-þjónn. Það er hægt að nota til að skipuleggja þjónustunet (og margt fleira - það er almennt umboð). En í sjálfu sér er það ekki þjónustunet.
- Network Service Mesh - er það þjónustunet?
- Nei. Þrátt fyrir nafnið er þetta ekki þjónustunet (hvernig líkar þér við undur markaðssetningar?).
- Mun þjónustunetið hjálpa við hvarfgjarna ósamstillta kerfið mitt sem byggir á skilaboðaröð?
- Nei, þjónustunetið mun ekki hjálpa þér.
- Hvaða þjónustunet ætti ég að nota?
- , ekkert mál.
- Greinin er ömurleg! / Höfundurinn - á sápuna!
— Vinsamlegast deildu hlekknum á það með öllum vinum þínum svo að þeir geti sannfærst um þetta!
Viðurkenningar
Eins og þú gætir giskað á af titlinum var þessi grein innblásin af frábærri ritgerð Jay Kreps "". Ég hitti Jay fyrir tíu árum þegar ég tók viðtal á Linked In og hann hefur verið mér innblástur síðan.
Þó að ég vilji kalla mig "Linkerd forritara", er raunveruleikinn sá að ég er meira umsjónarmaður README.md skráarinnar í verkefni. Er að vinna á Linkerd í dag , , fólk, og þetta verkefni hefði ekki verið mögulegt án ótrúlegs samfélags þátttakenda og notenda.
Og að lokum, sérstakar þakkir til skapara Linkerd, (primus inter pares), sem ásamt mér fyrir mörgum árum kafaði á hausinn í öllu þessu veseni með þjónustunetið.
PS frá þýðanda
Lestu líka á blogginu okkar:
- «»;
- «»;
- «»;
- «»;
- «'.
Heimild: www.habr.com