Huomautus. käännös: Palveluverkko on ilmiö, jolla ei ole vielä vakaata käännöstä venäjäksi (yli 2 vuotta sitten ehdotimme vaihtoehtoa "verkko palveluille", ja vähän myöhemmin jotkut kollegat alkoivat aktiivisesti edistää "palveluseula" -yhdistelmää). Jatkuva tästä teknologiasta puhuminen on johtanut tilanteeseen, jossa markkinoinnin ja tekniset komponentit kietoutuvat liian tiiviisti toisiinsa. Tämä upea materiaali yhdeltä alkuperäisen termin kirjoittajista on tarkoitettu selkeyttämään insinöörejä ja muita.
Sarjakuva kohteesta
Esittely
Jos olet ohjelmistosuunnittelija, joka työskentelee jossain taustajärjestelmätilassa, termi "palveluverkko" on luultavasti jo juurtunut vahvasti mieleesi parin viime vuoden aikana. Outo sattuman ansiosta tämä lause valtaa alaa yhä enemmän, ja siihen liittyvät hype- ja kampanjatarjoukset kasvavat kuin lumipallo, joka lensi alamäkeä eikä osoita merkkejä hidastumisesta.
Palveluverkko syntyi pilven natiiviekosysteemin hämärissä, puolueellisissa vesissä. Valitettavasti tämä tarkoittaa, että suuri osa sitä ympäröivästä kiistasta vaihtelee "vähäkalorisesta puheesta" - teknisellä termillä - suoranaiseen hölynpölyyn. Mutta jos leikkaat kaiken melun, huomaat, että palveluverkolla on hyvin todellinen, määritelty ja tärkeä tehtävä.
Tässä viestissä yritän tehdä juuri sen: tarjota rehellinen, syvällinen, insinöörikeskeinen opas palveluverkkoon. En aio vastata vain kysymykseen: "Mikä se on?", - mutta myös "Miksi?"Ja "Miksi nyt?". Lopuksi yritän hahmotella, miksi (mielestäni) juuri tämä tekniikka on aiheuttanut niin hullua kohua, mikä on sinänsä mielenkiintoinen tarina.
Kuka minä olen
Hei kaikki! Nimeni on . Olen yksi tekijöistä — aivan ensimmäinen palveluverkkoprojekti ja hanke, joka on syyllinen termin ilmenemiseen huoltoverkko sellaisenaan (anteeksi kaverit!). (Huomioi käännös.: Muuten, tämän termin ilmaantumisen kynnyksellä, yli 2,5 vuotta sitten, käänsimme jo saman kirjailijan varhaisen materiaalin nimeltä "".) Minä myös päätän on startup, joka luo hienoja palveluverkkoja, kuten Linkerd ja .
Voit luultavasti arvata, että minulla on hyvin puolueellinen ja subjektiivinen mielipide tästä asiasta. Yritän kuitenkin pitää puolueellisuuden mahdollisimman pienenä (lukuun ottamatta yhtä osaa: "Miksi palveluverkosta puhutaan niin paljon?", - jossa jaan edelleen ennakkokäsitykseni). Teen myös parhaani, jotta tämä opas olisi mahdollisimman objektiivinen. Konkreettisissa esimerkeissä luotan ensisijaisesti Linkerdin kokemukseen, mutta tuon esiin eroja (jos sellaisia on), joita tiedän muiden palveluverkkotyyppien toteutuksessa.
Okei, aika siirtyä herkkujen pariin.
Mikä on palveluverkko?
Kaikesta hypetystä huolimatta palveluverkon rakenne on melko yksinkertainen. Tämä on vain joukko käyttäjätilan välityspalvelimia, jotka sijaitsevat palveluiden "vieressä" (puhumme vähän siitä, mitä "seuraava" on myöhemmin), sekä joukko ohjausprosesseja. Välityspalvelimia kutsutaan kollektiivisesti datataso, ja ohjausprosesseja kutsutaan ohjaustaso. Datataso sieppaa puheluita palveluiden välillä ja tekee niillä "kaikenlaisia asioita"; Ohjaustaso vastaavasti koordinoi välityspalvelimen toimintaa ja tarjoaa pääsyn sinulle, ts. operaattorille API:lle, jolloin verkkoa voidaan manipuloida ja mitata kokonaisuutena.
Millainen välityspalvelin tämä on? Tämä on Layer 7 -tietoinen TCP-välityspalvelin (eli OSI-mallin kerroksen 7 "ottaminen huomioon") kuten HAProxy ja NGINX. Voit valita välityspalvelimen mieleiseksesi; Linkerd käyttää yksinkertaisesti nimettyä Rust-välityspalvelinta . Kokosimme sen erityisesti huoltoverkkoa varten. Muut silmät suosivat muita välityspalvelimia (Envoy on yleinen valinta). Välityspalvelimen valinta on kuitenkin vain toteutuskysymys.
Mitä nämä välityspalvelimet tekevät? Ilmeisesti ne välittävät puheluita palveluille ja palveluista (tiukasti sanottuna ne toimivat välityspalvelimena ja käänteisenä välityspalvelimena ja käsittelevät sekä saapuvia että lähteviä puheluita). Ja ne toteuttavat toimintosarjan, joka keskittyy puheluihin между palvelut. Tämä keskittyminen palveluiden väliseen liikenteeseen erottaa palvelun mesh-välityspalvelimen esimerkiksi API-yhdyskäytävistä tai sisääntulovälityspalvelimista (jälkimmäiset keskittyvät klusteriin ulkomaailmasta tuleviin puheluihin). (Huomautus. käännös: Jos haluat vertailla olemassa olevia Kubernetesin Ingress-ohjaimia, joista monet käyttävät jo mainittua Envoyta, katso .)
Joten, olemme selvittäneet datatason. Ohjaustaso on yksinkertaisempi: se on joukko komponentteja, jotka tarjoavat kaiken mekaniikan, jota tietotaso tarvitsee toimiakseen koordinoidusti, mukaan lukien palvelunhaku, TLS-varmenteiden myöntäminen, metrien yhdistäminen jne. Tietotaso ilmoittaa ohjaustasolle sen käyttäytyminen; ohjaustaso puolestaan tarjoaa API:n, jonka avulla voit muuttaa ja valvoa tietotason toimintaa kokonaisuutena.
Alla on kaavio Linkerdin ohjaustasosta ja datatasosta. Kuten näet, ohjaustaso sisältää useita eri komponentteja, mukaan lukien Prometheus-instanssi, joka kerää mittareita välityspalvelimista, sekä muita komponentteja, kuten esim. destination (palvelun löytäminen), identity (varmentaja, CA) ja public-api (verkon ja CLI:n päätepisteet). Sitä vastoin datataso on yksinkertainen linkerd-välityspalvelin sovellusesiintymän vieressä. Tämä on vain logiikkakaavio; Tosimaailmassa käytössäsi saattaa olla kolme kopiota kustakin ohjaustason komponentista ja satoja tai tuhansia välityspalvelimia tietotasossa.
(Tämän kaavion siniset suorakulmiot symboloivat Kubernetes-palkin rajoja. Näet, että linkerd-välityspalvelimella varustetut säilöt ovat samassa kotelossa kuin sovellussäiliöt. Tämä malli tunnetaan nimellä sivuvaunukontti.)
Palveluverkkoarkkitehtuurilla on useita tärkeitä seurauksia. Ensinnäkin, koska välityspalvelimen tehtävänä on siepata puheluita palveluiden välillä, palveluverkolla on järkeä vain, jos sovelluksesi on luotu tietylle palvelujoukolle. Mesh voidaan muodostaa käyttää monoliittien kanssa, mutta tämä on selvästi tarpeetonta yhden välityspalvelimen vuoksi, eikä sen toiminnallisuudelle todennäköisesti ole kysyntää.
Toinen tärkeä seuraus on, että palveluverkko vaatii valtava välityspalvelinten määrä. Itse asiassa Linkerd liittää linkerd-välityspalvelimen jokaisen palvelun jokaiseen esiintymään (muut toteutukset lisäävät välityspalvelimen jokaiseen solmuun/isäntään/virtuaalikoneeseen. Se on joka tapauksessa paljon). Tällainen välityspalvelinten aktiivinen käyttö aiheuttaa itsessään useita lisäkomplikaatioita:
- Datatason välityspalvelinten on oltava nopeasti, koska jokaista puhelua kohden on pari puhelua välityspalvelimelle: yksi asiakaspuolella, yksi palvelinpuolella.
- Myös välityspalvelimet pitäisi olla pieni и kevyt. Jokainen kuluttaa muistia ja prosessoriresursseja, ja tämä kulutus kasvaa lineaarisesti sovelluksen mukana.
- Tarvitset mekanismin, jolla voit ottaa käyttöön ja päivittää suuren määrän välityspalvelimia. Käsin tekeminen ei ole vaihtoehto.
Yleisesti ottaen palveluverkko näyttää tältä (ainakin lintuperspektiivistä): otat käyttöön joukon käyttäjätilan välityspalvelimia, jotka "tekevät jotain" sisäisellä, palvelujen välisellä liikenteellä, ja käytät ohjaustasoa valvomaan ja hallitsemaan niitä.
Nyt on aika kysyä "miksi?"
Mihin palveluverkko on tarkoitettu?
Niille, jotka kohtasivat ensimmäisen kerran ajatuksen palveluverkosta, voitaisiin antaa anteeksi hieman pelottava olo. Palveluverkkosuunnittelu tarkoittaa, että se ei vain lisää sovelluksen latenssia, vaan myös lisää kuluttaa resurssit ja lisää joukko uusia mekanismeja infrastruktuuriin. Ensin määrität palveluverkon, ja sitten yhtäkkiä huomaat tarvitsevasi satoja (ellei tuhansia) välityspalvelimia. Kysymys kuuluu, kuka tekee tämän vapaaehtoisesti?
Vastaus tähän kysymykseen koostuu kahdesta osasta. Ensinnäkin näiden välityspalvelinten käyttöönottoon liittyviä transaktiokustannuksia voidaan vähentää merkittävästi joidenkin ekosysteemissä tapahtuvien muutosten ansiosta (lisää tästä myöhemmin).
Toiseksi, tällainen laite on itse asiassa loistava tapa tuoda järjestelmään lisälogiikkaa. Ei vain siksi, että palveluverkko voi lisätä paljon uusia toimintoja, vaan myös siksi, että se voidaan tehdä häiritsemättä ekosysteemiä. Itse asiassa koko palveluverkkomalli perustuu tähän lähtökohtaan: monipalvelujärjestelmässä riippumatta siitä, mitä tehdä yksittäiset palvelut, liikenne heidän välillään on ihanteellinen paikka toiminnallisuuden lisäämiseen.
Esimerkiksi Linkerdissä (kuten useimmissa meshissä) toiminnallisuus keskittyy ensisijaisesti HTTP-kutsuihin, mukaan lukien HTTP/2 ja gRPC*. Toiminnallisuus on melko rikas - se voidaan jakaa kolmeen luokkaan:
- Ominaisuudet liittyvät luotettavuus. Toistuvat pyynnöt, aikakatkaisut, kanaarilainen lähestymistapa (liikenteen jakaminen/uudelleenohjaus) jne.
- Ominaisuudet liittyvät seurantaa. Onnistumisasteiden, viiveiden ja pyyntömäärien yhdistäminen kullekin palvelulle tai yksittäiselle suunnalle; palveluiden topologisten karttojen rakentaminen jne.
- Ominaisuudet liittyvät turvallisuus. Keskinäinen TLS, kulunvalvonta jne.
* Linkerdin näkökulmasta gRPC ei käytännössä eroa HTTP/2:sta: se käyttää vain protobufia hyötykuormassa. Kehittäjän näkökulmasta nämä kaksi asiaa ovat tietysti erilaisia.
Monet näistä mekanismeista toimivat pyyntötasolla (siis "L7-välityspalvelin"). Jos Foo-palvelu esimerkiksi soittaa HTTP-puhelun Bar-palvelulle, Foo-puolen linkerd-välityspalvelin voi suorittaa älykkään kuormituksen tasapainotuksen ja reitittää puhelut Foosta Bar-esiintymiin havaitun latenssin perusteella; se voi toistaa pyynnön tarvittaessa (ja jos se on idempotentti); se voi tallentaa vastauskoodin ja aikakatkaisun jne. Vastaavasti Bar-puolen linkerd-proxy voi hylätä pyynnön, jos se ei ole sallittua tai pyyntöraja ylittyy; voi tallentaa viivettä tms.
Välityspalvelimet voivat "tehdä jotain" myös yhteystasolla. Esimerkiksi linkerd-proxy Foo-puolella voi aloittaa TLS-yhteyden, ja linkerd-proxy Bar-puolella voi katkaista sen, ja molemmat osapuolet voivat tarkistaa toistensa TLS-varmenteet*. Tämä tarjoaa paitsi palveluiden välisen salauksen, myös kryptografisesti turvallisen tavan tunnistaa palvelut: Foo ja Bar voivat "todistaa" olevansa sitä, mitä he sanovat olevansa.
* "Ystävän molemminpuolinen" tarkoittaa, että myös asiakkaan varmenne on varmennettu (keskinäinen TLS). "Perinteisessä" TLS:ssä, esimerkiksi selaimen ja palvelimen välillä, yleensä vain yhden puolen (palvelimen) varmenne varmistetaan.
Riippumatta siitä toimivatko ne pyyntö- vai yhteystasolla, on tärkeää korostaa, että kaikki palveluverkkotoiminnot ovat toiminnassa merkki. Linkerd ei pysty muuttamaan hyötykuorman semantiikkaa - esimerkiksi lisäämällä kenttiä JSON-fragmenttiin tai tekemällä muutoksia protobufiin. Puhumme tästä tärkeästä ominaisuudesta myöhemmin, kun puhumme ESB:stä ja väliohjelmistosta.
Tämä on joukko ominaisuuksia, joita palveluverkko tarjoaa. Herää kysymys: miksi et toteuttaisi niitä suoraan sovelluksessa? Ja miksi ylipäätään vaivautua välityspalvelimen kanssa?
Miksi huoltoverkko on hyvä idea
Vaikka palveluverkon ominaisuudet ovat jännittäviä, sen ydinarvo ei varsinaisesti piile sen ominaisuuksissa. Lopulta me Voi toteuttaa ne suoraan sovelluksessa (näemme myöhemmin, että tämä oli palveluverkon alkuperä). Yritetään tiivistää se yhteen lauseeseen, palveluverkon arvo on: se tarjoaa ominaisuuksia, jotka ovat tärkeitä nykyaikaisen palvelinohjelmiston käyttämiselle johdonmukaisella tavalla koko pinossa ja sovelluskoodista riippumatta.
Analysoidaan tämä ehdotus.
«Ominaisuudet, jotka ovat tärkeitä nykyaikaisen palvelinohjelmiston käyttämiselle" Jos olet luomassa tapahtumapalvelinsovellusta, joka on yhteydessä julkiseen Internetiin ja joka hyväksyy ulkomaailman pyynnöt ja vastaa niihin lyhyessä ajassa - esimerkiksi verkkosovellus, API-palvelin ja suurin osa muista nykyaikaisista sovelluksista - ja jos otat sen käyttöön palvelujoukona, jotka ovat synkronisesti vuorovaikutuksessa toistensa kanssa, ja jos päivität tätä ohjelmistoa jatkuvasti, lisäät uusia ominaisuuksia ja jos joudut pitämään tämän järjestelmän toimintakunnossa muutosprosessin aikana - tässä onnittelut, olet luomassa nykyaikaista palvelinohjelmistoa. Ja kaikki nämä yllä luetellut upeat ominaisuudet osoittautuvat itse asiassa kriittisiksi sinulle. Sovelluksen on oltava luotettava, turvallinen ja sinun on voitava tarkkailla, mitä se tekee. Juuri näitä kysymyksiä Service Mesh auttaa ratkaisemaan.
(OK, edellinen kappale sisältää edelleen uskoni, että tämä lähestymistapa on nykyaikainen tapa luoda palvelinohjelmistoja. Toiset kehittävät mieluummin monoliitteja, "reaktiivisia mikropalveluita" ja muita asioita, jotka eivät kuulu yllä olevan määritelmän piiriin. Näillä ihmisillä on luultavasti mielipide on erilainen kuin minun. Minusta puolestaan ne ovat "vääriä" - vaikka joka tapauksessa palveluverkko ei ole heille kovin hyödyllinen).
«Univormu koko pinolle" Palveluverkon tarjoamat toiminnot eivät ole vain kriittisiä. Ne koskevat kaikkia sovelluksen palveluita riippumatta siitä, millä kielellä ne on kirjoitettu, mitä puitteita ne käyttävät, kuka ne on kirjoittanut, miten ne on otettu käyttöön ja muista niiden kehittämisen ja käytön hienouksista.
«Sovelluskoodista riippumaton" Lopuksi, palveluverkko ei ainoastaan tarjoa yhtenäisiä toimintoja koko pinossa, vaan myös tavalla, joka ei edellytä sovelluksen muokkaamista. Palveluverkkotoimintojen perusperusta, mukaan lukien konfigurointi-, päivitys-, käyttö-, ylläpito- jne. tehtävät, on täysin alustatasolla ja sovelluksesta riippumaton. Sovellus voi muuttua vaikuttamatta palveluverkkoon. Palveluverkko puolestaan voi muuttua ilman sovelluksen osallistumista.
Lyhyesti sanottuna palveluverkko ei ainoastaan tarjoa elintärkeitä toimintoja, vaan tekee sen myös maailmanlaajuisesti, yhtenäisellä ja sovelluksesta riippumattomalla tavalla. Ja niinpä, vaikka palveluverkkotoiminnallisuus voidaan toteuttaa palvelukoodissa (esimerkiksi jokaiseen palveluun sisältyvänä kirjastona), tämä lähestymistapa ei tarjoa yhtenäisyyttä ja riippumattomuutta, joka on niin arvokasta palveluverkon tapauksessa.
Ja sinun tarvitsee vain lisätä joukko välityspalvelimia! Lupaan, että tarkastelemme näiden välityspalvelinten lisäämiseen liittyviä käyttökustannuksia hyvin pian. Mutta ensin pysähdytään ja katsotaan tätä itsenäisyyden ajatusta eri näkökulmista. ihmiset.
Ketä palveluverkko auttaa?
Niin epämukavaa kuin se onkin, jotta teknologiasta tulisi tärkeä osa ekosysteemiä, ihmisten on hyväksyttävä se. Joten ketä kiinnostaa palveluverkko? Kuka hyötyy sen käytöstä?
Jos olet kehittämässä nykyaikaista palvelinohjelmistoa, voit karkeasti ajatella tiimiäsi ryhmänä palvelun omistajiajotka yhdessä kehittävät ja toteuttavat liiketoimintalogiikkaa ja alustan omistajatkehittämällä sisäistä alustaa, jolla nämä palvelut toimivat. Pienissä organisaatioissa nämä voivat olla samoja ihmisiä, mutta yrityksen kasvaessa nämä roolit korostuvat ja jopa jakautuvat alarooleihin... (Tässä on paljon sanottavaa devoppien muuttuvasta luonteesta, mikropalvelujen organisaatiovaikutus jne.) n. Otetaan nyt kuitenkin nämä kuvaukset annettuina).
Tästä näkökulmasta palveluverkon selkeitä hyötyjiä ovat alustan omistajat. Loppujen lopuksi alustatiimin tavoitteena on luoda sisäinen alusta, jolla palvelun omistajat voivat toteuttaa liiketoimintalogiikkaa ja tehdä sen siten, että he ovat mahdollisimman riippumattomia sen toiminnan hämäristä yksityiskohdista. Palveluverkko ei ainoastaan tarjoa tämän tavoitteen saavuttamisen kannalta kriittisiä ominaisuuksia, vaan se tekee sen tavalla, joka ei puolestaan aseta riippuvuutta palvelun omistajista.
Myös palvelun omistajat hyötyvät, vaikkakin välillisemmin. Palvelun omistajan tavoitteena on olla mahdollisimman tuottelias toteuttamaan liiketoimintaprosessin logiikkaa, ja mitä vähemmän hän joutuu huolehtimaan toiminnallisista asioista, sitä parempi. Sen sijaan, että he joutuisivat toteuttamaan esimerkiksi uudelleenyrityskäytäntöjä tai TLS:ää, he voivat keskittyä vain liiketoimintatavoitteisiin ja toivoa, että alusta huolehtii lopusta. Tämä on heille suuri etu.
Tällaisen alustojen ja palvelujen omistajien välisen jaon organisatorista arvoa ei voi yliarvioida. Luulen, että hän osallistuu tärkein osuus palveluverkon arvosta.
Opimme tämän läksyn, kun varhainen Linkerd-fani kertoi meille, miksi he valitsivat huoltoverkon: koska sen avulla he "pitävät puhumisen minimissä". Tässä on joitain yksityiskohtia: yhden suuren yrityksen kaverit siirsivät alustansa Kubernetesiin. Koska sovellus käsitteli arkaluonteisia tietoja, he halusivat salata kaiken klustereiden välisen viestinnän. Tilannetta vaikeutti kuitenkin satojen palveluiden ja satojen kehitystiimien läsnäolo. Mahdollisuus ottaa kaikkiin yhteyttä ja saada heidät sisällyttämään TLS-tuki suunnitelmiinsa ei tehnyt heitä onnelliseksi. Linkerdin asennuksen jälkeen he siirtyivät vastuu kehittäjistä (jonka näkökulmasta tämä oli tarpeetonta vaivaa) tasohyppelypelaajille, joille tämä oli huipputason prioriteetti. Toisin sanoen Linkerd ratkaisi heille ei niinkään teknisen ongelman kuin organisatorisen ongelman.
Lyhyesti sanottuna palveluverkko on enemmän ratkaisu, ei tekninen, vaan sosiotekninen Ongelmia. (Kiitos tämän termin käyttöönoton vuoksi.)
Ratkaiseeko huoltoverkko kaikki ongelmani?
Joo. Tarkoitan, ei!
Jos tarkastellaan kolmea edellä esitettyä ominaisuusluokkaa – luotettavuus, turvallisuus ja havaittavuus – käy selväksi, että palveluverkko ei ole täydellinen ratkaisu mihinkään näistä ongelmista. Vaikka Linkerd voi lähettää pyyntöjä uudelleen (jos se tietää, että ne ovat idempotentteja), se ei voi tehdä päätöksiä siitä, mitä palauttaa käyttäjälle, jos palvelu on pysyvästi epäonnistunut – nämä päätökset on tehtävä sovelluksen toimesta. Linkerd voi pitää tilastoja onnistuneista pyynnöistä, mutta se ei pysty perehtymään palveluun ja tarjoamaan sen sisäisiä mittareita - sovelluksessa on oltava sellaiset työkalut. Ja vaikka Linkerd pystyy järjestämään mTLS:n, täysimittaiset tietoturvaratkaisut vaativat paljon enemmän.
Osajoukko palveluverkon tarjoamista ominaisuuksista näillä alueilla liittyy alustan ominaisuudet. Tällä tarkoitan toimintoja, jotka:
- Riippumaton liikelogiikasta. Tapa, jolla Foon ja Barin väliset kutsuhistogrammit muodostetaan, on täysin riippumaton miksi Foo soittaa Barille.
- Vaikea toteuttaa oikein. Linkerdissä uudelleenyritykset parametroidaan kaikenlaisilla hienoilla asioilla, kuten uudelleenyritysbudjeteilla (yritä budjetteja uudelleen), koska monimutkainen, suoraviivainen lähestymistapa tällaisten asioiden toteuttamiseen johtaa varmasti niin sanotun "pyyntöjen lumivyöryn" syntymiseen. (yritä myrskyä uudelleen) ja muut hajautetuille järjestelmille ominaiset ongelmat.
- Tehokkain tasaisesti levitettynä. TLS-mekanismilla on järkeä vain, jos sitä sovelletaan kaikkialla.
Koska nämä toiminnot on toteutettu välityspalvelintasolla (eikä sovellustasolla), palveluverkko tarjoaa ne foorumi, ei sovelluksia. Ei siis ole väliä millä kielellä palvelut on kirjoitettu, mitä puitteita ne käyttävät, kuka ne on kirjoittanut ja miksi. Välityspalvelimet toimivat kaikkien näiden yksityiskohtien ulkopuolella, ja tämän toiminnallisuuden perusta, mukaan lukien konfigurointi-, päivitys-, käyttö-, ylläpito- jne. tehtävät, on yksinomaan alustatasolla.
Esimerkkejä palveluverkkoominaisuuksista
Yhteenvetona voidaan todeta, että palveluverkko ei ole täydellinen ratkaisu luotettavuuden, havaittavuuden tai turvallisuuden kannalta. Näiden alueiden laajuus edellyttää palvelun omistajien, Ops/SRE-tiimien ja muiden yrityskokonaisuuksien osallistumista. Palveluverkko tarjoaa vain alustatason "viipaleen" jokaiselle näistä alueista.
Miksi palveluverkosta on tullut suosittu juuri nyt?
Tähän mennessä olet todennäköisesti ihmetellyt: ok, jos palveluverkko on niin hyvä, miksi emme aloittaneet miljoonien välityspalvelinten käyttöönottoa pinossa kymmenen vuotta sitten?
Tähän kysymykseen on banaalinen vastaus: kymmenen vuotta sitten kaikki rakensivat monoliitteja, eikä kukaan tarvinnut huoltoverkkoa. Tämä on totta, mutta mielestäni tämä vastaus on menettänyt pointin. Jo kymmenen vuotta sitten mikropalveluiden käsite lupaavana tapana rakentaa suuria järjestelmiä keskusteltiin laajasti ja sitä sovellettiin muun muassa Twitterissä, Facebookissa, Googlessa ja Netflixissä. Yleinen näkemys – ainakin niillä teollisuudenaloilla, joiden kanssa olin tekemisissä – oli, että mikropalvelut olivat "oikea tapa" rakentaa suuria järjestelmiä, vaikka se olikin helvetin vaikeaa.
Tietenkin vaikka kymmenen vuotta sitten oli mikropalveluita tarjoavia yrityksiä, ne eivät tietenkään kiinnittäneet valtakirjoja kaikkialle, missä he pystyivät muodostamaan palveluverkkoa. Kuitenkin, jos katsot tarkasti, he tekivät jotain samanlaista: monet näistä yrityksistä vaativat erityisen sisäisen kirjaston käyttöä verkkoviestintään (jota joskus kutsutaan paksuksi asiakaskirjastoksi, lihava asiakaskirjasto).
Netflixillä oli Hysterix, Googlella Stubby, Twitterillä Finagle-kirjasto. Esimerkiksi Finagle oli pakollinen jokaisessa Twitterin uudessa palvelussa. Se käsitteli sekä asiakas- että palvelinpuolen yhteyksissä, salli toistuvat pyynnöt, tuki pyyntöjen reititystä, kuormituksen tasapainotusta ja mittausta. Se tarjosi yhtenäisen luotettavuuden ja havaittavuuden tason koko Twitter-pinossa riippumatta siitä, mitä palvelu teki. Tietysti se toimi vain JVM-kielille ja perustui ohjelmointimalliin, jota piti käyttää koko sovelluksessa. Sen toiminnallisuus oli kuitenkin lähes sama kuin palveluverkon. (Itse asiassa Linkerdin ensimmäinen versio oli yksinkertaisesti Finagle, joka oli kääritty välityspalvelimeen.)
Niinpä kymmenen vuotta sitten ei ollut olemassa vain mikropalveluita, vaan myös erityisiä proto-service-mesh-kirjastoja, jotka ratkaisivat samat ongelmat, joita palveluverkko ratkaisee nykyään. Itse palveluverkkoa ei kuitenkaan silloin ollut olemassa. Piti olla vielä yksi vuoro ennen kuin hän ilmestyi.
Ja tässä piilee syvempi vastaus, joka on piilotettu toiseen muutokseen, joka on tapahtunut viimeisen 10 vuoden aikana: mikropalvelujen käyttöönottokustannukset ovat laskeneet dramaattisesti. Yllä mainitut yritykset, jotka käyttivät mikropalveluita kymmenen vuotta sitten – Twitter, Netflix, Facebook, Google – olivat valtavan mittakaavan ja valtavien resurssien yrityksiä. Heillä ei ollut vain tarve, vaan myös kyky rakentaa, ottaa käyttöön ja käyttää suuria mikropalvelupohjaisia sovelluksia. Twitterin insinöörien käyttämä energia ja vaiva siirtyessään monoliittisesta mikropalvelulähestymistapaan on hämmästyttävää. (Ollakseni rehellinen, niin myös se tosiasia, että se onnistui.) Tällaiset infrastruktuuriliikkeet olivat silloin mahdottomia pienille yrityksille.
Pikakelaus nykyhetkeen. Nykyään on startuppeja, joissa mikropalvelujen suhde kehittäjiin on 5:1 (tai jopa ), ja mikä parasta, he selviävät niistä menestyksekkäästi! Jos 5 hengen startup pystyy helposti hoitamaan 50 mikropalvelua, niin jokin on selvästi vähentänyt niiden toteuttamiskustannuksia.
1500 mikropalvelua Monzossa; jokainen linja on määrätty verkkosääntö, joka sallii liikenteen
Mikropalveluiden käyttökustannusten dramaattinen lasku on seurausta yhdestä prosessista: konttien suosio kasvaa и orkestroijat. Tämä on juuri syvä vastaus kysymykseen, mikä vaikutti palveluverkon syntymiseen. Sama tekniikka teki sekä palveluverkoista että mikropalveluista houkuttelevia: Kubernetes ja Docker.
Miksi? No, Docker ratkaisee yhden suuren ongelman - pakkausongelman. Pakkaamalla sovelluksen ja sen (verkon ulkopuoliset) ajonaikaiset riippuvuudet säilöön, Docker muuttaa sovelluksen vaihdettavaksi yksiköksi, jota voidaan isännöidä ja käyttää missä tahansa. Samalla se yksinkertaistaa toimintaa huomattavasti monikielinen Pino: Koska kontti on käyttöönoton ja toiminnan kannalta ydinyksikkö, sen sisällä ei ole väliä, olipa se sitten JVM-, Node-, Go-, Python- tai Ruby-sovellus. Käynnistät sen ja se on siinä.
Kubernetes vie kaiken uudelle tasolle. Nyt kun on olemassa tonnia "ajettavia asioita" ja tonnia koneita, joilla niitä voidaan ajaa, tarvitaan työkalu, joka voi korreloida ne keskenään. Laajassa mielessä annat Kubernetesille paljon kontteja ja paljon koneita, ja se kartoittaa ne toisiaan vastaan (tämä on tietysti dynaaminen ja jatkuvasti muuttuva prosessi: uudet kontit liikkuvat järjestelmässä, koneet käynnistyvät ja pysähtyvät jne. Kubernetes kuitenkin ottaa tämän kaiken huomioon ).
Kun Kubernetes on määritetty, yhden palvelun käyttöönoton ja käytön aikakustannukset eivät juurikaan eroa kymmenen palvelun käyttöönoton ja käytön kustannuksista (itse asiassa se on melkein sama 100 palvelulla). Kun lisäät näihin säiliöihin pakkausmekanismina, joka kannustaa monikieliseen käyttöönottoon, saat joukon uusia sovelluksia toteutettuina eri kielillä kirjoitettujen mikropalveluiden muodossa – juuri sellaiseen ympäristöön, johon palveluverkko sopii niin hyvin.
Joten tulemme vastaukseen kysymykseen, miksi idea palveluverkosta on tullut suosituksi nyt: Kubernetesin palveluille tarjoama homogeenisuus koskee suoraan palveluverkon toiminnallisia haasteita. Pakkaat välityspalvelimet säiliöihin, annat Kubernetesille tehtäväksi kiinnittää ne minne vain voi, ja voila! Tämän seurauksena saat palveluverkon, kun taas Kubernetes hallitsee kaikkia sen käyttöönoton mekaniikkoja. (Ainakin lintuperspektiivistä katsottuna. Tässä prosessissa on tietysti monia vivahteita.)
Yhteenvetona: syy palveluverkoista on tullut suosittuja nyt, ei kymmenen vuotta sitten, on se, että Kubernetes ja Docker eivät ole vain lisääntyneet merkittävästi tarve siinä yksinkertaistettuaan sovellusten toteuttamista monikielisten mikropalveluiden sarjoina, mutta myös merkittävästi vähentynyt kustannuksia sen toimintaa varten tarjoamalla mekanismeja sivuvaunujen välityskalustojen käyttöönottamiseksi ja tukemiseksi.
Miksi palveluverkosta puhutaan niin paljon?
Varovaisuus: Käytän tässä osiossa kaikenlaisia olettamuksia, olettamuksia, fiktioita ja sisäpiiritietoa.
Tee haku sanalla "palveluverkko", niin löydät valtavan määrän kierrätettyä vähäkalorista sisältöä, outoja projekteja ja kaikukammion arvoisen vääristymän kaleidoskoopin. Kaikki hieno uusi tekniikka tekee tämän, mutta huoltoverkon tapauksessa ongelma on erityisen akuutti. Miksi?
No, osa siitä on minun syytäni. Olen työskennellyt kovasti edistääkseni Linkerdia ja palvelua joka kerta, kun saan lukemattomia tämän kaltaisia blogiviestejä ja artikkeleita. Mutta en ole niin voimakas. Jotta voimme todella vastata tähän kysymykseen, meidän on puhuttava hieman yleisestä tilanteesta. Ja siitä on mahdotonta puhua mainitsematta yhtä projektia: on Googlen, IBM:n ja Lyftin yhdessä kehittämä avoimen lähdekoodin palveluverkko.
(Näillä kolmella yrityksellä on hyvin erilaiset roolit: Lyftin osallistuminen näyttää olevan vain nimellinen; he ovat Envoyn kirjoittajia, mutta eivät käytä tai osallistu Istion kehitykseen. IBM on mukana ja käyttää Istion kehitystä. Google on aktiivisesti mukana Istion kehittämisessä. kehitystä, mutta ei käytä sitä niin pitkälle kuin voin kertoa.)
Istio-projekti on merkittävä kahdesta asiasta. Ensinnäkin se on valtava markkinointiponnistelu, jonka erityisesti Google kohdistaa sen edistämiseen. Arvioisin, että useimmat tämän päivän palveluverkkokonseptista tietävät saivat ensimmäisen kerran tiedon siitä Istion kautta. Toinen asia on se, kuinka huonosti Istio vastaanotettiin. Olen tässä asiassa ilmeisesti kiinnostunut, mutta yritän pysyä mahdollisimman objektiivisena, en silti voi auttaa , ei kovin erottuva (vaikka ei ainutlaatuinen: tulee mieleen systemd, ...) avoimen lähdekoodin projektiin.
(Käytännössä Istiolla näyttää olevan ongelmia paitsi monimutkaisuuden ja käyttökokemuksen, myös suorituskyvyn kanssa. Esim. Kolmannen osapuolen tekemässä tutkimuksessa tutkijat löysivät tilanteita, joissa Istion hännän latenssi oli 100 kertaa suurempi kuin Linkerdin, sekä resurssipulaa tilanteita, joissa Linkerd jatkoi toimintaansa menestyksekkäästi, kun taas Istio lakkasi toimimasta kokonaan.)
Jättäen sivuun teoriani siitä, miksi näin tapahtui, uskon, että palveluverkon ympärillä vallitseva ylivoimainen jännitys selittyy Googlen osallistumisella. Nimittäin seuraavan kolmen tekijän yhdistelmä:
- Googlen tunkeileva Istio-mainonta;
- vastaava paheksuva, kriittinen asenne projektia kohtaan;
- Kubernetesin suosion viimeaikainen raju nousu, jonka muistot ovat vielä tuoreita.
Yhdessä nämä tekijät luovat ällistyttävän, hapettoman ympäristön, jossa rationaalisen harkintakyky heikkenee ja jäljelle jää vain outo vaihtelu. .
Linkerdin näkökulmasta tämä on... mitä kuvailisin sekaiseksi siunaukseksi. Tarkoitan, on hienoa, että palveluverkko on tullut valtavirtaan tavalla, jolla se ei tapahtunut vuonna 2016, kun Linkerd aloitti ensimmäisen kerran, ja oli todella vaikea saada ihmisiä kiinnittämään huomiota projektiin. Nyt sellaista ongelmaa ei ole! Mutta huono uutinen on, että palveluverkkoympäristö on nykyään niin hämmentävä, että on lähes mahdotonta ymmärtää, mitkä projektit todella kuuluvat palveluverkkoluokkaan (puhumattakaan siitä, mikä niistä sopii parhaiten tiettyyn käyttötapaukseen). Tämä on ehdottomasti kaikkien sopimusten katkaisija (ja on varmasti joitain tapauksia, joissa Istio tai jokin muu projekti sopii paremmin kuin Linkerd, koska jälkimmäinen ei silti ole universaali ratkaisu).
Linkerdin puolella strategiamme on ollut jättää melu huomioimatta, jatkaa keskittymistä todellisten yhteisön ongelmien ratkaisemiseen ja oleellisesti odottaa, että hype laantuu. Lopulta hype laantuu ja voimme jatkaa työtä rauhallisesti.
Sillä välin meidän kaikkien on oltava hieman kärsivällisiä.
Onko palveluverkosta hyötyä minulle, vaatimattomalle ohjelmistosuunnittelijalle?
Seuraava kyselylomake auttaa sinua vastaamaan tähän kysymykseen:
Oletko mukana yksinomaan liiketoimintalogiikan toteuttamisessa? Tässä tapauksessa palveluverkosta ei ole sinulle hyötyä. Se on tietysti, että saatat olla kiinnostunut siitä, mutta ihannetapauksessa palveluverkon ei pitäisi vaikuttaa suoraan mihinkään ympäristössäsi. Jatka työtä sen eteen, mistä sinulle maksetaan.
Tuetko alustaa yrityksessä, joka käyttää Kubernetesia? Kyllä, tässä tapauksessa tarvitset huoltoverkon (ellet tietenkään käytä K8:ita vain monoliitti- tai eräkäsittelyyn - mutta sitten haluaisin kysyä, miksi tarvitset K8:ita). Saatat todennäköisesti päätyä moniin eri ihmisten kirjoittamiin mikropalveluihin. Ne kaikki ovat vuorovaikutuksessa toistensa kanssa ja ovat sidoksissa ajonaikaisten riippuvuuksien vyyhteeseen, ja sinun on löydettävä tapa käsitellä sitä kaikkea. Kubernetesin avulla voit valita palveluverkon "itsellesi". Voit tehdä tämän tutustumalla niiden ominaisuuksiin ja ominaisuuksiin ja vastaamalla kysymykseen, sopiiko jokin saatavilla olevista projekteista sinulle (suosittelen tutkimuksen aloittamista Linkerdillä).
Oletko alustayritys yrityksessä, joka EI käytä Kubernetesia, mutta käyttää mikropalveluita? Tässä tapauksessa palveluverkko on sinulle hyödyllinen, mutta sen käyttö ei ole triviaalia. Voit tietysti jäljitellä työpalveluverkkoa asettamalla joukko välityspalvelimia, mutta Kubernetesin tärkeä etu on käyttöönottomalli: näiden välityspalvelinten manuaalinen ylläpito vaatii paljon enemmän aikaa, vaivaa ja kustannuksia.
Oletko vastuussa alustasta monoliittien kanssa työskentelevässä yrityksessä? Tässä tapauksessa et todennäköisesti tarvitse huoltoverkkoa. Jos työskentelet monoliittien (tai jopa monoliittikokoelmien) kanssa, joilla on hyvin määritellyt ja harvoin muuttuvat vuorovaikutusmallit, palveluverkolla ei ole juurikaan tarjottavaa sinulle. Joten voit yksinkertaisesti jättää sen huomiotta ja toivoa, että se katoaa kuin paha unelma...
Johtopäätös
Todennäköisesti palveluverkkoa ei silti pitäisi kutsua "maailman hypetyimmäksi teknologiaksi" - tämä kyseenalainen kunnia kuuluu todennäköisesti Bitcoinille tai tekoälylle. Hän on luultavasti viiden parhaan joukossa. Mutta jos leikkaat melukerrokset, käy selväksi, että palveluverkko tuo todellista hyötyä niille, jotka rakentavat sovelluksia Kubernetesille.
Haluaisin sinun kokeilevan Linkerdia - asentamalla sen Kubernetes-klusteriin (tai jopa Minikubeen kannettavaan tietokoneeseen) , ja näet itse, mistä puhun.
FAQ
— Jos jätän palveluverkon huomiotta, katoaako se?
— Minun täytyy tuottaa teille pettymys: palveluverkko on ollut mukanamme pitkään.
- Mutta EN HALUA käyttää palveluverkkoa!
- No, se ei ole välttämätöntä! Lue vain yllä oleva kyselylomake ymmärtääksesi, pitäisikö sinun ainakin tutustua sen perusteisiin.
- Eikö tämä ole vanha kunnon ESB/väliastia uudella kastikkeella?
— Palveluverkko käsittelee toiminnallista logiikkaa, ei semanttista. yrityspalvelubussi (). Tämän erotuksen säilyttäminen auttaa huoltoverkkoa välttämään saman kohtalon.
— Miten palveluverkko eroaa API-yhdyskäytävistä?
– Tästä aiheesta on miljoona artikkelia. Googlaa vain.
— Onko lähettiläs palveluverkko?
- Ei, Envoy ei ole palveluverkko, se on välityspalvelin. Sitä voidaan käyttää palveluverkon järjestämiseen (ja paljon muuta - se on yleiskäyttöinen välityspalvelin). Mutta sinänsä se ei ole palveluverkko.
— Network Service Mesh on palveluverkko?
- Ei. Nimestä huolimatta tämä ei ole palveluverkko (miten pidät markkinoinnin ihmeistä?).
— Auttaako palveluverkko viestijonopohjaiseen reaktiiviseen asynkroniseen järjestelmääni?
- Ei, palveluverkko ei auta sinua.
— Mitä palveluverkkoa minun tulee käyttää?
- , itsestäänselvyys.
– Artikkeli on paska! / Kirjoittaja tervetuloa!
— Jaa linkki siihen kaikille ystävillesi, jotta he näkevät sen!
Kiitokset
Kuten otsikosta saattoi arvata, tämä artikkeli on saanut inspiraationsa Jay Krepsin fantastisesta tutkielmasta "" Tapasin Jayn kymmenen vuotta sitten, kun haastattelin häntä Linked Inissa, ja hän on ollut minulle inspiraationa siitä lähtien.
Vaikka haluan kutsua itseäni "Linkerd-kehittäjäksi", tosiasia on, että olen enemmän README.md-tiedoston ylläpitäjä projektissa. Linkerdin parissa työstetään tänään , , ihmisiä, ja tämä projekti ei olisi toteutunut ilman upean avustajien ja käyttäjien yhteisön osallistumista.
Ja lopuksi erityinen kiitos Linkerdin luojalle, (primus inter pares), joka yhdessä minun kanssani monta vuotta sitten sukelsi päätävarrella kaikkeen tähän palveluverkon meteliin.
PS kääntäjältä
Lue myös blogistamme:
- «";
- «";
- «";
- «";
- «'.
Lähde: will.com