Teenusete võrk: mida iga tarkvarainsener peab teadma kõige populaarsemast tehnoloogiast

Märk. tõlge.: Teenusete võrk on nähtus, millel puudub siiani kindel tõlge eesti keelde (üle kahe aasta tagasi pakkusime me variandi „teenuste võrk“, kuid hiljem hakkasid mõned kolleegid aktiivselt edendama kombinatsiooni „teenuseline sõel“). Jätkuvad arutelud selle tehnoloogia üle on viinud olukorrani, kus turundus ja tehnilised aspektid on liiga tihedalt põimunud. See suurepärane artikkel ühe originaaltermini autori poolt toob selgust inseneridele ja mitte ainult.

Koomiks autorilt Sebastian Caceres

Sissejuhatus

Kui oled tarkvarainsener, kes töötab kuskil tagasisüsteemide alal, on termin „service mesh“ tõenäoliselt juba viimase paari aasta jooksul kindlalt sinu teadvusesse juurdunud. Tänu kummalisele kokkusattumusele on see väljend tööstust üha enam haaranud ning sellega seotud reklaampakkumised kasvavad nagu lumepall, mis veereb mäest alla, andes signaale, et see ei aeglustu.

Teenusmesh sündis hägustes ja kallutatud vetes cloud native ökosüsteemis. Kahjuks tähendab see, et suur osa sellega seotud vaidlustest varieerub alates 'madala kalorsusega lobast' kuni - kui kasutada tehnilist terminit - avatud jaburuseni. Kuid kui eemaldada kogu müra, võib avastada, et teenusmesh'il on täiesti reaalne, määratletud ja oluline funktsioon.

Selles publikatsioonis püüan ma seda teha: esitada ausat, sügavat ja insenerikeskset juhendit teenusmesh'i kohta. Kavatseme vastata mitte ainult küsimusele: „Mis see on?”, — vaid ka „Miks?”, samuti „Miks just praegu?”. Lõpuks püüan joonistada, miks (minu arvates) just see tehnoloogia on tekitanud nii pöörast huvi, mis on iseenesest huvitav lugu.

Kes ma olen?

Tere kõigile! Minu nimi on William Morgan. Olen üks Loomemesh'i loojatest — esimesest teenusmesh'i projektist ja projektist, mis vastutab termini Linkerd nõudmise eest (kōik vabandused, poisid!). teenuse võrk sellisel kujul (vabandage, poisid!). (Prim tõlk.: Muide, selle termini algusaegadel, rohkem kui 2,5 aastat tagasi, tõlkisime juba sama autori varasema materjali nimega „Mis on service mesh ja miks see on vajalik [kogukonna rakendusele, mis põhineb mikroteenustel]?».) Samuti juhin ma Buoyant — idufirma, mis loob huvitavaid service mesh-lahendusi nagu Linkerd ja Dive.

Te ilmselt arvate, et mul on selle teema kohta üsna subjektiivne ja isiklik arvamus. Siiski püüan ma hoida kallutatuse minimaalsena (välja arvatud ühes jaos: „Miks on service meshist nii palju juttu?“, — kus jagan siiski oma eelarvamusi). Samuti panen ma kõik sisse, et see juhend oleks võimalikult objektiivne. Konkreetsetes näidetes tuginen peamiselt Linkerdile, märkides samal ajal teadaolevaid erinevusi (kui neid on) teiste tüüpi service meshide implementeerimisel.

Okei, aeg liikuda põnevate asjade juurde.

Mis on service mesh?

Oma hype'ist hoolimata on service mesh struktuurselt üsna lihtne. See on lihtsalt hulk userspace-proksisid, mis asuvad „kõrval“ teenustest (hiljem räägime natuke, mis see „kõrval“ tähendab), pluss komplekt juhtimisprotsesse. Proksid koos moodustavad data plane, samas kui juhtimisprotsessid nimetatakse control plane. Andmete tasand intercepts calls between services and does various things with them; the control plane, respectively, coordinates proxy behavior and provides access for you, i.e., the operator, to the API, allowing manipulation of the network and measurement of it as a whole.

Mis on see proxy? See on TCP-proxy, mis on „Layer 7-aware“ kategoorias (st. „arvesse võtma“ 7. taset OSI mudelis) nagu HAProxy ja NGINX. Proxyt saab valida vastavalt oma soovile; Linkerd kasutab Rustis kirjutatud proxy'd, mis on lihtsalt nimetatud linkerd-proxy. Oleme selle spetsiaalselt service mesh'i jaoks kokku pannud. Teised mesh'id eelistavad teisi proxye (Envoy on levinud valik). Siiski on proxy valimine lihtsalt rakendusküsimus.

Mida teevad need proxy-serverid? Ilmselgelt nad proxivad kutseid teenustele ja nende kaudu (rangelt öeldes täidavad nad nii proxy kui ka tagurpidi proxy funktsiooni, töötledes nii sisenevaid kui ka väljuvaid kutseid). Ja nad rakendavad kogumit funktsioone, mis keskenduvad kutsetele teenuste vahel. See keskendumine teenuste vahele jäävale liiklusele eristab service mesh-proxysid, näiteks API-gateway'dest või ingress-proxydest (eelmainitud keskenduvad kätte saadud kutsetele klastrisse välismaailmast). (Märk. tõlge.: Existing Ingress controllers for Kubernetes comparison, many of which utilize the previously mentioned Envoy, see in selles artiklis.)

So, we have figured out data plane. The control plane is simpler: it consists of a set of components that ensure all the mechanics necessary for the data plane to operate in a coordinated manner, including service discovery, TLS certificate issuance, metrics aggregation, etc. The data plane informs the control plane about its behavior; in turn, the control plane provides an API that allows modification and monitoring of the data plane's behavior as a single entity.

Below is a diagram of the control plane and data plane in Linkerd. As you can see, the control plane includes several different components, including a Prometheus instance that collects metrics from the proxy servers, as well as other components such as destination (service discovery), identity (certificate authority, CA) and public-api (endpoints for web and CLI). In contrast, the data plane consists of a simple linkerd-proxy alongside the application instance. This is just a logical diagram; in practice, during deployment, you may have three replicas of each component in the control plane and hundreds or thousands of proxies in the data plane.

(SInise ristkülikud sellel skeemil tähistavad Kubernetes'i pod'ide piire. Näha on, et linkerd-proxy konteinerid asuvad samas pod'is rakenduse konteineritega. Sellist skeemi tuntakse kui sidecar-konteiner.)

Service mesh arhitektuuril on mitmeid olulisi tagajärgi. Esiteks, kuna proxie ülesanne on vahendada teenuste vahelisi ühendusi, on service mesh mõttekas vaid siis, kui teie rakendus on loodud teatud teenuste kogumil. Mesh saab saab kasutada ka monoliitide puhul, kuid see on selgelt üleliigne üheainsa proksi jaoks ning selle funktsionaalsus ei pruugi olla nõutud.

Teine oluline tagajärg on see, et service mesh nõuab tohutul hulgal proksisid. Tegelikult lisab Linkerd linkerd-proxy iga teenuse iga eksemplari külge (teised rakendused lisavad proksi igale sõlmele/hostile/virtuaalmasinale. Igal juhul ei ole see väike kogus). Nii aktiivne prokside kasutamine toob endaga kaasa mitmeid lisaraskusi:

1. Data plane'i proksid peavad olema kiired, kuna iga kõne puhul on proksile kaks päringut: üks kliendi pool, üks serveri pool.
2. Samuti peavad proksid olema väikeste ja kergete. Igaüks neist tarbib mäluresursse ja CPU-d, ning see tarbimine kasvab lineaarset koos rakendusega.
3. Teil on vaja mehhanismi, et juurutada ja uuendada suurt hulka proksisid. Seda käsitsi teha ei saa.

Üldiselt näeb service mesh välja nii (vähemalt linnulennult): juurutate hulga userspace-proksisid, mis „teevad midagi” sisemise, teenustevahelise liiklusega ja kasutate control plane'i nende jälgimiseks ja haldamiseks.

Nüüd on aeg küsida: „Miks?”

Miks on vajalik service mesh?

Neile, kes kohtuvad service mesh'i ideega esmakordselt, on arusaadav tunda kerget ärevust. Service mesh'i struktuur tähendab, et see mitte ainult ei suurenda rakenduse latentsust, vaid ka tarbib ressursse ja lisab hulga uusi mehhanisme infrastruktuuri. Esiteks installite service mesh'i ja siis avastate äkki, et peate hoolitsema sadade (kui mitte tuhandete) prokside eest. Küsimus on, kes seda vabatahtlikult ette võtab?

Küsimuse vastus koosneb kahest osast. Esiteks, operatiivkulud, mis on seotud nende prokside kasutuselevõtuga, võivad märkimisväärselt väheneda tänu mõningatele muutustele ökosüsteemis (lisainfot selle kohta hiljem).

Teiseks, selline seade on tegelikult suurepärane viis, kuidas süsteemi lisada täiendavat loogikat. Ja mitte ainult seetõttu, et service mesh võimaldab lisada palju uusi funktsioone, vaid ka seetõttu, et seda saab teha sekkumata ökosüsteemi. Tegelikult põhineb kogu service mesh'i mudel just sellel postulaadil: mitmes teenusesüsteemis, sõltumata sellest, mida teevad üksikud teenused, siis liiklus nende vahel on ideaalne koht funktsionaalsuse lisamiseks.

Näiteks Linkerdis (nagu enamikus mesh'ides) on funktsionaalsus peamiselt keskendunud HTTP kutsetele, sealhulgas HTTP/2 ja gRPC*. Funktsionaalsus on üsna rikkalik — seda võib jagada kolme klassi:

1. Funktsioonid, mis on seotud usaldusväärsusega. Taaskutsu, ajapiirangud, kanarindade lähenemine (liikluse jagamine/ümbersuunamine) jne.
2. Funktsioonid, mis on seotud monitooringuga. Teenuste või erisuundade tulemuslikkuse, viivituste ja päringute mahtude aggregatsioon; teenuste topoloogiliste kaardide koostamine jne.
3. Funktsioonid, mis on seotud turvalisus. Vastastikune TLS, juurdepääsu kontroll jne.

* Linkerdi vaates ei erine gRPC praktiliselt HTTP/2-st: lihtsalt kasutas koormuses protobuf. Arendaja seisukohalt on need kaks asja loomulikult erinevad.

Paljud neist mehhanismidest töötavad päringute tasemel (seetõttu ka «L7-proksi»). Näiteks, kui teenus Foo saadab HTTP-kutse teenusele Bar, võib linkerd-proxy Foo pooles läbi viia nutikat koormuse tasakaalustamist ja suunata kõned Foo-st Bar-i eksemplaridele sõltuvalt täheldatud viivitustest; see võib vajadusel päringu uuesti saata (kui see on idempotentne); see võib registreerida vastuskoodi ja ooteaja, jne. Sarnaselt võib linkerd-proxy Bar- pooles küsitluse tagasi lükata, kui see ei ole lubatud või on ületatud päringute limiit; see võib fikseerida oma viivituse jne.

Proxyd saavad "midagi teha" ka ühendusetasemel. Näiteks võib linkerd-proxy Foo küljel alustada TLS-ühendust, samas kui linkerd-proxy Bar küljel seda katkestab, ja mõlemad pooled saavad üksteise TLS-sertifikaate kontrollida*. See tagab mitte ainult krüpteeritud suhtluse teenuste vahel, vaid ka krüptograafiliselt turvalise viisi teenuste tuvastamiseks: Foo ja Bar saavad "tõestada", et nad on need, kes nad väidavad end olevat.

* "Üksteise" all mõeldakse, et kliendi sertifikaati kontrollitakse ka (suunatud TLS). "Klassikalisel" TLS-il, näiteks brauseri ja serveri vahel, kontrollitakse tavaliselt ainult ühe poole (serveri) sertifikaati.

Olenemata sellest, kas nad töötavad päringute või ühenduste tasemel, on oluline rõhutada, et kõik teenusetehnoloogia funktsioonid on operatiivsed loomuselt. Linkerd ei suuda muuta kasuliku koormuse semantikat - näiteks lisada välju JSON-fragmenti või teha muudatusi protobufis. Me räägime sellest olulisest aspektist hiljem, kui arutame ESB ja middleware'i.

See on funktsioonide kogum, mida pakub service mesh. Tekib küsimus: miks mitte rakendada neid otse rakenduses? Ja miks üldse tegeleda proksi kasutamisega?

Miks on service mesh hea idee

Kuigi service mesh'i võimalused on köitvad, seisneb selle peamine väärtus tegelikult mitte funktsioonides. Lõppude lõpuks saame rakendada neid otse rakenduses (hiljem näeme, et see oli service mesh'i päritolu). Kui proovida väljendada seda mõtet ühes lauses, siis service mesh'i väärtus on järgmine: rakendada neid otse rakenduses (hiljem näeme, et teenuse võrgu päritolu oli selline). Kui proovida seda mõtet väljendada ühe lausega, seisneb teenuse võrgu väärtus järgmistes: see pakub funktsioone, mis on kriitilise tähtsusega kaasaegse serveritarkvara toimimiseks, ühtlaselt kogu tech stack'is ja rakenduse koodist sõltumatult..

Analüüsime seda lauset.

«Funktsioonid, mis on kriitilise tähtsusega kaasaegse serveritarkvara toimimiseks» Kui loote tehingu serverirakendust, mis on seotud avaliku internetiga, vastu võtab välismaailmast pärinevaid päringuid ja vastab neile lühikese aja jooksul — näiteks veebirakendus, API-server ja enamik teisi kaasaegseid rakendusi — ning kui rakendate seda teenuste kogumina, mis omavahel sümbiootiselt suhtlevad, ja kui te pidevalt täiustate seda tarkvara, lisades uusi funktsioone, ja kui teil on hädasti vaja hoida seda süsteemi töökorras muudatuste protsessi käigus — siis õnnitleme teid, te tegelikult arendate tänapäeva serveritarkvara. Kõik need imeliselt olulised omadused, mida mainiti, on teie jaoks kriitilise tähtsusega. Rakendus peab olema usaldusväärne, turvaline ja teil peab olema võimalus jälgida, mida see teeb. Just need küsimused aitavad lahendada service mesh.

(Okay, minu veendumus, et see lähenemine on kaasaegne viis serveri tarkvara loomisel, hiilis eelmine lause siiski sisse. Teised eelistavad arendada monoliite, «reaktiivseid mikroteenuseid» ja muid asju, mis ei vasta ülaltoodud määratlusele. Nendel inimestel on kindlasti oma arvamus, mis erineb minu omast. Omalt poolt arvan, et nad «ei ole õiged» — kuigi igal juhul ei ole service mesh nende jaoks kuigi kasulik).

«Kogu stacki jaoks ühtne». Service mesh'i pakutavad funktsioonid ei ole lihtsalt kriitiliselt olulised. Need kehtivad kõigi rakenduses olevate teenuste suhtes, sõltumata sellest, millises keeles need on kirjutatud, millist raamistikku nad kasutavad, kes need kirjutas ja kuidas need on juurutatud, ning kõigist muudest arendamise ja rakendamise nüanssidest.

«Rakenduskoodist sõltumatu». Lõpuks ei paku service mesh mitte ainult ühtseid funktsioone kogu steigi jaoks, vaid teeb seda ka viisil, mis ei nõua rakenduse muutmist. Service mesh'i funktsionaalsuse põhi, sealhulgas seadistamise, uuendamise, haldamise, hoolduse jne ülesanded, on täiesti platvormi tasemel ja sõltumatu rakendusest. Rakendus võib muutuda, mõjutamata service mesh'i. Omakorda võib service mesh muutuda ilma rakenduse sekkumiseta.

Kokkuvõttes ei paku service mesh mitte ainult elutähtsaid funktsioone, vaid teeb seda ka globaalselt, ühtselt ja rakendusest sõltumatu viisi kaudu. Seetõttu, kuigi service mesh'i funktsionaalsust saab realiseerida teenuse koodis (näiteks raamatukoguna, mis on kaasatud igasse teenusesse), ei taga see lähenemine ühtsust ja sõltumatust, mis on service mesh'i puhul nii väärtuslikud.

Ja kõik, mis selleks vajalik, on hunnik proksisid! Luban, et väga varsti vaatame lähemalt nende prokside lisamisega seotud töötamisvõimekuse kulusid. Kuid kõigepealt peatugem ja vaatame seda sõltumatuse ideed erinevate vaatenurkade kaudu. inimesed.

Kellele on service mesh abiks?

Kuigi see võib olla ebamugav, peab mingi tehnoloogia muutuma tähtsaks osaks ökosüsteemist, et seda peaksid aktsepteerima inimesed. Nii et kes on huvitatud service mesh'ist? Kes saab selle kasutamisest kasu?

Kui arendate kaasaegset serveritarkvara, võite oma meeskonda 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 isegi jagunevad alamrollideks... (Siin on palju rääkida devops'i muutuvast iseloomust, mikroteenuste organisatsioonilisest mõjust jne. Kuid seni võtame need kirjeldused kui faktid.)

Selliste vaatenurkade kohaselt on service mesh selgelt kasu saajad platvormi omanikud. Lõppkokkuvõttes on platvormi meeskonna eesmärk luua sisemine platvorm, kus teenuste omanikud saavad teostada äriloogikat viisil, mis tagab nende maksimaalse sõltumatuse selle haldamise hämaratest detaljidest. Service mesh mitte ainult ei paku võimalusi, mis on kriitilise tähtsusega selle eesmärgi saavutamiseks, vaid teeb seda viisil, mis omakorda ei kehtesta teenuste omanikele sõltuvusi.

Teenuste omanikud saavad ka kasu, kuigi kaudsemal moel. Teenuse omaniku eesmärk on olla võimalikult produktiivne äriprotsessi loogika rakendamisel ning mida vähem peab ta hoolt kandma haldamise küsimuste pärast, seda parem. Selle asemel, et keskenduda näiteks taotluste kordamise või TLS poliitikate rakendamisele, saavad nad keskenduda eranditult äriülesannetele ja loota, et platvorm hoolitseb kõigi muude asjade eest. See on nende jaoks suur eelis.

Selliste platvormide ja teenuste omamise vahelise eristamise korral on organisatsiooniline väärtus raske ülehinnata. Usun, et see toob kaasa peamine kasu service mesh'i jaoks.

Otsustasime selle õppetunni, kui üks Linkerdi esimesi toetajaid rääkis meile, miks nad valisid service mesh'i: sest see võimaldas neil "minimeerida lobisemist". Siin on mõned üksikasjad: üks suur ettevõte migreeris oma platvormi Kubernetesesse. Kuna rakendus töötas konfidentsiaalse teabe alusel, soovisid nad krüpteerida kõik suhtlused klastrite vahel. Kuid olukord muutus keeruliseks, kuna oli sadu teenuseid ja sadu arendustiime. Perspektiiv suhelda kõikide nende ja veenda neid TLS-toetuse lisamise plaanidesse ei olnud sugugi meeldiv. Linkerdi seadistamisega siirdusid nad vastutuse arendajatelt (kelle jaoks oli see liigne vaev) platvormide jaoks, kelle jaoks see oli ülim prioriteet. Teisisõnu, Linkerd lahendas neile vähem tehnilise, vaid rohkem organisatsioonilise probleemi.

Lühidalt, service mesh on pigem sotsiaaltehniline lahendus. (Aitäh Cindy Sridharan selle terminiga tutvumise eest.)

Kas service mesh lahendab kõik mu probleemid?

Jah. Tähendab, ei!

Kui vaadata kolme eelpool mainitud funktsioonide klassi: usaldusväärsus, turvalisus ja jälgitavus — siis on selge, et service mesh ei ole täielik lahendus kumbagi neist probleemidest. Kuigi Linkerd suudab edastada korduvaid päringuid (kui ta teab, et need on idempotentsed), ei suuda ta otsustada, mida kasutajale tagasi anda, kui teenus on täielikult kokku kukkunud — sellised otsused peaks tegema rakendus. Linkerd suudab jälgida edukaid päringuid, kuid ta ei saa vaadata teenuse sisse ja pakkuda selle sisemisi mõõdikuid — selline tööriist peab olema rakenduses. Ja kuigi Linkerd suudab korraldada mTLS-i, vajavad tõhusad turvalisuse lahendused palju enamat.

Service mesh pakub nende valdkondade funktsioonide osahulka, mis kuuluvad platvormi funktsioonidesse. Selle all mõistan ma funktsioone, mis:

1. On sõltumatud äri loogikast. Kuidas ehitatakse Foo ja Bar vahelisi kutsealuseid histogramme, ei sõltu absoluutselt sellest, miks Foo kutsub Bar.
2. Õigesti rakendamine on keeruline. Linkerdis parametreeritakse taaskatsetused igasuguste keerukate elementidega, nagu taaskatsetuste eelarved (retry budgets), kuna lihtne lähenemine nende rakendamisele toob tõenäoliselt kaasa nn „taaskatsetuste tormi” (retry storm) ja muid jaotatud süsteemidele iseloomulikke probleeme.
3. On kõige tõhusamad, kui neid rakendatakse järjekindlalt. TLS mehhanism omab mõtet ainult siis, kui seda rakendatakse igal pool.

Kuna need funktsioonid on rakendatud proksi tasemel (mitte rakenduse tasemel), pakub service mesh neid tasemel platvorm, mitte rakenduses. Seega pole oluline, millises keeles teenused on kirjutatud, millist raamistikku nad kasutavad, kes need kirjutas ja miks. Proksid töötavad välja kõik need üksikasjad ning selle funktsionaalsuse aluseks olevad ülesanded, sealhulgas konfigureerimine, uuendamine, hooldamine jne, jäävad täielikult platvormi tasemele.

Näiteks service mesh'i võimalused

Kokkuvõtteks tahan öelda, et service mesh ei ole täielik lahendus usaldusväärsuse, jälgimise või turvalisuse tagamiseks. Nende valdkondade ulatus nõuab kohustuslikku osalemist teenuste omanike, Ops/SRE meeskondade ja teiste ettevõtte osaliste poolt. Service mesh pakub ainult platformi tasandil „ülevaadet” igas neist valdkondadest.

Miks on service mesh just praegu nii populaarne?

Tõenäoliselt mõtlete hetkel: okei, kui service mesh on nii hea, siis miks me ei hakanud kümme aastat tagasi miljonit proxyt üles seadma?

On selle küsimuse lihtne vastus: kümme aastat tagasi ehitati kõik monoliite ja service mesh'i ei vajatud. See on tõsi, kuid minu arvates kaob sellise vastuse puhul ära põhjus. Isegi kümme aastat tagasi arutleti mikroteenuste kontseptsiooni kui perspektiivset viisi suurte süsteemide loomiseks laialdaselt ning seda rakendati sellistes ettevõtetes nagu Twitter, Facebook, Google ja Netflix. Üldine arusaam — vähemalt nendes tööstuse osades, millega ma kokku puutusin — oli see, et mikroteenused on "õige viis" suurte süsteemide loomiseks, isegi kui see oli põrgulikult keeruline.

Muidugi, kuigi kümme aastat tagasi olid ettevõtteid, kes kasutasid mikroteenuseid, ei pannud nad sugugi prokse igale poole, et luua service mesh'i. Kuid kui lähemalt vaadata, siis nad tegid midagi sarnast: paljudes neist ettevõtetest oli ette nähtud, et tuleb kasutada erilist sisemist raamatukogu võrgu suhtlemiseks (mida mõnikord nimetatakse paksu kliendi raamatukoguks, fat client library).

Netflixil oli Hysterix, Google'il Stubby ja Twitteril Finagle'i teek. Finagle, näiteks, oli kohustuslik iga uue teenuse jaoks Twitteris. See haldas nii kliendi- kui ka serveripoolseid ühendusi, võimaldas korduvaid päringuid, toetas päringute marsruutimist, koormuse jaotamist ning mõõtmisi. See tagas järjepideva usaldusväärsuse ja jälgitavuse kihi kogu Twitteri tehnoloogiapuhvris, sõltumata teenuse konkreetsest tegevusvaldkonnast. Loomulikult töötas see ainult JVM-keelte puhul ja põhines programmeerimismudelit, mida tuli rakenduses kasutada. Siiski olid selle funktsioonid peaaegu samad, mis service mesh'il. (Tegelikult oli Linkerdi esimene versioon lihtsalt Finagle, ümbritsetud proksiga.)

Nii et kümme aastat tagasi olid olemas mitte ainult mikroteenused, vaid ka spetsiaalsed proto-service-mesh raamatukogud, mis lahendasid samu probleeme, mida service mesh lahendab tänapäeval. Siiski ei olnud sel ajal service mesh'i. Enne selle tekkimist pidi toimuma veel üks muutus.

Ja siin peitub sügavam vastus, mis on seotud teise muutusega, mis on toimunud viimase 10 aasta jooksul: mikroteenuste juurutamise kulud on tõusnud järsult. Ülalmainitud ettevõtted, kes kasutasid mikroteenuseid kümme aastat tagasi: Twitter, Netflix, Facebook, Google, — olid tohutu suurusega ja suure ressursiga ettevõtted. Neil oli mitte ainult vajadus, vaid ka võimalus luua, juurutada ja hallata suuri mikroteenusel põhinevaid rakendusi. Twitteri inseneride energia ja pingutused monoliidisüsteemilt mikroteenuste lähenemisele ülemiseks on lihtsalt hämmastavad. (Ausalt öeldes, nagu ka see, et see õnnestus.) Sellised infrastruktuuri käigud olid sel ajal väiksematele ettevõtetele võimatud.

Liigume olevikku. Täna on olemas idufirmad, kus mikroteenuste ja arendajate suhe on 5:1 (või isegi 10:1), ning nad saavad sellega edukalt hakkama! Kui 5-liikmeline idufirma suudab vaevata hallata 50 mikroteenust, tähendab see, et midagi on ilmselgelt vähendanud nende rakendamise kulusid.

1500 mikroteenust Monzo's; iga rida — ettenähtud võrgureegel, mis lubab liiklust

Mikroteenuste käitamise kulude järsk vähenemine on tulemuseks ühele protsessile: konteinerite populaarsuse kasvule ja orkestritele. Just see on põhjus, miks service mesh'i kasutamine on muutunud atraktiivseks. Üks ja sama tehnoloogia on teinud nii service mesh'i kui ka mikroteenused atraktiivseks: Kubernetes ja Docker.

Miks? Noh, Docker lahendab ühe suure probleemi — pakendamise probleemi. Pakendades rakenduse ja selle (mitte-võrgulised) töötamise sõltuvused konteinerisse, muudab Docker rakenduse vahetatavaks üksuseks, mida saab paigaldada ja käivitada igal pool. Samal ajal lihtsustab see oluliselt käitamiseks mitmekeelse steigi: kuna konteiner on täitmisaatom, ei ole paigaldamise ja käitamise eesmärkide jaoks oluline, mis on sees, olgu see rakendus JVM, Node, Go, Python või Ruby. Sa lihtsalt käivitad selle, ja kõik.

Kubernetes viib kõik uuele tasemele. Nüüd, kui on palju "käivitatavaid asju" ja mitmeid masinaid, millel neid käitada, on vajadus tööriista järele, mis suudab neid üksteisega seostada. Laiemas mõttes annate Kubernetes'ele hulga konteinerite ja hulga masinaid, ning see seob need omavahel (loomulikult on see dünaamiline ja pidevalt muutuva protsess: uued konteinerid liiguvad süsteemis, masinad käivituvad ja peatatakse jne. Kuid Kubernetes arvestab kõigega sellega).

Pärast Kubernetes'e seadistamist on ajakulud ühe teenuse juurutamiseks ja hooldamiseks vähe erinevad kuludest, mis on vajalikud kümne teenuse juurutamiseks ja hooldamiseks (tegelikult on need praktiliselt sarnased ka 100 teenuse puhul). Lisa sellele konteinerid kui pakendi mehhanism, mis edendab mitme keele realiseerimist, ja saad hulga uusi rakendusi, mis on realiseeritud mikroteenustena, kirjutatud erinevates keeltes — just sellises keskkonnas, mille jaoks service mesh on nii hästi sobiv.

Nii, oleme jõudnud vastuseni küsimusele, miks service meshi idee on just nüüd populaarsust kogunud: see ühtlus, mida Kubernetes teenustele tagab, on otseselt rakendatav service mesh'i haldamiseks. Te pakite pöördproksi konteineritesse, lasete Kubernetesel neid kuhugi kinnitada, ja voila! Tulemuseks on service mesh, samal ajal kui kogu selle paigaldamise mehhanismi haldab Kubernetes. (Kõige vähem, kõrge alt vaadates. Loomulikult on selles protsessis palju nüansse.)

Kokkuvõttes: põhjus, miks service mesh on just nüüd, mitte kümme aastat tagasi populaarsust kogunud, on see, et Kubernetes ja Docker on mitte ainult oluliselt suurendanud nõudlust selle järele, lihtsustades rakenduste elluviimist mitmekeelsena mikroteenuste kogumina, vaid ka oluliselt vähendanud kulusid selle haldamiseks, tagades sidecar-proxide paigaldamise ja toetamise mehhanismid.

Miks on nii palju juttu service mesh'ist?

Hoiatus: selles osas kasutan ma igasuguseid oletusi, arva ja spekulatsioone ning siseteavet.

Otsides fraasi „service mesh” leiate hulgaliselt üle töötatud madala kalorsusega sisu, kummalisi projekte ja kaleidoskoopilisi moonutusi, mis väärivad kaja kaamerat. See on iseloomulik igale uuele ja moes olevale tehnoloogiale, kuid service meshi puhul on probleem eriti terav. Miks?

Noh, osaliselt on see minu süü. Olen pühendunud Linkerdi ja service mesh'i edendamisele igal võimalusel, läbi lugematute blogikirjutiste ja artiklite, nagu see. Kuid ma ei ole nii võimas. Et sellele küsimusele tõeliselt vastata, tuleb rääkida veidi üldisest olukorrast. Ja sellest ei saa rääkida, mainimata ühte projekti: Istio — avatud lähtekoodiga service mesh, mida arendavad koos Google, IBM ja Lyft.

(Nendel kolmel ettevõttel on täiesti erinevad rollid: Lyfti osalus näib piirduvat ainult nimega; nad on Envoy autorid, kuid ei kasuta Istiot ega osale selle arendamisel. IBM osaleb Istio arendamises ja kasutab seda. Google osaleb aktiivselt Istio arendamises, kuid, nii palju kui ma tean, ei kasuta seda tõeliselt.)

Istio projekt paistab silma kahe peamise omadusega. Esiteks, need on tohutud turunduspingutused, mida Google, eriti, sellele suunab. Minu hinnangul on enamik inimesi, kes on teadlikud service mesh kontseptsioonist, praegu sellest esmakordselt kuulnud tänu Istio'le. Teine omadus on see, kui halvasti Istio vastu on võetud. Kuigi ma olen selles küsimuses selgelt huvitatud osaline, püüdes jääda võimalikult objektiivseks, ei saa ma siiski mitte... märgi äärmiselt negatiivne meeleolu, mitte just tüüpiline (kuigi mitte ainulaadne: meelde tuleb systemd, võrdlus on toimunud juba korduvalt…) avatud lähtekoodiga projekti puhul.

(Tegelikkuses näib, et Istio-l on probleemid mitte ainult keerukuse ja kasutajakogemuse, vaid ka jõudlusega. Näiteks, Linkerd’i jõudluse hindamise, mille toimus kolmanda osapoole korral, avastas spetsialistid olukordi, kus Istio viivitused (tail latency) olid 100 korda suuremad kui sama näitaja Linkerd’il, samuti olukordades, kus ressursside puudus tõi kaasa, et Linkerd töötas eduka jätkamiseks, samas kui Istio lõpetas täielikult töö.)

Jättes kõrvale minu teooriad selle kohta, miks see nii juhtus, arvan, et service mesh'i ümber käiv suur mürarikkus on tingitud just Google'i osalusest. Nimelt kolme järgmise teguri kombinatsioonist:

1. Google'i pealetükkiv reklaamimine Istio;
2. vastav mitte-kiitev, kriitiline suhtumine projekti;
3. viimase aja kiire tõus Kubernetes'e populaarsuses, mille mälestused on endiselt värsked.

Koos need tegurid ühinevad mingiks uinutavaks, hapnikuvabaks keskkonnaks, kus ratsionaalse otsustamise võime väheneb, ja alles jääb ainult imeliku variandi tulbimanial.

Linkerd'i vaatenurgast on see... ma kirjeldaksin seda kui kahtlast kasu. Suurepärane on see, et teenusevõrk on jõudnud peavoolu — seda ei olnud 2016. aastal, kui Linkerd esmakordselt ilmus ja oli tõeliselt keeruline tähelepanu projektile tõmmata. Nüüd ei ole sellist probleemi! Kuid halb on see, et teenusevõrgu olukord on täna nii segane, et on praktiliselt võimatu mõista, millised projektid tõeliselt kuuluvad teenusevõrgu kategooriasse (rääkimata sellest, et mõista, milline neist sobib konkreetse kasutusjuhtumi jaoks kõige paremini). See takistab kindlasti kõiki (ja kindlasti on mõnedel juhtudel Istio või mõni muu projekt sobivam kui Linkerd, kuna viimane ei ole siiski universaalne lahendus).

Linkerd'i poolt oli meie strateegia ignoreerida müra, keskenduda jätkuvalt kogukonna tegelike probleemide lahendamisele ja põhimõtteliselt oodata, kuni põnevus vaibub. Lõppkokkuvõttes hype väheneb ja me saame rahulikult edasi töötada.

Kuni selle ajani peame me kõik natuke kannatama.

Kas teenusevõrk on kasulik mulle, tagasihoidlikule tarkvarainsenerile?

Selle küsimuse vastus sõltub järgnevast küsitlusest:

Kas tegelete ainult äri loogika rakendamisega? Sellisel juhul ei ole service mesh teile vajalik. Loomulikult võite sellega huvi tunda, kuid ideaalis ei peaks service mesh teie keskkonda otseselt mõjutama. Jätkake oma töö tegemist selle nimel, mille eest teile makstakse.

Kas te toetate platvormi ettevõttes, mis kasutab Kubernetes't? Jah, sel juhul on service mesh teil vajalik (kui te ei kasuta K8s lihtsalt monoliidi käitamiseks või mahutöötluseks – aga siis tahaksin ma küsida, miks teile K8s vajalik on). Tõenäoliselt satute olukorda, kus on palju mikroteenuseid, mida on kirjutanud erinevad inimesed. Kõik need suhtlevad omavahel ja on seotud runtime-sõltuvuste kogumisse, ja teil on vaja leida viis sellega toime tulla. Kubernetes'i rakendamine võimaldab valida service mesh'i 'oma vajaduste järgi'. Selleks tutvuge nende võimaluste ja omadustega ning vastake küsimusele, kas mõni olemasolev projekt sobib teile (soovitan alustada uurimist Linkerd'ist).

Kas te töötate platvormi kallal ettevõttes, mis EI kasuta Kubernetes't, vaid kasutab mikroteenuseid? Sel juhul on service mesh teile kasulik, kuid selle kasutamine ei ole triviaalne. Muidugi saate simuleerida service mesh'i toimimist, paigaldades hulga vahendusi, kuid Kubernetes'e oluline eelis on just juurutusmudel: nende vahendite käsitsi hooldamine nõuab palju rohkem aega, vaeva ja kulutusi.

Kas te vastutate platvormi eest ettevõttes, mis töötab monoliitidega? Sel juhul ei ole service mesh tõenäoliselt vajalik. Kui töötate monoliitidega (või isegi monoliitide kogumitega), millel on selgelt määratletud ja harva muutuvaid suhtlemismustreid, ei paku service mesh teile suurt midagi. Seega võite lihtsalt ignoreerida ja loota, et see kaob nagu halb unenägu...

Kokkuvõte

Arvatavasti ei peaks service mesh'i nimetama maailma «kõige hüpsamaks tehnoloogiaks» — see kahtlane au kuulub tõenäoliselt bitcoinile või tehisintellektile. Võib-olla on ta esimeses viies. Kuid kui läbida müra ja segaduse kihtide kaudu, saab selgeks, et service mesh toob tõelist kasu neile, kes arendavad rakendusi Kuberneteses.

Soovin, et te prooviksite Linkerd’i — selle installimine Kubernetesesse (või isegi Minikube’is sülearvutis) võtab aega umbes 60 sekundit, ja te saate ise näha, millest ma räägin.

KKK

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

— Aga MA EI SOOVI kasutada service mesh'i!
— No ja ei peagi! Lihtsalt loe minu ülaltoodud küsitlust, et aru saada, kas tasub tutvuda vähemalt selle põhialustega.

— Kas see ei ole lihtsalt vana hea ESB/middleware uue kastmena?
— Service mesh tegeleb operatiivsete loogikate, mitte sisuga. See oli suurim puudus ettevõtte teenuse bussist (ESB). Selle jaotuse säilitamine aitab service mesh'il vältida sama saatust.

— Milles service mesh erineb API-lüüsidest?
— Selle kohta on miljon artiklit. Lihtsalt googeldage.

— Kas Envoy on service mesh?
— Ei, Envoy ei ole service mesh, vaid see on vaheline server. Seda saab kasutada service mesh'i korraldamiseks (ja paljuks muuks — see on universaalne vaheline server). Kuid iseenesest ei ole see service mesh.

— Kas Network Service Mesh on service mesh?
— Ei. Malepärast, see ei ole service mesh (kuidas teile meeldib turunduse imed?).

— Kas service mesh aitab mu reaktiivses asünkroonilises süsteemis, mis põhineb sõnumi järjekordadel?
— Ei, service mesh ei aita.

— Millist service mesh'i peaksin kasutama?
— Linkerd, see on iseenesest mõistetav.

— Artikkel on jama! / Autor tuleks sundida!
— Palun jagage selle linki kõigi oma sõpradega, et nad saaksid sellest veenduda!

Tänud

Kuna võisite pealkirjast arvata, siis see artikkel sai inspiratsiooni Jay Krepsi fantastilisest teosest „The Log: What every software engineer should know about real-time data’s unifying abstraction”. Ma kohtusin Jay'ga kümme aastat tagasi, kui tegin Intervjuud LinkedInis, ja sellest ajast alates on ta olnud mulle inspiratsiooniks.

Kuigi meeldib end nimetada „Linkerdi arendajaks”, on tõde see, et olen pigem README.md faili hooldaja projektis. Täna töötab Linkerdi kallal väga, väga, väga palju inimesi, ja see projekt ei oleks õnnestunud ilma imelise mängijate ja kasutajate kogukonna panuseta.

Ja lõpetuseks eriline tänu Linkerdi loojaile, Oliver Gould (primus inter pares), kes koos minuga hüppas aastaid tagasi sügavale sellesse teenuste võrku seotud kaost.

P.S. tõlkija märkused

Lugege ka meie blogist:

• «Mis on service mesh ja miks see on vajalik [kogukonna rakendusele, mis põhineb mikroteenustel]?»;
• «Traefik 2.0: teenuste võrgu uuendamine TCP toe ja uue veebivahendiga»;
• «Maesh — uus lihtne teenuste võrk Kuberneteselt Traefiku autoritelt»;
• «Tagasi mikroteenuste juurde koos Istio. Osa 1»;
• «Conduit — kerge teenuste võrk Kuberneteselt».

Allikas: habr.com