Kun siirrymme monoliittisesta sovelluksesta mikropalveluarkkitehtuuriin, kohtaamme uusia haasteita.
Monoliittinen sovellus on yleensä melko helppo määrittää, missä järjestelmän osassa virhe tapahtui. Todennäköisimmin ongelma on itse monoliitin koodissa tai tietokannassa. Mutta kun alamme etsiä ongelmaa mikropalveluarkkitehtuurista, kaikki ei ole enää niin ilmeistä. Meidän on löydettävä koko pyynnön polku alusta loppuun ja valittava se sadoista mikropalveluista. Lisäksi monilla niistä on myös omat varastotilat, jotka voivat myös aiheuttaa loogisia virheitä sekä suorituskyky- ja vikasieto-ongelmia.
Olen etsinyt jo pitkään työkalua, joka auttaisi selviytymään tällaisista ongelmista (kirjoitin tästä Habressa: , ), mutta lopulta tein oman avoimen lähdekoodin ratkaisuni. Tässä artikkelissa puhun palveluverkkolähestymistavan eduista ja jaan uuden työkalun sen toteuttamiseen.
Hajautettu jäljitys on yleinen ratkaisu hajautettujen järjestelmien virheiden etsimiseen. Mutta entä jos tätä tiedonkeruuta verkkovuorovaikutuksista ei ole vielä otettu käyttöön järjestelmässä tai, mikä vielä pahempaa, osassa järjestelmä toimii jo kunnolla, mutta osittain ei, koska sitä ei ole lisätty vanhoihin palveluihin ? Ongelman tarkan perimmäisen syyn määrittämiseksi on välttämätöntä saada täydellinen kuva siitä, mitä järjestelmässä tapahtuu. Erityisen tärkeää on ymmärtää, mitkä mikropalvelut ovat mukana liiketoiminnan kannalta keskeisillä poluilla.
Tässä voi tulla avuksemme palveluverkko-lähestymistapa, joka käsittelee kaikki verkkotiedon keräämiskoneet alemmalla tasolla kuin palvelut itse toimivat. Tämän lähestymistavan avulla voimme siepata kaiken liikenteen ja analysoida sitä lennossa. Lisäksi sovellusten ei tarvitse edes tietää siitä mitään.
Palveluverkon lähestymistapa
Palveluverkkolähestymistavan pääideana on lisätä verkkoon toinen infrastruktuurikerros, jonka avulla voimme tehdä mitä tahansa palveluiden välisen vuorovaikutuksen kanssa. Useimmat toteutukset toimivat seuraavasti: jokaiseen mikropalveluun lisätään ylimääräinen sivuvaunukontti läpinäkyvällä välityspalvelimella, jonka kautta kaikki palvelun saapuva ja lähtevä liikenne kulkee. Ja tämä on juuri se paikka, jossa voimme tehdä asiakastasapainotuksen, soveltaa tietoturvapolitiikkaa, asettaa rajoituksia pyyntöjen lukumäärälle ja kerätä tärkeää tietoa palveluiden vuorovaikutuksesta tuotannossa.
Ratkaisut
Tästä lähestymistavasta on jo useita toteutuksia: и . Ne tarjoavat paljon ominaisuuksia heti laatikosta alkaen. Mutta samaan aikaan resursseihin liittyy isoja kustannuksia. Lisäksi mitä suuremmassa klusterissa tällainen järjestelmä toimii, sitä enemmän resursseja tarvitaan uuden infrastruktuurin ylläpitoon. Me Avitossa operoimme kubernetes-klustereita, jotka sisältävät tuhansia palveluesiintymiä (ja niiden määrä kasvaa edelleen nopeasti). Nykyisessä toteutuksessaan Istio kuluttaa ~300 Mt RAM-muistia palveluinstanssia kohden. Mahdollisuuksien suuren määrän vuoksi läpinäkyvä tasapainotus vaikuttaa myös palvelujen kokonaisvasteaikaan (jopa 10ms).
Tämän seurauksena tarkastelimme juuri nyt, mitä ominaisuuksia tarvitsemme juuri nyt, ja päätimme, että suurin syy, miksi aloimme toteuttaa tällaisia ratkaisuja, oli kyky kerätä jäljitystietoja koko järjestelmästä läpinäkyvästi. Halusimme myös hallita palvelujen vuorovaikutusta ja tehdä erilaisia manipulaatioita palveluiden välillä siirrettävillä otsikoilla.
Tuloksena päädyimme päätökseemme: .
Netramesh
on kevyt palveluverkkoratkaisu, joka voi skaalata loputtomasti järjestelmän palveluiden lukumäärästä riippumatta.
Uuden ratkaisun päätavoitteet olivat alhaiset resurssit ja korkea suorituskyky. Yksi tärkeimmistä ominaisuuksista halusimme välittömästi lähettää jäljitysvälit läpinäkyvästi Jaeger-järjestelmäämme.
Nykyään useimmat pilviratkaisut toteutetaan Golangissa. Ja tähän on tietysti syynsä. Verkkosovellusten kirjoittaminen Golangissa, jotka toimivat asynkronisesti I/O:n kanssa ja skaalaavat ytimien välillä tarpeen mukaan, on kätevää ja melko yksinkertaista. Ja mikä on myös erittäin tärkeää, suorituskyky riittää ratkaisemaan tämän ongelman. Siksi valitsimme myös Golangin.
Suorituskyky
Olemme keskittyneet saavuttamaan maksimaalisen tuottavuuden. Ratkaisu, joka otetaan käyttöön palvelun jokaisen esiintymän vieressä, vaatii vähän RAM-muistia ja suorittimen aikaa. Ja tietysti myös vastausviiveen tulee olla pieni.
Katsotaan mitä tuloksia saamme.
RAM
Netramesh kuluttaa ~10 Mt ilman liikennettä ja enintään 50 Mt kuormituksella jopa 10000 XNUMX RPS:tä kohden.
Istio Envoy -välityspalvelin kuluttaa aina ~300Mb tuhansia esiintymiä sisältävissä klustereissamme. Tämä ei salli sen skaalaamista koko klusteriin.
Netrameshin avulla saimme ~10x vähennyksen muistinkulutukseen.
prosessori
Prosessorin käyttö on suhteellisen tasaista kuormitettuna. Se riippuu sivuvaunun pyyntöjen määrästä aikayksikköä kohti. Arvot 3000 pyynnöllä sekunnissa huipulla:
On vielä yksi tärkeä kohta: Netramesh - ratkaisu ilman ohjaustasoa ja ilman kuormitusta ei kuluta CPU-aikaa. Istion avulla sivuvaunut päivittävät aina palvelun päätepisteitä. Tämän seurauksena voimme nähdä tämän kuvan ilman kuormaa:
Käytämme HTTP/1:tä palveluiden väliseen viestintään. Istion vasteaika nousi välityspalvelimella lähettilään kautta jopa 5-10 ms, mikä on melko paljon palveluille, jotka ovat valmiita vastaamaan millisekunnissa. Netrameshin kanssa tämä aika on laskenut 0.5-2 ms:iin.
Skaalautuvuus
Kunkin välityspalvelimen käyttämä pieni resurssien määrä mahdollistaa sen sijoittamisen jokaisen palvelun viereen. Netramesh luotiin tarkoituksella ilman ohjaustasokomponenttia, jotta jokainen sivuvaunu pysyisi kevyenä. Usein huoltoverkkoratkaisuissa ohjaustaso jakaa palvelunhakutiedot kullekin sivuvaunulle. Sen mukana tulee tietoa aikakatkaisuista ja tasapainotusasetuksista. Kaiken tämän avulla voit tehdä paljon hyödyllisiä asioita, mutta valitettavasti se paisuttaa sivuvaunujen kokoa.
Palvelun löytäminen
Netramesh ei lisää muita mekanismeja palvelun löytämiseen. Kaikki liikenne välitetään läpinäkyvästi netran sivuvaunun kautta.
Netramesh tukee HTTP/1-sovellusprotokollaa. Sen määrittämiseen käytetään konfiguroitavaa porttiluetteloa. Tyypillisesti järjestelmässä on useita portteja, joiden kautta HTTP-yhteys tapahtuu. Palveluiden ja ulkoisten pyyntöjen väliseen vuorovaikutukseen käytetään esimerkiksi 80, 8890, 8080. Tässä tapauksessa ne voidaan asettaa ympäristömuuttujan avulla. NETRA_HTTP_PORTS.
Jos käytät Kubernetesia järjestäjänä ja sen Palveluentiteettimekanismia klusterin sisäiseen viestintään palveluiden välillä, mekanismi pysyy täsmälleen samana. Ensin mikropalvelu hankkii palvelun IP-osoitteen kube-dns:n avulla ja avaa siihen uuden yhteyden. Tämä yhteys muodostetaan ensin paikallisen netran sivukorin kanssa ja kaikki TCP-paketit saapuvat aluksi netralle. Seuraavaksi netra-sivuvaunu muodostaa yhteyden alkuperäiseen määränpäähän. NAT solmun pod IP:ssä pysyy täsmälleen samana kuin ilman netraa.
Hajautettu jäljitys ja kontekstin edelleenlähetys
Netramesh tarjoaa toiminnot, joita tarvitaan HTTP-vuorovaikutusten jäljitysjaksojen lähettämiseen. Netra-sidecar jäsentää HTTP-protokollan, mittaa pyyntöjen viiveet ja poimii tarvittavat tiedot HTTP-otsikoista. Lopulta saamme kaikki jäljet yhdestä jääkärijärjestelmästä. Tarkkaan määrittelyyn voit käyttää myös virallisen kirjaston tarjoamia ympäristömuuttujia .
Mutta siinä on ongelma. Ennen kuin palvelut luovat ja lähettävät erityisen uber-otsikon, emme näe yhdistettyjä jäljitysjaksoja järjestelmässä. Ja tämä meidän on löydettävä nopeasti ongelmien syyt. Netrameshilla on jälleen ratkaisu. Välityspalvelimet lukevat HTTP-otsikot ja luovat sellaisen, jos ne eivät sisällä uber-jäljitystunnusta. Netramesh myös tallentaa tiedot saapuvista ja lähtevistä pyynnöistä sivuvaunuun ja sovittaa ne rikastamalla niitä tarvittavilla lähtevien pyyntöjen otsikoilla. Palveluissa sinun tarvitsee vain lähettää vain yksi otsikko X-Request-Id, joka voidaan määrittää ympäristömuuttujan avulla NETRA_HTTP_REQUEST_ID_HEADER_NAME. Voit hallita kontekstin kokoa Netrameshissa asettamalla seuraavat ympäristömuuttujat: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (aika, jonka konteksti tallennetaan) ja NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (kontekstin puhdistustiheys).
On myös mahdollista yhdistää useita polkuja järjestelmässäsi merkitsemällä ne erityisellä istuntotunnuksella. Netran avulla voit asentaa HTTP_HEADER_TAG_MAP muuttaa HTTP-otsikot vastaaviksi jäljitysvälitunnisteiksi. Tämä voi olla erityisen hyödyllistä testauksessa. Kun olet läpäissyt toimintatestin, näet, mihin järjestelmän osaan vastaava istuntoavaimen suodatus vaikutti.
Pyynnön lähteen määrittäminen
Voit määrittää, mistä pyyntö tuli, käyttämällä toimintoa, joka lisää automaattisesti otsikon lähteen kanssa. Ympäristömuuttujan käyttö NETRA_HTTP_X_SOURCE_HEADER_NAME Voit määrittää otsikon nimen, joka asennetaan automaattisesti. Käyttämällä NETRA_HTTP_X_SOURCE_VALUE voit asettaa arvon, johon X-Source-otsikko asetetaan kaikille lähteville pyynnöille.
Tämä mahdollistaa tämän hyödyllisen otsikon jakelun tasaisesti koko verkossa. Sitten voit käyttää sitä palveluissa ja lisätä sen lokeihin ja mittareihin.
Liikenteen reititys ja Netramesh-sisäosat
Netramesh koostuu kahdesta pääkomponentista. Ensimmäinen, netra-init, asettaa verkkosäännöt sieppaamaan liikennettä. Hän käyttää siepata koko liikenne tai osa siitä sivuvaunulla, joka on Netrameshin toinen pääkomponentti. Voit määrittää, mitkä portit on siepattava saapuvia ja lähteviä TCP-istuntoja varten: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Työkalussa on myös mielenkiintoinen ominaisuus - todennäköisyyspohjainen reititys. Jos käytät Netrameshia yksinomaan jäljitysvälien keräämiseen, voit tuotantoympäristössä säästää resursseja ja ottaa käyttöön todennäköisyyspohjaisen reitityksen muuttujien avulla. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0 - 1). Oletusarvo on 1 (kaikki liikenne siepataan).
Onnistuneen sieppauksen jälkeen netran sivuvaunu hyväksyy uuden yhteyden ja käyttää SO_ORIGINAL_DST socket-vaihtoehto saadaksesi alkuperäisen määränpään. Netra avaa sitten uuden yhteyden alkuperäiseen IP-osoitteeseen ja muodostaa kaksisuuntaisen TCP-viestinnän osapuolten välille kuuntelemalla kaikkea läpi kulkevaa liikennettä. Jos portti on määritetty HTTP:ksi, Netra yrittää jäsentää ja jäljittää sen. Jos HTTP-jäsennys epäonnistuu, Netra palaa TCP:hen ja välittää tavut läpinäkyvästi.
Riippuvuuskaavion rakentaminen
Saatuani suuren määrän jäljitystietoja Jaegerissa, haluan saada täydellisen kaavion järjestelmän vuorovaikutuksista. Mutta jos järjestelmäsi on melko kuormitettu ja miljardeja jäljitysjaksoja kertyy päivässä, niiden yhdistäminen ei ole niin helppoa. On olemassa virallinen tapa tehdä tämä: . Täydellisen kaavion luominen kestää kuitenkin tunteja ja pakottaa sinut lataamaan koko datajoukon Jaegerista viimeisen XNUMX tunnin ajalta.
Jos käytät Elasticsearchia jäljitysjännevälien tallentamiseen, voit käyttää , joka rakentaa saman kaavion minuuteissa käyttämällä Elasticsearchin ominaisuuksia ja ominaisuuksia.
Kuinka käyttää Netrameshia
Netra voidaan helposti lisätä mihin tahansa palveluun, joka käyttää mitä tahansa orkesteria. Voit nähdä esimerkin .
Tällä hetkellä Netralla ei ole mahdollisuutta ottaa automaattisesti käyttöön sivuvaunuja palveluihin, mutta toteutussuunnitelmia on.
Netrameshin tulevaisuus
päätavoite on minimaalisten resurssikustannusten ja korkean suorituskyvyn saavuttaminen, mikä tarjoaa perusominaisuudet yksiköiden välisen viestinnän havainnointiin ja hallintaan.
Jatkossa Netramesh tukee muita sovelluskerroksen protokollia HTTP:n lisäksi. L7-reititys on saatavilla lähitulevaisuudessa.
Käytä Netrameshia, jos kohtaat samanlaisia ongelmia, ja kirjoita meille kysymyksiä ja ehdotuksia.
Lähde: will.com