Service Mesh: mida iga tarkvarainsener peab teadma kõige kuumemast tehnoloogiast

Märkus tõlke kohta.: Teenusmesh - nähtus, millel pole veel kindlat tõlget eesti keelde (üle kahe aasta tagasi pakkusime välja variandi "teenuste võrk", hiljem hakkasid mõned kolleegid aktiivselt propageerima väljendit "teenuste sõel"). Algavad pidevad arutelud selle tehnoloogia üle on viinud olukorrani, kus turunduslikud ja tehnilised aspektid on omavahel liiga tihedalt põimunud. See suurepärane materjal ühe originaaltermini autori poolt on mõeldud tooma selgust inseneridele ja mitte ainult neile.

Koomiks Sebastian Caceres

Sissejuhatus

Kui oled tarkvarainsener, kes töötab tagasi- või klienditeenindussüsteemide alal, siis on termin "teenusmesh" ilmselt viimase paari aasta jooksul juba tugevalt Sinu teadvusesse juurdunud. Olles imelike sündmuste kokku langemisel, on see väljend hakanud tööstust üha enam haarama, samal ajal kui huvi ja sellega seotud reklaamipakkumised kasvavad nagu lumepall, mis veerema hakkab tõusul ja ei näita mingeid pidurdusmärke.

Teenusemesh tekkis hägustes, kallutatud vetes pilvetehnoloogia ökosüsteemis. Kahjuks tähendab see, et suurem osa sellega seotud vastukäimist varieerub "madala kalorsusega lobaga" kuni - kui kasutada tehnilist terminit - puhtalt välja mõeldud juttudeni. Kuid kui kõrvaldada kogu müra, võib leida, et teenusmesh’il on täiesti reaalne, kindel ja oluline funktsioon.

Selles publikatsioonis püüan ma täpselt seda teha: esitada aus, põhjalik ja inseneridele suunatud juhend teenusmesh'i kohta. Kavatseme vastata mitte ainult küsimusele: "Mis see on?", - vaid ka "Miks?", samuti "Miks just nüüd?". Lõpuks püüan ma kirjeldada, miks (minu arvates) just selle tehnoloogia tõttu on tekkinud hullumeelne tõuge, mis on selline huvitav lugu.

Kes ma olen?

Tere kõigile! Minu nimi on William Morgan. Olen üks loojatest Linkerd — esimese teenusmesh'i projekti ning projekti, mis on vastutav termini tekkimise eest teenuste võrk sellisena (vabandust, poisid!). (Tõlge.: Üks lisaks, juba üle kahe ja poole aasta tagasi, kui see termin esmakordselt ilmus, tõlkisime juba selle autori varasema materjali pealkirjaga "Mis on service mesh ja miks on see mulle vajalik [pilveäppi mikroteenuste jaoks]?».) Samuti juhtin ma Buoyant — idufirma, mis tegeleb selliste lahedate teenusmesh'i asjade loomisega nagu Linkerd ja Dive.

Te tõenäoliselt arvate, et mul on selle küsimuse kohta üsna kallutatud ja subjektiivne arvamus. Siiski püüan ma kallutatust minimeerida (välja arvatud ühes osas: „Miks on nii palju räägitud service mesh'ist?”, — milles jagan oma eelnevaid mõtteid). Samuti püüan ma teha kõik endast oleneva, et see juhend oleks võimalikult objektiivne. Konkreetsetes näidetes toetun peamiselt Linkerdi kogemusele, samas osutades mulle teadaolevatele erinevustele (kui need on olemas) teiste tüüpi service mesh'ide rakendustes.

Okei, on aeg minna maitsvate asjade juurde.

Mis on service mesh?

Hoolimata kogu hüpest on service mesh struktuuriliselt üsna lihtne. See on lihtsalt rida userspace-proxisi, mis asuvad „lähedal” teenustele (hiljem räägime veidi sellest, mis tähendab „lähedal”), pluss rida haldureid. Proxid koos saavad nimeks data plane, haldavad protsessid nimetatakse control plane. Data plane interceptib teenuste vahelisi kutsungeid ja teeb nendega „igaüht erinevat” ning control plane koordineerib vastavalt proxide käitumist, pakkudes juurdepääsu teie jaoks, st operaatorile, API-le, võimaldades manipuleerida võrku ja mõõta seda tervikuna.

Mis on need proxid? Need on TCP-proxid, mis on kategoorias „Layer 7-aware” (st „arvestavad” OSI mudeli 7. taset) , nagu HAProxy ja NGINX. Proxi valik sõltub teie eelistustest; Linkerd kasutab Rustis kirjutatud proxid, mis on lihtsalt nimetatud linkerd-proxy. Nii valmistasime selle spetsiaalselt service mesh'i jaoks. Teised mesh'id eelistavad teisi proxe (Envoy on tihti valik). Kuid proxide valik on vaid rakendusküsimus.

Mida teevad need proksiserverid? Selgelt öeldes, nad proxivad kutsungeid teenustele ja teenustelt (tehniliselt nad toimivad nii proksina kui ka tagasipööratud proxina, töötledes nii sissetulevaid kui väljaminevaid kutsungeid). Ja nad rakendavad funktsioonide komplekti, mis keskendub kutsungitele teenuste vahel. See fookus teenuste vahelise liikluse peal eristab service mesh-proxide teistest, näiteks API-silla või ingress-proxide (viimased keskenduvad kutsungitele, mis tulevad klastrisse välimisest maailmast). (Märkus tõlke kohta.: olemasolevate Ingress-kontrollerite võrdlus Kuberneteses, millest paljud kasutavad juba mainitud Envoy, vt selles artiklis.)

Nii et, data plane'iga oleme valmis saanud. Control plane on lihtsam: see on komponentide kogum, mis tagab kogu mehaanika, mida data plane vajab koordineeritud töötamiseks, sealhulgas teenuste avastamine, TLS-sertifikaatide väljastamine, mõõdikute agregatsioon jne. Data plane annab control plane'ile teada oma käitumisest; omakorda annab control plane API, mis võimaldab muuta ja jälgida data plane'i käitumist kui ühtset tervikut.

Allpool on kujutatud control plane'i ja data plane'i struktuuri Linkerdis. Nagu näha, sisaldab control plane mitmeid erinevaid komponente, sealhulgas Prometheuse instantsi, mis kogub mõõdikuid proksiserveritest, samuti teisi komponente, nagu sihtkoht (teenuste avastamine), identity (sertifitseerimiskeskus, CA) ja public-api (veebi ja CLI lõpp-punktid). Erinevalt sellest, esindab data plane lihtsat linkerd-proxy'd rakenduse eksemplari kõrval. See on vaid loogiline skeem; reaalsetes tingimustes jagamisel võib teil olla kolm koopiat igast control plane'i komponendist ja sadu või tuhandeid proksi data plane'is.

(Sellel skeemil tähistavad sinised ristkülikud Kubernetes'i podide piire. On näha, et linkerd-proxy konteinerid asuvad samas pod'is rakenduse konteineritega. Sellist skeemi tuntakse kui sidecar-konteiner.)

Teenuste võrgu arhitektuuril on mitmeid olulisi tagajärgi. Esiteks, kuna proksi ülesanne on summutada teenuste vahelisi kutseid, on teenuste võrk mõistlik ainult juhul, kui teie rakendus on loodud teatud teenuste kogumi põhjal. Võrk saab on mõeldud monoliitide jaoks, kuid see on ilmselgelt liialdatud üheainsa proksi jaoks, ja selle funktsionaalsus ei tule tõenäoliselt kasuks.

Teine oluline tagajärg on see, et teenuste võrk nõuab suurt hulka prokse. Tegelikult säilitab Linkerd linkerd-proxy igas iga teenuse eksemplaris (teised teostused lisavad proksi igale sõlmele/mahub/virtuaalmasinale. Igal juhul, see on üsna palju). Niivõrd aktiivne prokside kasutamine toob endaga kaasa mitmeid lisaraskusi:

1. Proksid data plane'is peavad olema kiired, kuna iga kutse kohta on paar proksi kõnesid: üks kliendi poolel, üks serveri poolel.
2. Samuti peavad proksid olema väikesed ja kergekaalulised.Igaüks tarbib mälu ja CPU ressursse ning see tarbimine suureneb lineaarselt koos rakendusega.
3. Teilite võtmeprotsess, et juurutada ja värskendada suurt hulka proksi. Manualne lähenemine ei ole variant.

Kokkuvõttes näeb teenuste võrgu mudel välja nii (vähemalt linnulennult): käitate hulga kasutajaruumi proksi, mis "teevad midagi" sisemise, teenustevahelise liiklusega ja kasutate juhtimisplaani nende jälgimiseks ja haldamiseks.

Jõudsime küsimuseni "Miks?"

Milleks on teenuste võrk vajalik?

Need, kes puutuvad esmakordselt kokku teenuste võrgu ideega, võivad tunda veidi ärevust. Teenuste võrgu struktuur tähendab, et see mitte ainult ei suurenda rakenduse viivitusi, vaid ka tarbib ressursse ja lisab rohkem uusi mehhanisme infrastruktuuri. Esiteks installite teenuste võrgu ja seejärel avastate äkitselt, et peate hooldama sadu (kui mitte tuhandeid) proksi. Küsimus on, kes läheb selle peale ise?

Sellele küsimusele on kaks vastust. Esiteks võivad nende prokside kasutuselevõttu seotud operatiivkulud mõningate ekosüsteemi muutuste tõttu märkimisväärselt väheneda (rohkem sellest hiljem).

Teiseks on selline seadistus tegelikult suurepärane viis lisada süsteemi täiendavat loogikat. Ja mitte ainult sellepärast, et teenuste võrgu abil saab lisada hulgaliselt uusi funktsioone, vaid ka seetõttu, et seda saab teha sekkumata ekosüsteemi. Tegelikult põhineb kogu teenuste võrgu mudel just sellel postulatsioonil: mitme teenuse süsteemis, sõltumata sellest, mida teevad eraldi teenused, on liiklus nende vahel ideaalne koht funktsionaalsuse lisamiseks.

Näiteks Linkerdis (nagu enamikus võrku) on funktsionaalsus peamiselt keskendunud HTTP-kõnedele, sealhulgas HTTP/2 ja gRPC*. Funktsionaalsus on üsna rikkalik — seda saab jagada kolme kategooriasse:

1. Funktsioonid, mis on seotud usaldusväärsusega. Uuesti tehtud päringud, ajapiirangud, kanarüssi lähenemine (liikluse jagamine/saatekohandumine) jne.
2. Funktsioonid, mis on seotud jälgimisega. Edukvõti, viivitused ja päringute mahtude kogumine iga teenuse või üksikute suundade jaoks; teenuste topoloogiliste kaartide koostamine jne.
3. Funktsioonid, mis on seotud turvalisusega. Vastastikune TLS, juurdepääsu kontroll ja jne.

* Linkerd'i vaatepunktist erineb gRPC praktiliselt HTTP/2-st ainult sellega, et koormuses kasutatakse protobuf'i. Arendaja jaoks eristuvad need kaks asja kindlasti.

Paljud neist mehhanismidest töötavad päringute tasandil (seetõttu ka „L7-proksi”). Näiteks kui teenus Foo saadab HTTP-kutse teenusele Bar, siis linkerd-proxy Foo poolel võib teha intelligentset koormuse jaotust ning suunata kutsed Foo-st Bar’i eksemplaride poole, sõltuvalt jälgitavast latentsusest; see võib vajadusel kutse korduda (ja kui see on idempotentne); see võib salvestada vastuse koodi ja ooteaja jne. Samamoodi võib linkerd-proxy Bar’i poolel kutse tagasi lükata, kui see ei ole lubatud või ületanud päringute limiti; see võib salvestada latentsuse oma poolelt jne.

Proksid saavad teha „midagi” ka ühenduse tasandil. Näiteks võib linkerd-proxy Foo poolel algatada TLS-ühenduse, samas kui linkerd-proxy Bar’i poolel võib selle katkestada, ja mõlemad pooled saavad omavahel kontrollida TLS-sertifikaate. See tagab mitte ainult krüpteerimise teenuste vahel, vaid ka krüptograafiliselt turvalise viisi teenuste tuvastamiseks: Foo ja Bar saavad „tõendada”, et nad on need, kes nad väidavad end olevat.

* „Teineteist” tähendab, et kliendi sertifikaat kontrollitakse samuti (mõlemapoolne TLS). „Klassikalises” TLS-is, näiteks brauseri ja serveri vahel, kontrollitakse tavaliselt ainult ühe poole (serveri) sertifikaati.

Sõltumata sellest, kas nad töötavad päringute või ühenduste tasandil, on oluline rõhutada, et kõik teenuste võrgu funktsioonid on operatiivsed iseloomuga. Linkerd ei saa muuta koormuse semantikat – näiteks lisada välju JSON fragmenti või teha muudatusi protobuf’is. Sellest olulisel aspektist räägime hiljem, kui arutame ESB ja middleware’i teemasid.

See on funktsioonide kogum, mida teenuste võrku pakub. Küsitakse, miks mitte rakendada neid otse rakenduses? Ja miks üldse tegeleda proksiga?

Miks on teenuste võrk hea idee

Kuigi teenuste võrgu võimalused köidavad kujutlusvõimet, peitub selle peamine väärtus tegelikult mitte funktsioonides. Lõppude lõpuks oleme me saame rakendada neid otse rakenduses (hiljem näeme, et see oli service mesh'i päritolu). Kui üritada seda mõtet väljendada ühes lauses, on service mesh'i väärtus järgmine: see pakub kaasaegse serveritarkvara toimimiseks kriitiliselt olulisi funktsioone, mis on ühtsed kogu tehnoloogiakuhja jaoks ja sõltumatud rakendusekoodist.

Analüüsime seda lauset.

«Funktsioonid, mis on kriitiliselt olulised tänapäeva serveritarkvara toimimiseksKui loote tehingupõhise serverirakenduse, mis on seotud avaliku internetiga, mis võtab vastu päringuid välismaailmast ja vastab neile lühikese aja jooksul — näiteks veebirakendus, API-server, ja enamus teisi kaasaegseid rakendusi — ja kui rakendate seda teenuste komplektina, mis suhtlevad omavahel sünkroonselt, ning kui uuendate pidevalt seda tarkvara, lisades uusi funktsioone, ja kui peate selle süsteemi töökindlust säilitama muudatuste käigus — siis õnnitlen teid, te loote tänapäevast serveritarkvara. Ja kõik need toredad funktsioonid, mis on ülal loetletud, osutuvad teie jaoks tõeliselt kriitiliselt oluliseks. Rakendus peab olema usaldusväärne, turvaline ja te peate olema võimelised jälgima, mida see teeb. Just need küsimused aitab lahendada service mesh.

(Noh, eelmisse lõiku on siiski imbunud minu veendumus, et see lähenemine on kaasaegne viis serveritarkvara loomiseks. Teised eelistavad arendada monoliite, "reaktiivseid mikroteenuseid" ja muid asju, mis ei vasta ülaltoodud määratlemisele. Nendel inimestel on kindlasti oma arvamus, mis erineb minu omast. Omalt poolt usun, et nad "ei ole õiged" — kuigi igal juhul pole service mesh neile eriti kasulik).

«Ühtne kogu tehnoloogiakuhja jaoksService mesh'i pakutavad funktsioonid ei ole mitte lihtsalt kriitiliselt olulised. Need on rakendatavad kõigile rakenduse teenustele olenemata sellest, millises keeles need on kirjutatud, millist raamistikku kasutatakse, kes need on kirjutanud, kuidas need on juurutatud ja kõigist muudest nende arendamise ja kasutamise nüanssidest.

«Sõltumatu rakendusekoodistLõpuks ei paku service mesh mitte ainult ühte tõhusat funktsionaalsust kogu tehnoloogiatööstuses, vaid teeb seda ka rakenduse muutmist mitte nõudval viisil. Service mesh'i funktsionaalsuse põhialused, sealhulgas seadistamise, uuendamise, haldamise ja muu ülesanded, asuvad eranditult platvormi tasemel ning on rakendusest sõltumatud. Rakendus võib muutuda, mõjutamata service mesh'i. Omakorda võib service mesh muutuda ilma rakenduse sekkumiseta.

Lühidalt öeldes ei paku service mesh mitte ainult elutähtsaid funktsioone, vaid teeb seda ka globaalsetel, ühtsetel ja rakendusest sõltumatutel viisidel. Seetõttu, kuigi service mesh'i funktsioone saab rakenduse koodis (näiteks teegina, mis on lisatud igale teenusele) realiseerida, ei tagaks see lähenemine ühtsust ja sõltumatust, mis on service mesh'is nii väärtuslikud.

Ja kõik, mis selleks vajalik, on lisada hulk proksisid! Luban, et varsti uurime neid operatiivkulusid, mis on seotud nende prokside lisamisega. Kuid enne, kui liigume edasi, peatume ja vaatame seda sõltumatuse ideed erinevatest vaatepunktidest. inimesi.

Kellele on service mesh kasulik?

Kuigi see võib olla ebamugav, peab tehnoloogia saama olulise osa ökosüsteemist olema inimeste poolt vastu võetud. Nii et kes on huvitatud service mesh'ist? Kes kasu saab selle kasutamisest?

Kui arendate kaasaegset serveritarkvara, siis võite oma meeskonda ette kujutada kui rühma teenuste omanikke, kes koos arendavad ja rakendavad äriloogikat, ning platvormi omanikke, kes tegelevad selle sisemise platvormi arendamisega, millel need teenused töötavad. Väikestes organisatsioonides võivad need olla samad inimesed, kuid ettevõtte kasvades muutuvad need rollid tavaliselt selgemaks ja jagunevad isegi alarollideks… (Seda võiks palju rääkida devops'i muutuvast olemusest, mikroteenuste organisatsioonilisest mõjust ja jne. Kuid seni võtame need kirjeldused antud seisukohtadena.)

Selle vaatevinkli kaudu on teenuse võrgu selged kasusaajad platvormi omanikud. Lõppude lõpuks on platvormimeeskonna eesmärk luua sisemine platvorm, millel teenuse omanikud saavad teostada äriloogikat viisil, mis tagab nende maksimaalse sõltumatuse selle haldamise keerukatest detailidest. Teenuse võrgu mitte ainult ei paku kriitilise tähtsusega võimalusi selle eesmärgi saavutamiseks: see teeb seda viisil, mis omakorda ei pane teenuse omanikele sõltuvusi.

Teenuse omanikud saavad samuti kasu, kuigi rohkem kaudselt. Teenuse omaniku eesmärk on olla võimalikult produktiivne äritegevuse juhtimise teostamisel, ja mida vähem peab ta haldusküsimuste pärast muretsema, seda parem. Selle asemel, et tegeleda näiteks taotlemise poliitikate või TLS-i rakendamisega, saavad nad keskenduda ainult äriülesannetele ja loota, et platvorm hoolitseb kõigest muust. See on neile suur eelis.

Sellise jaotuse organisatsiooniline väärtus platvormi ja teenuse omanike vahel on raske ülehindamine. Ma arvan, et see toob põhiosa lisandväärtust teenuse võrgule.

Me õppisime selle õppetunni, kui üks esimesi Linkerdi toetajaid ütles meile, miks nad valisid teenuse võrgu: sellepärast, et see võimaldas neil "vestlemist vähendada". Siin on mõned üksikasjad: suure ettevõtte töötajad migreerisid oma platvormi Kubernetesesse. Kuna rakendus töötas konfidentsiaalse teabega, soovisid nad krüpteerida kõik suhtlused klastrites. Siiski keeruliseks läks asi tuhandete teenuste ja arendajate meeskondade tõttu. Kõigi nende kontaktimine ja veenmine, et nad toetaksid TLS-i oma plaanides, ei olnud neile sugugi meeldiv. Linkerdi paigaldamisega üle kanti vastutus arendajatelt (kelle jaoks oli see liigsed mured) platvormimeestele, kelle jaoks oli see kõrge prioriteet. Teisisõnu, Linkerd lahendas neile mitte niivõrd tehnilise, vaid organisatsioonilise probleemi.

Lühidalt öeldes on teenuse võrk pigem mitte tehnilise, vaid sotsiaal-tehnilise probleemi lahendus. (Aitäh Cindy Sridharan selle termini tutvustamise eest.)

Kas teenuse võrk lahendab kõik mu probleemid?

Jah. Tähendab, ei!

Kui vaadata kolme eelnevalt mainitud funktsiooniklassi: usaldusväärsus, turvalisus ja jälgitavus, siis on selge, et teenusevõrk ei ole ühtegi neist probleemidest tõeliselt lahendav. Kuigi Linkerd suudab uuesti päringuid saata (kui ta teab, et need on idempotentsed), ei ole tal võimalik otsustada, mida kasutajale tagastada, kui teenus on kokku kukkunud – sellised otsused peab tegema rakendus. Linkerd võib pidada statistikat eduka päringu kohta, kuid ei suuda vaatama sisse teenusesse ja esitada selle sisemisi mõõdikke – selline tööriist peab olema rakendusel. Ja kuigi Linkerd suudab korraldada mTLS-i, nõuavad tõelised turvalisuse lahendused palju rohkem.

Mõned teenusevõrgu pakutavad funktsioonide omadused kuuluvad plaatformaalsusele. Sellega mõistan ma funktsioone, mis:

1. On sõltumatud äriloogikast. Valik, kuidas koostada arvutuste histogrammi Foo ja Bar vahel, ei sõltu absoluutselt sellest, miks kuidas Foo kutsub Bar'i.
2. On keeruline õigesti rakendada. Linkerdis on uuesti katsetamine parametriseeritud erinevate keerukate elementidega, nagu uuesti katsetamise eelarved (retry budgets), kuna otse-löögi lähenemine selliste asjade rakendamisele tõenäoliselt toob esile nn "päringute laviini" (retry storm) ja muid jaotatud süsteemidele iseloomulikke probleeme.
3. On kõige efektiivsemad, kui neid rakendatakse ühtlaselt. TLS-mehhanismil on tähendus ainult siis, kui seda rakendatakse igal pool.

Kuna need funktsioonid on rakendatud proksi tasemel (mitte rakendustasandil), pakub teenusevõrk neid tasemel platvormi, mitte rakendustasandil. Seega ei oma tähtsust, millisel keeles teenused on kirjutatud, millist raamistikku nad kasutavad, kes need kirjutas ja miks. Proksid töötavad kõigi nende detailide piirete taha, ja selle funktsiooni põhialused, sealhulgas seadistamine, uuendamine, haldamine, hooldus jne, jäävad täielikult platvormi tasemele.

Teenusevõrgu võimaluste näited

Kokkuvõtteks võib öelda, et service mesh ei ole täielik lahendus usaldusväärsuse, jälgitavuse või turvalisuse tagamiseks. Nende valdkondade ulatus eeldab kohustuslikku osalust teenuste omanike, Ops/SRE meeskondade ja teiste ettevõtte osaliste poolt. Service mesh pakub igaühe jaoks ainult platvormitasandi "lõiget" nendes valdkondades.

Miks on service mesh just nüüd populaarsust kogunud?

Tõenäoliselt küsite sel hetkel: okei, kui service mesh on nii hea, miks me ei hakanud kümme aastat tagasi miljoneid proksisid oma tehnoloogiapagasisse seadma?

Sellele küsimusele on triviaalne vastus: kümme aastat tagasi ehitati kõik monoliite ja service mesh ei olnud kellelegi vajalik. See on tõsi, kuid minu arvates kaob sellise vastuse puhul sisuline mõte. Isegi kümme aastat tagasi arutleti ja rakendati mikroteenuste kontseptsiooni kui perspektiivset viisi suurte süsteemide loomiseks laialdaselt sellistes ettevõtetes nagu Twitter, Facebook, Google ja Netflix. Ühine arusaam - vähemalt nendes tööstuse osades, millega ma kokku puutusin - oli, et mikroteenused on "õige viis" suurte süsteemide loomiseks, isegi kui see oli tõeliselt keeruline.

Muidugi, kuigi kümme aastat tagasi eksisteerisid ettevõtted, kes kasutasid mikroteenuseid, ei olnud nad sugugi proksisid iga nurga peale paigaldanud, et moodustada service mesh. Siiski, kui lähemalt vaadata, tegid nad midagi sarnast: paljudes neist ettevõtetest oli ette nähtud kasutada erilist sisemist raamatukogu võrguühenduse loomiseks (mõnikord nimetatakse seda paksu kliendi raamatukoguks, fat client library).

Netflixil oli Hysterix, Google'il Stubby, Twitteril Finagle'i raamatukogu. Näiteks oli Finagle kohustuslik iga uue teenuse jaoks Twitteris. See hallas nii kliendi kui ka serveri ühendusi, võimaldas uuesti päringute saatmist, toetas päringute suunamist, koormuse tasakaalustamist ja mõõtmist. See pakkus järjepidevat usaldusväärsuse ja jälgitavuse taset kogu Twitteri tehnoloogiapagasile, sõltumata teenuse sisust. Muidugi töötas see ainult JVM keelte jaoks ja põhines programmeerimislogi, mida tuli kasutada kogu rakenduse jaoks. Siiski olid selle funktsionaalsused peaaegu samad, mis service mesh'il. (Tegemist oli tõepoolest esimese Linkerdi versiooniga, mis oli finagle'i kujul proxyna.)

Seega, kümme aastat tagasi eksisteerisid mitte ainult mikroteenused, vaid ka spetsiaalsed proto-service-mesh raamatukogud, mis lahendasid samu probleeme, mida service mesh lahendab täna. Kuid tol ajal ei olnud olemas service meshi. Enne selle tekkimist pidi toimuma veel üks muutus.

Ja just siin peitub sügavam vastus, mis on varjatud veel ühte muutusse, mis juhtus viimase 10 aasta jooksul: mikroteenuste juurutamise kulud on järsult langenud. Üleval mainitud ettevõtted, kes kasutasid mikroteenuseid kümme aastat tagasi: Twitter, Netflix, Facebook, Google, olid tohutu mastaabi ja suurte ressurssidega ettevõtted. Neil oli mitte ainult vajadus, vaid ka võimalus luua, juurutada ja hallata suuri mikroteenustel põhinevaid rakendusi. Twitteri inseneride energia ja pingutused mikroteenusele üleminekul monoliitsest lähenemisest on tõeliselt hämmastav. (Ausalt öeldes, nagu ka see, et see õnnestus.) Sarnased infrastruktuuri katsetused olid tol ajal väiksemate ettevõtete jaoks võimatu.

Liigume nüüd tänasesse päeva. Täna on olemas idufirmasid, kus mikroteenuste ja arendajate suhe on 5:1 (või isegi 10:1), ja lisaks sellele suudavad nad nendega edukalt toime tulla! Kui 5 inimese idufirma suudab pingutuseta hallata 50 mikroteenust, siis on ilmselgelt midagi, mis on oluliselt vähendanud nende juurutamise kulusid.

1500 mikroteenust Monzo's; iga rida - ette nähtud võrgu reegel, mis lubab liiklust

Mikroteenuste kasutamise kulude järsk langus on tulemuseks ühele protsessile: konteinerite populaarsuse kasv ja orkestraatorite. Just selles seisneb põhjus, miks service mesh on ellu kutsutud. Üks ja sama tehnoloogia on teinud nii service mesh'i kui ka mikroteenuste atraktiivseks: Kubernetes ja Docker.

Miks? Noh, Docker lahendab ühe suure probleemi - pakkimise probleemi. Pakendades rakenduse ja selle (mittevõrgulised) jooksu sõltuvused konteinerisse, muudab Docker rakenduse vahetatavaks elemendiks, mida saab paigutada ja käitada ükskõik kus. Samal ajal lihtsustab see oluliselt haldamist mitmekeelsed stakk: kuna konteiner on aatomaarne täitmiseüksus, ei ole juurutamise ja haldamise jaoks oluline, mis seal sees on, olgu selleks rakendus JVM-is, Node'is, Go's, Pythonis või Ruby's. Sa lihtsalt käivitad selle ja kõik.

Kubernetes viib kõik uuele tasemele. Nüüd, kui on hulk "täidetavaid asju" ja palju masinaid, millel neid käivitada, tekib vajadus tööriista järele, mis suudab neid omavahel siduda. Laiemalt öeldes annate te Kubernetes'ele hulga konteinerid ja hulga masinaid ning tema seob need omavahel kokku (loomulikult on see dünaamiline ja pidevalt muutuv protsess: uued konteinerid liiguvad süsteemis, masinad käivituvad ja lõpetavad töötamise jne. Kuid Kubernetes arvestab kõigega sellega).

Pärast Kubernetes'e seadistamist on ajakulu ühe teenuse juurutamiseks ja haldamiseks vähesel määral erinev kümne teenuse juurutamise ja haldamise kuludest (tõepoolest, need on praktiliselt sarnased ka 100 teenusele). Lisage sellele konteinerid pakendamismehhanismina, mis soodustab mitmekeelseid rakendusi, ja saate hulgaliselt uusi rakendusi, mis on ellu viidud mikroteenustena, kirjutatud erinevates keeltes — just selline keskkond, mille jaoks service mesh sobib väga hästi.

Nii oleme vastuse leidnud küsimusele, miks service mesh'i idee on just nüüd populaarne: see ühtsus, mida Kubernetes teenustele tagab, on otseselt rakendatav service mesh'iga seotud haldusülesannetele. Te pakendate proksi konteineritesse, annate Kubernetes'ele ülesande need kuhugi kleepida, ja voilà! Te saate service mesh'i, mille juurutamise kogu mehhanika on Kubernetes'i hallatav. (V vähemalt linnulennult. Loomulikult on selles protsessis palju nüansse.)

Kokkuvõtteks: põhjus, miks service mesh on just nüüd, mitte kümme aastat tagasi populaarseks saanud, seisneb selles, et Kubernetes ja Docker on mitte ainult oluliselt suurendanud vajadust selle järele, lihtsustades rakenduste juurutamist mitmekeelselte mikroteenuste komplektidena, vaid on ka oluliselt vähendanud kulusid selle haldamiseks, pakkudes mehhanisme sidecar-proksi juurutamiseks ja hooldamiseks.

Miks on nii palju räägitud service mesh'ist?

Hoiatus: selles peatükis rakendan ma igasuguseid eeldusi, oletusi, spekulatsioone ja siseteavet.

Otsides fraasi „service mesh“, satute hulga ümber töötatud madala kalorsusega sisu, kummalisi projekte ja kaleidoskoopilisi moonutusi, mis väärivad eho-kambrit. Iga uue moetehnoloogia puhul on see iseloomulik, kuid service mesh'i puhul on probleem eriti terav. Miks?

Noh, osaliselt on see minu süü. Olen teinud kõik, et edendada Linkerdit ja service mesh'i igal võimalusel, kirjutades lugematult blogipostitusi ja artikleid, nagu see. Kuid ma ei ole nii vägev. Et tõeliselt sellele küsimusele vastata, tuleb rääkida pisut üldisest olukorrast. Ja seda ei saa teha, kui ei maini ühte projekti: Istio — avatud lähtekoodiga service mesh, mille arendavad koos Google, IBM ja Lyft.

(Neil kolmel ettevõttel on täiesti erinevad rollid: Lyfti osalus tundub olevat vaid nimekiri; nad on Envoy autoriõiguste omanikud, kuid ei kasuta Istio't ega osale selle arendamisel. IBM osaleb Istio arendamisel ja kasutab seda. Google osaleb aktiivselt Istio arendamisel, kuid, kui ma ei eksi, ei kasuta nad seda tõeliselt.)

Projekt Istio on tähelepanuväärne kahe omaduse poolest. Esiteks, see on tohutu turundustegevus, mida Google, eriti, rakendab selle edendamiseks. Minu hinnangul teavad enamik inimesi, kes on teadlikud service mesh kontseptsioonist, sellest esmakordselt Istio kaudu. Teine omadus on see, kui halb on Istio vastuvõtugrad. esile tõsta Olen ilmselgelt osaline, kuid püüdes olla võimalikult objektiivne, ei saa ma siiski väga negatiivne, mitte just iseloomulik (kuigi mitte ainulaadne: tuleb meelde systemd, võrdlus oleme korraldanud juba korduvalt…) avatud lähtekoodiga projekti jaoks.

(Praktikas paistab, et Istio'l on probleemid mitte ainult keerukuse ja UX-iga, vaid ka jõudlusega. Näiteks, Linkerdi jõudluse hindamise, mille viis läbi kolmas osapool, leidis spetsialistid olukordi, kus Istio hilinemise sabad (tail latency) olid 100 korda kõrgemad kui Linkerdil, samuti olukordi, kus ressursse nappis, kus Linkerd jätkas edukalt toimimist, samal ajal kui Istio lõpetas täielikult töö.)

Jätan kõrvale oma teooriad selle kohta, miks see juhtus, arvan, et service mesh'i ülemäärane furoor tuleneb just Google'i osalusest. Nimelt kolmest järgnevast tegurist:

1. Google'i pealetükkiv reklaamimine Istio osas;
2. asjakohane ebasoovitav, kriitiline suhtumine projekti;
3. viimasel ajal kiirelt kasvanud Kubernetes'e populaarsus, mille mälestused on endiselt värsked.

Need tegurid liituvad koos mõnesse uimastavasse, hapnikuvaegusesse keskkonda, kus ratsionaalne mõtlemisvõime nõrgeneb, ja alles jääb ainult imeline variant tulpamania.

Linkerd'i vaatenurgast on see… ma kirjeldaksin seda kui kahevahelise õnnestumise. Mõtlen, et on suurepärane, et service mesh on peavoolu jõudnud — midagi, mida ei olnud 2016. aastal, kui Linkerd alles ilmuma hakkas ja oli tõeliselt keeruline tõmmata inimeste tähelepanu projekti. Nüüd ei ole selle probleemiga! Aga halb on see, et service mesh'i olukord on täna nii segane, et on praktiliselt võimatu mõista, millised projektid kuuluvad tõeliselt service mesh'i kategooriasse (rääkimata sellest, et mõista, milline neist sobib kõige paremini konkreetse kasutusjuhtumi jaoks). See takistab kindlasti kõiki (ja kindlasti on mõnel juhul Istio või mõni muu projekt paremini sobiv kui Linkerd, kuna viimane ei ole siiski universaalne lahendus).

Linkerd'i poolelt koosnes meie strateegia müra ignoreerimisest, tõsiselt murede lahendamiseks, mis koondusid kogukonnas ja, sisuliselt, ootamise ajal, kuni furoor vaibub. Lõpuks hüpe väheneb ja me saame rahulikult edasi töötada.

Praegu peame me kõik natukene kannatama.

Kas service mesh aitab mind, tagasihoidlikku tarkvarainseneri?

Sellele küsimusele aitab vastata järgmine küsitlus:

Kas tegelete ainuüksi äri loogika rakendamisega? Sellisel juhul ei ole service mesh teid vajalik. Loomulikult võite selle vastu huvi tunda, kuid ideaalis ei tohiks service mesh otse mõjutada midagi teie keskkonnas. Jätkake töötamist selle nimel, mille eest teised teile maksavad.

Kas te toetate platvormi ettevõttes, mis kasutab Kubernetes'e? Jah, sel juhul on teil kindlasti vajalik service mesh (muidugi, kui te ei kasuta K8s lihtsalt monoliidi või partii töötlemiseks — aga siis tahaksin teada, miks teile K8s üldse vajalik on). Tõenäoliselt leiate end olukorrast, kus on arvukalt mikroteenuseid, mille on kirjutanud erinevad inimesed. Kõik need suhtlevad üksteisega ja on seotud jooksva sõltuvuste suhtluse massiga ning teil tuleb leida viis, kuidas sellega toime tulla. Kubernetes'i kasutamine võimaldab valida service mesh, mis sobib teile. Selleks tutvuge nende võimaluste ja omadustega ning vastake küsimusele, kas mõni olemasolevatest projektidest sobib teile (soovitan alustada uurimist Linkerdiga).

Te töötate ettevõtte platvormi kallal, mis EI kasuta Kubernetes'i, kuid kasutab mikrosüsteeme? Sel juhul on service mesh teile kasulik, kuid selle kasutamine ei ole lihtne. Muidugi, te saate simuleerida service mesh'i tööd, paigutades hulk proksisid, kuid Kubernetes'e oluline eelis on just juurutusmudel: nende prokside käsitsi hooldamine nõuab palju rohkem aega, vaeva ja kulutusi.

Kas olete vastutav platvormi eest ettevõttes, mis töötab monoliitidega? Sel juhul ei ole service mesh teile tõenäoliselt vajalik. Kui te töötate monoliitidega (või isegi monoliitide kogumitega), millel on selgelt määratletud ja harva muutuvad suhtlemismustrid, siis ei saa service mesh teile suurt midagi pakkuda. Nii et võite selle lihtsalt tähelepanuta jätta ja loota, et see kaob nagu halb unenägu…

Kokkuvõte

Tõenäoliselt ei ole service mesh seda väärt nimetada "maailma kõige ülehinnatumate tehnoloogiate" hulka — see kahtlane au võib tõenäoliselt kuuluda Bitcoinile või tehisintellektile. Võib-olla on see esimeses viies. Kuid kui murda läbi müra ja segaduse kihid, on selge, et service mesh toob reaalset kasu neile, kes loovad rakendusi Kubernetes'is.

Tahaksin, et prooviksite Linkerd’i — selle installimine Kubernetes'i klastrisse (või isegi Minikube'i oma sülearvutisse) võtab aega umbes 60 sekundit, ja saate ise näha, mida ma mõtlen.

KKK

— Kui ma ignoreerin service mesh'i, kas see kaob ära?
— Pean teid kurvastama: service mesh on meiega pikaajaline.

— Aga ma EI TAHA kasutada service mesh'i!
— Ja ei peagi! Lihtsalt lugege minu ülaltoodud küsitlust, et aru saada, kas peaksite tutvuma vähemalt tema põhiasjadega.

— Kas see ei ole lihtsalt vana hea ESB/middleware uue sisu all?
— Teeninduse mesh tegeleb operatiivse loogikaga, mitte tähendusega. See oli peamine puudus ettevõtte teenuste bussist (ESB). Selle jaotuse säilitamine aitab teeninduse mesh-'il vältida sama saatust.

— Kuidas teeninduse mesh erineb API lüüsidest?
— Selle kohta on miljon artiklit. Otsige lihtsalt Google'ist.

— Kas Envoy on teeninduse mesh?
— Ei, Envoy ei ole teeninduse mesh, see on proksi-server. Seda saab kasutada teeninduse mesh'i korraldamiseks (ja paljus muuks — see on universaalne proksi). Aga iseenesest ei ole ta teeninduse mesh.

— Network Service Mesh on teeninduse mesh?
— Ei. Hoolimata nimest ei ole see teeninduse mesh (kuidas need turunduse imed toimivad?).

— Kas teeninduse mesh aitab minu reaktiivsete asünkroonsete süsteemide puhul, mis põhinevad sõnumite järjekordadel?
— Ei, teeninduse mesh ei aita teid.

— Millist teeninduse mesh-i ma peaksin kasutama?
— Linkerd, seda on selge.

— Artikkel on kehv! / Autor prügikasti!
— Palun jagage seda linki kõigi oma sõpradega, et nad saaksid sellest veenduda!

Tänud

Kuidas te võisite arvata pealkirjast, see artikkel oli inspireeritud fantastilisest kirjutisest Jay Krepsilt "The Log: Mis iga tarkvaraarendaja peaks teadma reaalajas andmete ühendava abstraktsiooni kohta“. Ma kohtusin Jay'ga kümme aastat tagasi, kui tegin intervjuud LinkedInis, ja sellest ajast alates on ta olnud mulle inspiratsiooniks.

Kuigi mulle meeldib nimetada end "Linkerd arendajaks", on reaalsus see, et ma olen pigem README.md faili hooldaja projektis. Linkerdis töötab täna meeldib väga., meeldib väga., meeldib väga. palju inimesi ja see projekt ei oleks toimunud ilma suurepärase kogukonna panuseta ja kasutajateta.

Ja lõpetuseks, eriline tänu Linkerd'i loojale, Oliver Gould (primus inter pares), kes koos minuga sukeldus kõikidesse nende teeninduse mesh'i segadustesse juba aastaid tagasi.

P.S. tõlkijalt

Lugege ka meie blogist:

• «Mis on service mesh ja miks on see mulle vajalik [pilveäppi mikroteenuste jaoks]?»;
• «Traefik 2.0: teeninduse mesh'i uuendus TCP toe ja uue veebiliidese toega»;
• «Maesh — uus lihtne teeninduse mesh Kubernetes'e jaoks Traefik autoritelt»;
• «Tagasi mikroteenustele koos Istio. Osa 1»;
• «Conduit — kerge service mesh Kubernetes'ile».

Allikas: habr.com