Märge. tõlge: Teenusvõrk on nähtus, millel pole veel stabiilset tõlget vene keelde (rohkem kui 2 aastat tagasi pakkusime võimalust "teenuste võrk" ja veidi hiljem hakkasid mõned kolleegid aktiivselt reklaamima kombinatsiooni "teenussõel") . Pidev jutt sellest tehnoloogiast on viinud olukorrani, kus turunduslikud ja tehnilised komponendid on liiga tihedalt läbi põimunud. See imeline materjal ühelt algse termini autorilt on mõeldud selguse toomiseks inseneridele ja mitte ainult.
Koomiks alates
Sissejuhatus
Kui olete tarkvarainsener, kes töötab kuskil taustasüsteemide vallas, on termin "teenusevõrk" ilmselt viimase paari aasta jooksul teie meelest juba kindlalt juurdunud. Tänu kummalisele kokkusattumusele võtab see fraas tööstuse üha enam võimust ning hüpe ja sellega seotud sooduspakkumised kasvavad lumepallina, lendavad mäest alla ega näita tempo aeglustumise märke.
Teenindusvõrk sündis pilve loodusliku ökosüsteemi häguses ja tendentslikus vees. Kahjuks tähendab see, et suur osa selle ümber käivatest vaidlustest ulatub „madala kalorsusega lobisemisest” kuni – kui kasutada tehnilist terminit – räige jama. Kui aga kogu müra välja filtreerida, võib avastada, et teenindusvõrgul on väga reaalne, kindel ja oluline funktsioon.
Selles postituses püüan just seda teha: pakkuda ausat, põhjalikku ja inseneridele suunatud juhendit teenindusvõrgu kohta. Ma vastan enamale kui lihtsalt küsimusele: "Mis see on?", - aga ka "Miks?" ning "Miks nüüd?". Lõpetuseks püüan visandada, miks (minu meelest) just see tehnoloogia on tekitanud nii hullumeelset hüpet, mis on iseenesest huvitav lugu.
Kes ma olen?
Tere kõigile! Minu nimi on . Olen üks loojatest - kõige esimene teenindusvõrgu projekt ja projekt, mis on termini ilmumises süüdi teenindusvõrk sellisena (vabandust poisid!). (Märkus tõlkida.: Muide, selle termini ilmumise koidikul, rohkem kui 2,5 aastat tagasi, tõlkisime juba sama autori varase materjali nimega "".) Juhin ka on startup, mis loob lahedaid teenusevõrke, nagu Linkerd ja .
Ilmselt võite arvata, et mul on selles küsimuses väga kallutatud ja subjektiivne arvamus. Püüan siiski hoida erapoolikust miinimumini (välja arvatud üks jaotis: "Miks räägitakse nii palju teenindusvõrgust?", - milles ma siiski jagan oma eelarvamusi). Samuti annan endast parima, et see juhend oleks võimalikult objektiivne. Konkreetsete näidete puhul toetun peamiselt Linkerdi kogemustele, tuues samas välja erinevused (kui neid on), mida ma tean teist tüüpi teenindusvõrgu rakendamisel.
Olgu, on aeg maiuste juurde liikuda.
Mis on teenindusvõrk?
Hoolimata kõigest reklaamist on teenindusvõrk struktuurilt üsna lihtne. See on lihtsalt hulk kasutajaruumi puhverservereid, mis asuvad teenuste "kõrval" (räägime hiljem veidi "lähedal") pluss juhtimisprotsesside komplekt. Puhverservereid nimetatakse ühiselt andmetasand, ja juhtimisprotsesse nimetatakse kontrolltasand. Andmetasand püüab kinni teenustevahelised kõned ja teeb nendega "midagi erinevat"; juhttasand vastavalt koordineerib puhverserveri käitumist ja tagab teile juurdepääsu, st. operaatorile API-le, võimaldades võrguga manipuleerida ja seda tervikuna mõõta.
Mis see puhverserver on? See on kategooria "Layer 7-aware" TCP-puhverserver (st "arvestades" OSI mudeli 7. kihti) nagu HAProxy ja NGINX. Saate valida endale meelepärase puhverserveri; Linkerd kasutab lihtsa nimega Rusti puhverserverit . Oleme selle koostanud spetsiaalselt teenindusvõrgu jaoks. Teised võrgusilmad eelistavad teisi puhverservereid (saadik on tavaline valik). Puhverserveri valimine on aga vaid rakendamise küsimus.
Mida need puhverserverid teevad? Ilmselgelt puhverserverivad nad kõnesid teenustele ja teenustest (rangelt võttes toimivad nad puhverserveritena ja vastupidiste puhverserveritena, käsitledes nii sissetulevaid kui ka väljaminevaid kõnesid). Ja nad rakendavad funktsioonide komplekti, mis keskendub kõnedele vahel teenuseid. See keskendumine teenustevahelisele liiklusele eristab teenusevõrgu puhverserverit näiteks API lüüsidest või sisendpuhverserveritest (viimased keskenduvad välismaailmast klastrisse tulevatele kõnedele). (Märge. tõlge: Olemasolevate Kubernetes Ingressi kontrollerite võrdluseks, millest paljud kasutavad juba mainitud Envoy'd, vt. .)
Niisiis, me arvasime välja andmetasandi. Juhttasand on lihtsam: see on komponentide kogum, mis tagab kogu mehaanika, mida andmetasand vajab koordineeritult töötamiseks, sealhulgas teenuse leidmine, TLS-sertifikaadi väljastamine, mõõdikute koondamine jne. Andmetasand teavitab juhttasandit selle käitumine; juhttasand omakorda pakub API-d, mis võimaldab muuta ja jälgida andmetasandi kui terviku käitumist.
Allpool on Linkerdi juhttasandi ja andmetasandi diagramm. Nagu näete, sisaldab juhtimistasand mitut erinevat komponenti, sealhulgas Prometheuse eksemplari, mis kogub puhverserveritelt mõõdikuid, ja muid komponente, nagu näiteks destination (teenuse avastamine), identity (sertifitseerimisasutus, CA) ja public-api (veebi ja CLI lõpp-punktid). Seevastu andmetasand on rakenduse eksemplari kõrval lihtne linkerd-puhverserver. See on lihtsalt loogikaskeem; reaalses maailmas võib teil olla iga juhttasandi komponendi kolm koopiat ja andmetasandil sadu või tuhandeid puhverservereid.
(Selle diagrammi sinised kastid tähistavad Kubernetese kaustade piire. Näete, et linkerd-puhverserveriga konteinerid asuvad rakenduse konteineritega samas kaustas. Seda skeemi tuntakse kui külgkorvi konteiner.)
Teenindusvõrgu arhitektuuril on mitu olulist mõju. Esiteks, kuna puhverserveri ülesanne on kõnede pealtkuulamine teenuste vahel, on teenusevõrgul mõtet ainult siis, kui teie rakendus on loodud teenuste komplekti jaoks. võrk keegi ei saa kasutada koos monoliitidega, kuid see on ühe puhverserveri jaoks selgelt üleliigne ja selle funktsionaalsuse järele pole tõenäoliselt nõudlust.
Teine oluline tagajärg on see, et teenindusvõrk nõuab tohutu puhverserverite arv. Tegelikult aheldab Linkerd iga teenuse iga eksemplari linkerd-puhverserveri (teised rakendused lisavad puhverserveri igale hostile/hostile/VM-ile. Seda on niikuinii palju). Selline puhverserveri aktiivne kasutamine toob iseenesest kaasa mitmeid täiendavaid komplikatsioone:
- Andmetasandi puhverserverid peaksid olema kiire, sest iga kõne kohta tehakse paar kõnet puhverserverile: üks kliendi poolel, üks serveri poolel.
- Samuti peavad olema puhverserverid väike и kergekaaluline. Igaüks neist tarbib mälu ja protsessori ressursse ning see tarbimine kasvab lineaarselt koos rakendusega.
- Suure hulga puhverserverite juurutamiseks ja värskendamiseks vajate mehhanismi. Seda käsitsi teha ei saa.
Üldiselt näeb teenindusvõrk (vähemalt linnulennult vaadatuna) välja järgmine: juurutate hulga kasutajaruumi puhverservereid, mis "teevad midagi ära" sisemise, teenustevahelise liiklusega, ning kasutate nende jälgimiseks ja haldamiseks juhttasandit.
On aeg esitada küsimus "Miks?"
Mille jaoks on teenindusvõrk?
Neile, kes teenindusvõrgu ideega esimest korda kokku puutusid, on andestatav olla pisut aukartusega. Teenindusvõrgu disain tähendab, et see mitte ainult ei suurenda rakenduse latentsust, vaid suurendab ka seda tarbima ressursse ja lisab hulk uusi mehhanisme infrastruktuuris. Esmalt seadistate teenindusvõrgu ja siis äkki avastate, et peate teenindama sadu (kui mitte tuhandeid) puhverservereid. Küsimus on selles, kes selle vabatahtlikuna osaleb?
Vastus sellele küsimusele koosneb kahest osast. Esiteks saab nende puhverserverite kasutuselevõtuga seotud tehingukulusid märkimisväärselt vähendada ökosüsteemis toimuvate muutuste tõttu (sellest lähemalt hiljem).
Teiseks on selline seade tegelikult suurepärane võimalus süsteemi lisaloogikat tuua. Ja mitte ainult sellepärast, et teenindusvõrgu abil saab lisada palju uusi funktsioone, vaid ka seetõttu, et seda saab teha ökosüsteemi sekkumata. Tegelikult põhineb kogu teenindusvõrgu mudel sellel postulaadil: multiteenussüsteemis, ükskõik mida teha üksikteenused, liiklus nende vahel on ideaalne koht funktsionaalsuse lisamiseks.
Näiteks Linkerdis (nagu enamikes võrkudes) on funktsionaalsus keskendunud peamiselt HTTP-kõnedele, sealhulgas HTTP/2 ja gRPC*. Funktsionaalsus on üsna rikkalik - selle saab jagada kolme klassi:
- Seotud funktsioonid töökindlus. Proovige uuesti taotlusi, aegumist, kanaari lähenemist (liikluse jagamine/ümbersuunamine) jne.
- Seotud funktsioonid jälgimine. Edumäärade, viivituste ja taotluste mahtude koondamine iga teenuse või üksikute sihtkohtade kohta; teenuste topoloogiliste kaartide koostamine jne.
- Seotud funktsioonid turvalisus. Vastastikune TLS, juurdepääsukontroll jne.
* Linkerdi vaatenurgast ei erine gRPC praktiliselt HTTP/2-st: see kasutab kasulikus koormuses lihtsalt protobufi. Arendaja seisukohalt on need kaks asja loomulikult erinevad.
Paljud neist mehhanismidest töötavad päringu tasemel (seega "L7 puhverserver"). Näiteks kui teenus Foo teeb HTTP-kõne teenuseribale, saab Foo poolel asuv linkerd-puhverserver arukalt koormust tasakaalustada ja kõnesid Foo-lt Bar-eksemplaridele vaadeldava latentsuse põhjal suunata; see võib vajadusel taotlust korrata (ja kui see on idempotentne); ta saab salvestada vastuse koodi ja ajalõpu jne. Samamoodi võib riba pool asuv linkerd-puhverserver taotluse tagasi lükata, kui see pole lubatud või kui päringu limiit on ületatud; oskab omapoolset viivitust parandada jne.
Puhverserverid saavad "midagi teha" ka ühenduse tasemel. Näiteks Foo poolel asuv linkerd-puhverserver saab algatada TLS-ühenduse ja linkerd-puhverserver Bar-pool võib selle lõpetada ning mõlemad pooled saavad kontrollida üksteise TLS-sertifikaate*. See ei paku mitte ainult teenuste vahelist krüptimist, vaid ka krüptograafiliselt turvalist viisi teenuste tuvastamiseks: Foo ja Bar saavad "tõestada", et nad on need, kes nad end olevat.
* "Sõbra sõber" tähendab, et kontrollitakse ka kliendi sertifikaati (vastastikune TLS). "Klassikalises" TLS-is, näiteks brauseri ja serveri vahel, kontrollitakse tavaliselt ainult ühe poole (serveri) sertifikaati.
Olenemata sellest, kas need töötavad taotluse või ühenduse tasemel, on oluline rõhutada, et kõik teenindusvõrgu funktsioonid on olemas töökorras iseloomu. Linkerd ei saa muuta kasuliku koormuse semantikat, näiteks lisada JSON-i fragmendile välju või teha muudatusi protobufis. Sellest olulisest funktsioonist räägime hiljem, kui räägime ESB-st ja vahevarast.
See on funktsioonide kogum, mida teenindusvõrk pakub. Tekib küsimus: miks mitte rakendada neid otse rakenduses? Ja milleks üldse puhverserveriga jamada?
Miks on teenindusvõrk hea mõte?
Kuigi teenindusvõrgu võimalused on kütkestavad, ei seisne selle põhiväärtus tegelikult funktsioonides. Lõpuks me Saab rakendage need otse rakenduses (hiljem näeme, et see oli teenindusvõrgu päritolu). Ühe lausega öeldes on teenindusvõrgu väärtus: see pakub funktsioone, mis on olulised kaasaegse serveritarkvara käitamiseks järjepideval, kogu pinu hõlmaval, rakenduste koodi agnostilisel viisil.
Analüüsime seda ettepanekut.
«Kaasaegse serveritarkvara käitamiseks üliolulised funktsioonid". Kui ehitate avaliku Internetiga ühendatud tehinguserveri rakendust, mis võtab vastu välismaailma päringuid ja vastab neile lühikese aja jooksul (nt veebirakendus, API-server ja enamik teisi kaasaegseid rakendusi) ja kui rakendate seda teenuste komplektina, mis suhtlevad üksteisega sünkroonselt, ja kui uuendate seda tarkvara pidevalt, lisate uusi funktsioone ja kui olete sunnitud süsteemi muutmise ajal töökorras hoidma - antud juhul palju õnne, loote kaasaegse serveritarkvara . Ja kõik need ülaltoodud suurepärased funktsioonid osutuvad teie jaoks kriitiliseks. Rakendus peab olema usaldusväärne, turvaline ja teil peab olema võimalik näha, mida see teeb. Just neid küsimusi aitab teenindusvõrk lahendada.
(Olgu, minu veendumus, et selline lähenemine on tänapäevane viis serveritarkvara koostamiseks, on pugenud eelmisesse lõiku. Teised eelistavad arendada monoliite, "reaktiivseid mikroteenuseid" ja muid asju, mis ei kuulu ülaltoodud definitsiooni alla. Neil inimestel on tõenäoliselt arvamus, mis erineb minu omast, ja omakorda usun, et need on "valed" - kuigi igal juhul pole teenindusvõrk nende jaoks eriti kasulik).
«Ühtlane kogu virna jaoks". Teenusvõrgu pakutavad funktsioonid pole mitte ainult kriitilised. Need kehtivad kõigi rakenduse teenuste kohta, olenemata sellest, mis keeles need on kirjutatud, millist raamistikku nad kasutavad, kes need kirjutas, kuidas need juurutati ning kõigist muudest arenduse ja kasutamise nüanssidest.
«Rakenduse koodist sõltumatu". Lõpuks ei paku teenindusvõrk mitte ainult ühtlast funktsionaalsust kogu virna ulatuses, vaid teeb seda ka viisil, mis ei nõua rakenduse redigeerimist. Teenusvõrgu funktsionaalsuse, sealhulgas konfigureerimise, värskendamise, käitamise, hooldamise jne ülesanded, on puhtalt platvormi tasemel ja rakendusest sõltumatud. Rakendust saab muuta ilma teenindusvõrku mõjutamata. Teenusevõrk võib omakorda muutuda ilma rakenduse sekkumiseta.
Lühidalt öeldes ei paku teenindusvõrk mitte ainult elutähtsaid funktsioone, vaid teeb seda globaalsel, ühtsel ja rakendusest sõltumatul viisil. Seega, kuigi teenusevõrgu funktsionaalsust saab rakendada teenuse koodis (näiteks iga teenusega kaasas oleva raamatukoguna), ei taga see lähenemine ühtsust ja sõltumatust, mis on teenuse puhul nii väärtuslik. teenindusvõrk.
Ja kõik, mida pead tegema, on lisada hulk puhverservereid! Luban, et varsti vaatame nende puhverserverite lisamisega seotud tegevuskulusid. Kuid kõigepealt peatume ja vaatame seda iseseisvuse ideed erinevate vaatenurgast inimesed.
Keda teenindusvõrk aitab?
Nii ebamugav kui see ka pole, selleks et tehnoloogia saaks ökosüsteemi oluliseks osaks, peavad inimesed selle omaks võtma. Keda siis huvitab teenindusvõrk? Kellele selle kasutamisest kasu on?
Kui arendate kaasaegset serveritarkvara, võite oma meeskonda umbkaudu ette kujutada rühmana teenuse omanikudkes üheskoos arendavad ja rakendavad äriloogikat ning platvormi omanikudkaasatud nende teenuste sisemise platvormi väljatöötamisse. Väikestes organisatsioonides võivad need olla samad inimesed, kuid ettevõtte kasvades kipuvad need rollid rohkem väljenduma ja jagunevad isegi alamrollideks ... (Siin on palju rääkida devopide muutuvast olemusest, mikroteenuste korralduslik mõju jne). n. Kuid praegu võtkem neid kirjeldusi enesestmõistetavana).
Sellest vaatenurgast on teenusevõrgust selgelt kasusaajad platvormi omanikud. Lõppude lõpuks on platvormi meeskonna lõppeesmärk luua siseplatvorm, millel teenuseomanikud saavad rakendada äriloogikat ja teha seda viisil, mis tagab neile maksimaalse sõltumatuse selle toimimise süngetest üksikasjadest. Teenusvõrk ei paku mitte ainult selle eesmärgi saavutamiseks olulisi võimalusi, vaid teeb seda nii, et see omakorda ei sõltu teenuse omanikest.
Kasu saavad ka teenuste omanikud, kuigi kaudsemal viisil. Teenuseomaniku eesmärk on olla võimalikult produktiivne äriprotsessi loogika elluviimisel ja mida vähem tal tuleb operatiivprobleemide pärast muretseda, seda parem. Selle asemel, et jõustada näiteks uuesti proovimise poliitikat või TLS-i, saavad nad keskenduda ainult ettevõttele ja loota, et platvorm hoolitseb ülejäänu eest. Nende jaoks on see suur eelis.
Sellise platvormide ja teenuste omanike vahelise jaotuse organisatsioonilist väärtust ei saa ülehinnata. Ma arvan, et ta annab oma panuse peamine panus teenusevõrgu väärtusesse.
Õppisime seda õppetundi, kui üks Linkerdi varajane fänn rääkis meile, miks nad valisid teenindusvõrgu: kuna see võimaldas neil "minimaalselt rääkida". Siin on mõned üksikasjad: ühe suure ettevõtte poisid migreerisid oma platvormi Kubernetesesse. Kuna rakendus töötas tundliku teabega, soovisid nad kogu klastrites oleva suhtluse krüpteerida. Olukorra tegi aga keeruliseks sadade teenuste ja sadade arendusmeeskondade olemasolu. Väljavaade kõigiga ühendust võtta ja veenda neid TLS-i toetamist oma plaanidesse lülitama ei rõõmustanud neid sugugi. Linkerdi installimisega nad migreerusid vastutus arendajatest (kelle vaatenurgast oli see tarbetu tüli) platvormitootjateni, kelle jaoks see oli tipptasemel prioriteet. Teisisõnu lahendas Linkerd nende jaoks mitte niivõrd tehnilist, kuivõrd organisatsioonilist probleemi.
Lühidalt öeldes pole teenindusvõrk pigem tehniline lahendus, vaid sotsiaal-tehniline Probleemid. (Aitäh selle termini kasutuselevõtu eest.
Kas teenindusvõrk lahendab kõik minu probleemid?
Jah. Tähendab, ei!
Vaadates kolme ülaltoodud funktsioonide klassi – usaldusväärsust, turvalisust ja vaadeldavust – saab selgeks, et teenindusvõrk ei ole nende probleemide täielik lahendus. Kuigi Linkerd võib saata korduvaid päringuid (kui ta teab, et need on idempotentsed), ei saa ta teha otsuseid selle kohta, mida kasutajale tagastada, kui teenus on lõpuks ära langenud – sellised otsused peab tegema rakendus. Linkerd võib pidada statistikat edukate päringute kohta, kuid ta ei saa teenusesse sisse vaadata ja selle sisemisi mõõdikuid esitada – selline tööriistakomplekt peaks rakendusel olema. Ja kuigi Linkerd on võimeline mTLS-i majutama, nõuavad täisväärtuslikud turvalahendused palju enamat.
Nende valdkondade funktsioonide alamhulk, mida teenusevõrk pakub, on seotud platvormi funktsioonid. Selle all pean silmas funktsioone, mis:
- Äriloogikast sõltumatu. Viis, kuidas Foo ja Bari vahel kõne histogrammid koostatakse, on täiesti sõltumatu sellest, kas miks Foo helistab Barile.
- Raske õigesti rakendada. Linkerdis on korduskatsete parameetrid kõikvõimalike väljamõeldud asjadega, nagu korduskatsete eelarved. (proovige eelarveid uuesti), kuna lihtsameelne lähenemine selliste asjade elluviimisel viib kindlasti nn "taotluste laviini" tekkeni. (proovi tormi uuesti) ja muud hajutatud süsteemidele iseloomulikud probleemid.
- Kõige tõhusam, kui seda kasutatakse järjepidevalt. TLS-mehhanismil on mõtet ainult siis, kui seda rakendatakse kõikjal.
Kuna need funktsioonid on rakendatud puhverserveri kihis (ja mitte rakenduskihis), paljastab teenindusvõrk need platvormid, mitte rakendusi. Seega pole vahet, mis keeles teenused on kirjutatud, millist raamistikku nad kasutavad, kes need kirjutas ja miks. Puhverserverid töötavad kaugemale kõigist nendest üksikasjadest ja selle funktsionaalsuse põhialus, sealhulgas konfigureerimise, värskendamise, käitamise, hooldamise jne ülesanded, on ainult platvormi tasemel.
Näited teenindusvõrgu võimaluste kohta
Kokkuvõtteks võib öelda, et teenindusvõrk ei ole terviklik lahendus usaldusväärsuse, jälgitavuse või turvalisuse tagamiseks. Nende valdkondade ulatus eeldab teenuste omanike, operatsioonide / SRE meeskondade ja teiste ettevõtte sidusrühmade kohustuslikku osalemist. Teenindusvõrk pakub iga nende piirkondade jaoks ainult platvormi tasemel "lõigu".
Miks on teenindusvõrk just praegu populaarseks muutunud?
Tõenäoliselt mõtlete praegu: OK, kui teenindusvõrk on nii hea, siis miks me ei hakanud kümme aastat tagasi virna juurutama miljoneid puhverservereid?
Sellele küsimusele on banaalne vastus: kümme aastat tagasi ehitasid kõik monoliite ja keegi ei vajanud hooldusvõrku. See on tõsi, kuid minu arvates jääb see vastus mõttetuks. Juba kümme aastat tagasi arutati mikroteenuste kontseptsiooni kui paljutõotavat võimalust suuremahuliste süsteemide loomiseks laialdaselt arutleda ja seda rakendati sellistes ettevõtetes nagu Twitter, Facebook, Google ja Netflix. Üldine arusaam – vähemalt nendes tööstuse osades, millega olen kokku puutunud – oli, et mikroteenused on "õige viis" suurte süsteemide ehitamiseks, isegi kui see oli pagana raske.
Muidugi, kuigi kümme aastat tagasi oli mikroteenuseid kasutanud ettevõtteid, ei kleepinud nad puhverservereid igale poole, et luua teenindusvõrk. Siiski, kui te vaatate tähelepanelikult, tegid nad midagi sarnast: paljud neist ettevõtetest andsid ülesandeks kasutada võrgu loomiseks spetsiaalset sisemist teeki (mida mõnikord nimetatakse paksu klienditeegiks, paks kliendiraamatukogu).
Netflixil oli Hysterix, Google'il Stubby, Twitteril Finagle'i raamatukogu. Näiteks Finagle on olnud Twitteris iga uue teenuse jaoks kohustuslik. See käsitles ühenduste nii kliendi kui ka serveri poolt, võimaldas korduvaid päringuid, toetas päringu marsruutimist, koormuse tasakaalustamist ja mõõtmist. See pakkus kogu Twitteri virna ühtlaselt usaldusväärsust ja jälgitavust, olenemata sellest, mida teenus tegi. Loomulikult töötas see ainult JVM-i keelte jaoks ja põhines programmeerimismudelil, mida tuli kasutada kogu rakenduse jaoks. Selle funktsionaalsus oli aga peaaegu sama, mis teenindusvõrgul. (Tegelikult oli Linkerdi esimene versioon lihtsalt puhverserveri vormis pakitud Finagle.)
Seega ei eksisteerinud kümme aastat tagasi mitte ainult mikroteenused, vaid ka spetsiaalsed proto-service-mesh teegid, mis lahendasid samu probleeme, mida tänapäeval lahendab teenindusvõrk. Hooldusvõrku ennast siis aga ei eksisteerinud. Enne tema ilmumist pidi olema veel üks vahetus.
Ja siin peitub sügavam vastus, mis on peidetud teises viimase 10 aasta jooksul toimunud muutuses: mikroteenuste kasutuselevõtu kulud on järsult langenud. Eespool mainitud ettevõtted, kes kasutasid mikroteenuseid kümmekond aastat tagasi – Twitter, Netflix, Facebook, Google – olid tohutu mastaabiga ja tohutute ressurssidega ettevõtted. Neil ei olnud mitte ainult vajadus, vaid ka võimalus luua, juurutada ja kasutada suuri mikroteenustel põhinevaid rakendusi. Energia ja pingutus, mida Twitteri insenerid on panustanud monoliitsest lähenemisest mikroteenustele üleminekuks, on hämmastav. (Ausalt, nagu ka asjaolu, et see töötas.) Selline infrastruktuuri manööverdamine oli siis väiksemate ettevõtete jaoks võimatu.
Liigume olevikku. Tänapäeval on idufirmasid, kus mikroteenuste ja arendajate suhe on 5:1 (või isegi ) ja pealegi saavad nad nendega edukalt hakkama! Kui 5 inimesest koosnev startup suudab ilma pingutamata opereerida 50 mikroteenust, siis miski vähendas nende juurutamise kulusid selgelt.
1500 mikroteenust Monzos; iga liin on ettenähtud võrgureegel, mis lubab liiklust
Mikroteenuste osutamise kulude dramaatiline vähenemine on ühe protsessi tulemus: konteinerite kasvav populaarsus и orkestrandid. See on täpselt sügav vastus küsimusele, mis aitas kaasa teenindusvõrgu tekkimisele. Sama tehnoloogia muutis atraktiivseks nii teenindusvõrgu kui ka mikroteenused: Kubernetes ja Docker.
Miks? Noh, Docker lahendab ühe suure probleemi - pakendiprobleemi. Pakkides rakenduse ja selle (võrguvälised) käitusaegsed sõltuvused konteinerisse, muudab Docker rakenduse asendatavaks üksuseks, mida saab hostida ja käivitada kõikjal. Samal ajal lihtsustab see oluliselt tööd. mitmekeelne virn: kuna konteiner on täitmisüksus, pole juurutamise ja töötamise eesmärgil vahet, mis selle sees on, olgu selleks JVM, Node, Go, Python või Ruby rakendus. Sa lihtsalt käivitad selle ja kõik.
Kubernetes viib kõik järgmisele tasemele. Nüüd, kui on hunnik "käivitatavaid asju" ja palju masinaid, millel neid käitada, on vaja tööriista, mis suudaks need omavahel sobitada. Laias plaanis annad Kubernetesele palju konteinereid ja palju masinaid ning see sobitab need omavahel (loomulikult on see dünaamiline ja pidevalt muutuv protsess: uued konteinerid liiguvad süsteemis ringi, masinad käivituvad ja peatuvad jne. Kubernetes võtab seda kõike arvesse ).
Kui Kubernetes on seadistatud, ei erine ühe teenuse juurutamiseks ja käitamiseks kuluv aeg palju kümne teenuse juurutamise ja käitamise kuludest (tegelikult on see 100 teenuse puhul peaaegu sama). Kui lisate sellesse konteinerisse pakkimismehhanismi, mis soodustab mitmekeelset juurutamist, saate hulga uusi rakendusi, mis on rakendatud mitmes keeles kirjutatud mikroteenustena, just sellises keskkonnas, millele teenusevõrk nii hästi sobib.
Niisiis jõuame vastuseni küsimusele, miks teenindusvõrgu idee on just praegu populaarseks saanud: Kubernetesi teenuste ühtsus on otseselt rakendatav teenindusvõrgu ees seisvate operatiivülesannete puhul. Pakendate puhverserverid konteineritesse, annate Kubernetesile ülesande need kleepida kõikjale, kus võimalik, ja voila! Selle tulemusel saate teenindusvõrgu, samal ajal kui Kubernetes juhib kogu selle juurutamise mehaanikat. (Vähemalt linnulennult. Muidugi on sellel protsessil palju nüansse.)
Kokkuvõtteks: põhjus, miks teenindusvõrk sai populaarseks nüüd ja mitte kümme aastat tagasi, on see, et Kubernetes ja Docker ei kasvanud mitte ainult märkimisväärselt vaja selles, lihtsustades rakenduste rakendamist mitmekeelsete mikroteenuste komplektidena, kuid ka oluliselt vähendatud kulud selle toimimiseks, pakkudes mehhanisme külgkorvi puhverparkide kasutuselevõtuks ja hooldamiseks.
Miks teenindusvõrgust nii palju räägitakse?
Hoiatus: Selles jaotises kasutan kõikvõimalikke oletusi, oletusi, väljamõeldisi ja siseteavet.
Kui otsite sõna "service mesh", leiate hulga taaskasutatud, madala kalorsusega sisu, veidraid projekte ja moonutuste kaleidoskoobi, mis väärib kajakambrit. Igas trendikas uues tehnoloogias on see olemas, kuid teenindusvõrgu puhul on probleem eriti terav. Miks?
Noh, see on osaliselt minu süü. Olen andnud endast parima, et igal võimalusel Linkerdit ja teenindusvõrku reklaamida lugematute ajaveebipostituste ja artiklite kaudu. Aga ma pole nii võimas. Sellele küsimusele tõeliseks vastamiseks peame veidi rääkima üldisest olukorrast. Ja sellest on võimatu rääkida üht projekti mainimata: on avatud lähtekoodiga teenusevõrk, mille on ühiselt välja töötanud Google, IBM ja Lyft.
(Nendel kolmel ettevõttel on väga erinevad rollid: näib, et Lyfti osalus piirdub ainult nimega; nemad on Envoy autorid, kuid ei kasuta või ei osale Istio arendamisel. IBM on seotud Istio arendamisega ja kasutab seda. Google on tugevalt kaasatud osaleb Istio väljatöötamises, kuid niipalju kui ma aru saan, ei kasuta ta seda tegelikult.)
Istio projekt on tähelepanuväärne kahe asja poolest. Esiteks on see tohutu turundustöö, mida Google oma reklaamimiseks teeb. Arvan, et enamik inimesi, kes on praegu teenindusvõrgu kontseptsioonist teadlikud, said sellest esmakordselt teada tänu Istiole. Teine eripära on see, kui halvasti Istio vastu võeti. Ilmselgelt olen ma selles asjas huvitatud pool, kuid püüdes jääda võimalikult objektiivseks, ei saa ma siiski aidata, kui , mitte väga spetsiifiline (kuigi mitte ainulaadne: tuleb meelde systemd, ...) avatud lähtekoodiga projekti jaoks.
(Praktikas tundub, et Istiol pole probleeme mitte ainult keerukuse ja kasutuskogemusega, vaid ka jõudlusega. Näiteks ajal Kolmanda osapoole läbiviimisel leidsid eksperdid olukordi, kus Istio saba latentsus oli 100 korda kõrgem kui Linkerdil, samuti olukordi, kus oli ressursside nappus, kui Linkerd jätkas edukalt töötamist ja Istio lakkas täielikult töötamast.)
Jättes kõrvale minu teooriad selle kohta, miks see juhtus, usun, et teenusevõrgu ümber leviv mastaapne hüpe on tingitud Google'i kaasamisest. Nimelt järgmise kolme teguri kombinatsioon:
- Istio obsessiivne reklaamimine Google'i poolt;
- asjakohane tauniv, kriitiline suhtumine projekti;
- Kubernetese viimasel ajal hüppeliselt tõusnud populaarsus, mille mälestus on veel värske.
Üheskoos ühinevad need tegurid omamoodi joovastavaks anoksiliseks keskkonnaks, milles ratsionaalse otsustusvõime väheneb, jättes alles vaid veidra mitmekesisuse .
Linkerdi vaatenurgast on see… Ma kirjeldaksin seda kui segast õnnistust. See tähendab, et on suurepärane, et teenindusvõrk on jõudnud peavoolu – mis ei olnud nii 2016. aastal, kui Linkerd esmakordselt ilmus, ja inimeste tähelepanu oli projektile tõesti raske tõmmata. Nüüd pole sellist probleemi! Kuid halb uudis on see, et teenindusvõrgu olukord on tänapäeval nii segane, et on peaaegu võimatu aru saada, millised projektid tõesti teenusevõrgu kategooriasse kuuluvad (rääkimata sellest, milline neist on konkreetse kasutusjuhtumi jaoks parim). See segab kindlasti kõiki (ja kindlasti on mõnel juhul Istio või mõni muu projekt Linkerdist parem, kuna viimane ei ole kõigile üks lahendus).
Linkerdi poolelt on meie strateegia olnud müra eiramine, keskendumine kogukonna tegelike probleemide lahendamisele ja sisuliselt oodata, kuni hüpe vaibub. Lõpuks kära vaibub ja saame rahus edasi töötada.
Seni peame kõik kannatlikud olema.
Kas teenindusvõrk on kasulik mulle, tagasihoidlikule tarkvarainsenerile?
Järgmine küsimustik aitab sellele küsimusele vastata:
Kas tegelete eranditult äriloogika rakendamisega? Sel juhul pole teenindusvõrk teile kasulik. See tähendab, et see võib teid muidugi huvitada, kuid ideaalis ei tohiks teenindusvõrk teie keskkonnas midagi otseselt mõjutada. Jätkake tööd selle kallal, mille eest teile makstakse.
Kas teil on Kubernetest kasutavas ettevõttes platvorm? Jah, sel juhul on teil vaja teenindusvõrku (muidugi, kui te ei kasuta K8-sid ainult monoliidi või partiitöötluse käivitamiseks - aga siis tahaksin küsida, miks teil K8-sid vaja on). Tõenäoliselt leiad end olukorrast, kus on palju erinevate inimeste kirjutatud mikroteenuseid. Nad kõik suhtlevad üksteisega ja on seotud käitusaegsete sõltuvuste puntrasse ning peate leidma viisi selle kõigega toimetulemiseks. Kubernetese kasutamine võimaldab teil valida teenindusvõrgu "enda jaoks". Selleks tutvu nende võimaluste ja funktsioonidega ning vasta küsimusele, kas mõni saadaolevatest projektidest sulle üldse sobib (soovitan alustada uurimistööd Linkerdist).
Kas kasutate platvormi ettevõttele, mis EI kasuta Kubernetest, kuid kasutab mikroteenuseid? Sel juhul on teenindusvõrk teile kasulik, kuid selle kasutamine ei ole triviaalne. Muidugi sa suudad jäljendama teenindusvõrk majutades hulga puhverservereid, kuid Kubernetese oluline eelis on just juurutusmudel: nende puhverserverite käsitsi hooldamine nõuab palju rohkem aega, vaeva ja kulusid.
Kas vastutate platvormi eest ettevõttes, mis töötab monoliitidega? Sel juhul pole teil tõenäoliselt hooldusvõrku vaja. Kui töötate monoliitidega (või isegi monoliitide komplektidega), millel on hästi määratletud ja harva muutuvad interaktsioonimustrid, pole teenindusvõrgul teile vähe pakkuda. Nii et võite seda lihtsalt ignoreerida ja loota, et see kaob nagu halb unenägu...
Järeldus
Tõenäoliselt ei tohiks teenindusvõrku ikkagi nimetada "maailma kõige hüplevamaks tehnoloogiaks" - see kahtlane au kuulub ilmselt bitcoinile või AI-le. Võib-olla on ta esiviisikus. Kui aga müra ja müra kihtidest läbi murda, saab selgeks, et teenindusvõrk toob Kubernetesis rakenduste loojatele tõelist kasu.
Soovin, et prooviksite Linkerdi - installige see Kubernetese klastrisse (või isegi sülearvutisse Minikube) ja näete ise, millest ma räägin.
FAQ
- Kui ma teenindusvõrku ignoreerin, kas see kaob?
- Pean teile pettumust valmistama: teenindusvõrk on meiega pikka aega.
— Aga ma EI TAHA kasutada teenindusvõrku!
- Noh, see pole vajalik! Lihtsalt lugege minu ülaltoodud küsimustikku, et näha, kas peaksite vähemalt selle põhitõdedega kurssi viima.
— Kas see pole vana hea ESB/vahenõu uue kastmega?
- Teenusvõrk käsitleb operatsiooniloogikat, mitte semantilist. ettevõtte teenindusbuss (). Selle eraldatuse säilitamine aitab teenindusvõrgul sama saatust vältida.
- Mille poolest erineb teenindusvõrk API lüüsidest?
Sellel teemal on miljon artiklit. Lihtsalt googelda.
Kas Envoy on teenindusvõrk?
- Ei, Envoy ei ole teenindusvõrk, see on puhverserver. Seda saab kasutada teenindusvõrgu korraldamiseks (ja palju muud – see on üldotstarbeline puhverserver). Kuid iseenesest pole see teenindusvõrk.
- Network Service Mesh – kas see on teenindusvõrk?
- Ei. Vaatamata nimele pole see teenindusvõrk (kuidas teile turunduse imed meeldivad?).
- Kas teenindusvõrk aitab minu sõnumijärjekorral põhinevat reaktiivset asünkroonset süsteemi?
- Ei, teenindusvõrk teid ei aita.
- Millist teenindusvõrku peaksin kasutama?
- , lihtne.
- Artikkel on nõme! / Autor - seebi peal!
— Palun jaga selle linki kõigi oma sõpradega, et nad saaksid selles veenduda!
Tänusõnad
Nagu pealkirjast võis arvata, on see artikkel inspireeritud Jay Krepsi fantastilisest traktaadist "". Kohtusin Jayga kümme aastat tagasi Linked Inis intervjuud tehes ja sellest ajast peale on ta mulle inspiratsiooniks olnud.
Kuigi mulle meeldib end nimetada "Linkerdi arendajaks", on tegelikkus see, et olen projektis pigem faili README.md hooldaja. Täna töötan Linkerdis , , inimesi ning see projekt poleks olnud võimalik ilma hämmastava kaastööliste ja kasutajate kogukonnata.
Ja lõpuks, eriline tänu Linkerdi loojale, (primus inter pares), kes koos minuga aastaid tagasi sukeldus pea ees kogu sellesse teenindusvõrguga segi.
PS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «";
- «";
- «'.
Allikas: www.habr.com