Terwyl ons van 'n monolitiese toepassing na 'n mikrodiensargitektuur beweeg, staar ons nuwe uitdagings in die gesig.
In 'n monolitiese toepassing is dit gewoonlik redelik maklik om te bepaal in watter deel van die stelsel die fout plaasgevind het. Waarskynlik is die probleem in die kode van die monoliet self, of in die databasis. Maar wanneer ons begin soek na 'n probleem in 'n mikrodiens-argitektuur, is alles nie meer so voor die hand liggend nie. Ons moet die hele pad vind wat die versoek van begin tot einde geneem het en dit uit honderde mikrodienste kies. Boonop het baie van hulle ook hul eie bergingsfasiliteite, wat ook logiese foute kan veroorsaak, sowel as probleme met werkverrigting en fouttoleransie.
Ek soek al lank na 'n hulpmiddel wat sal help om sulke probleme die hoof te bied (ek het hieroor op Habré geskryf: , ), maar ek het uiteindelik my eie oopbron-oplossing gemaak. In hierdie artikel praat ek oor die voordele van die diensnetwerkbenadering en deel ek 'n nuwe hulpmiddel vir die implementering daarvan.
Verspreide opsporing is 'n algemene oplossing vir die probleem om foute in verspreide stelsels te vind. Maar wat as hierdie benadering tot die insameling van inligting oor netwerkinteraksies nog nie in die stelsel geïmplementeer is nie, of, erger nog, in 'n deel van die stelsel werk dit reeds behoorlik, maar gedeeltelik nie, aangesien dit nie by ou dienste gevoeg is nie ? Om die presiese oorsaak van 'n probleem te bepaal, is dit nodig om 'n volledige prentjie te hê van wat in die stelsel gebeur. Dit is veral belangrik om te verstaan watter mikrodienste by sleutelbesigheidkritieke paaie betrokke is.
Hier kan die diensnetwerkbenadering ons help, wat al die masjinerie vir die insameling van netwerkinligting sal hanteer op 'n vlak laer as wat die dienste self bedryf. Hierdie benadering stel ons in staat om alle verkeer te onderskep en dit dadelik te ontleed. Boonop hoef toepassings niks daarvan te weet nie.
Diensnetwerkbenadering
Die hoofgedagte van die diensnetwerkbenadering is om nog 'n infrastruktuurlaag oor die netwerk by te voeg, wat ons in staat sal stel om enige ding met interdiensinteraksie te doen. Die meeste implementerings werk soos volg: 'n bykomende syspanhouer met 'n deursigtige instaanbediener word by elke mikrodiens gevoeg, waardeur alle inkomende en uitgaande verkeer van die diens deurgegee word. En dit is die einste plek waar ons kliëntebalansering kan doen, sekuriteitsbeleide kan toepas, beperkings op die aantal versoeke kan stel en belangrike inligting kan insamel oor die interaksie van dienste in produksie.
Oplossings
Daar is reeds verskeie implementerings van hierdie benadering: и . Hulle bied baie funksies uit die boks. Maar terselfdertyd kom daar 'n groot bokoste op hulpbronne. Bowendien, hoe groter die groep waarin so 'n stelsel funksioneer, hoe meer hulpbronne sal benodig word om die nuwe infrastruktuur in stand te hou. By Avito bedryf ons kubernetes-klusters wat duisende diensgevalle bevat (en hul aantal groei steeds vinnig). In sy huidige implementering verbruik Istio ~300Mb RAM per diensinstansie. As gevolg van die groot aantal moontlikhede, beïnvloed deursigtige balansering ook die algehele reaksietyd van dienste (tot 10ms).
Gevolglik het ons gekyk na presies watter vermoëns ons nou nodig het, en besluit dat die hoofrede waarom ons sulke oplossings begin implementeer het, die vermoë was om opsporingsinligting van die hele stelsel deursigtig in te samel. Ons wou ook beheer hê oor die interaksie van dienste en verskeie manipulasies doen met die opskrifte wat tussen dienste oorgedra word.
Gevolglik het ons tot ons besluit gekom: .
Netramesh
is 'n liggewig diensnetwerkoplossing met die vermoë om oneindig te skaal, ongeag die aantal dienste in die stelsel.
Die hoofdoelwitte van die nuwe oplossing was lae hulpbronbokoste en hoë werkverrigting. Van die hoofkenmerke wou ons dadelik in staat wees om naspeurspanne deursigtig na ons Jaeger-stelsel te stuur.
Vandag word die meeste wolkoplossings in Golang geïmplementeer. En natuurlik is daar redes hiervoor. Om netwerktoepassings in Golang te skryf wat asynchroon met I/O werk en oor kerns skaal soos nodig is gerieflik en redelik eenvoudig. En, wat ook baie belangrik is, die prestasie is voldoende om hierdie probleem op te los. Daarom het ons ook Golang gekies.
produktiwiteit
Ons het ons pogings daarop toegespits om maksimum produktiwiteit te bereik. Vir 'n oplossing wat langs elke instansie van die diens ontplooi word, is 'n klein verbruik van RAM en SVE-tyd nodig. En natuurlik moet die reaksievertraging ook klein wees.
Kom ons kyk watter resultate ons gekry het.
RAM
Netramesh verbruik ~10Mb sonder verkeer en 50Mb maksimum met 'n las van tot 10000 RPS per geval.
Istio gesant-instaanbediener verbruik altyd ~300Mb in ons groepe met duisende gevalle. Dit laat nie toe dat dit na die hele groep geskaal word nie.
Met Netramesh het ons 'n ~10x vermindering in geheueverbruik gekry.
CPU
SVE-gebruik is relatief gelyk onder las. Dit hang af van die aantal versoeke per tydseenheid na die syspan. Waardes by 3000 versoeke per sekonde op piek:
Daar is nog 'n belangrike punt: Netramesh - 'n oplossing sonder 'n beheervlak en sonder vrag verbruik nie SVE-tyd nie. Met Istio werk syspan altyd dienseindpunte op. As gevolg hiervan kan ons hierdie prentjie sien sonder om te laai:
Ons gebruik HTTP/1 vir kommunikasie tussen dienste. Die toename in reaksietyd vir Istio by volmag deur gesant was tot 5-10ms, wat nogal baie is vir dienste wat gereed is om binne 'n millisekonde te reageer. Met Netramesh het hierdie tyd afgeneem tot 0.5-2ms.
Skaalbaarheid
Die klein hoeveelheid hulpbronne wat deur elke instaanbediener verbruik word, maak dit moontlik om dit langs elke diens te plaas. Netramesh is doelbewus geskep sonder 'n beheervlakkomponent om elke syspan eenvoudig liggewig te hou. Dikwels in diensnetwerkoplossings versprei die beheervliegtuig diensontdekkinginligting na elke syspan. Daarmee saam kom inligting oor time-outs en balanseringinstellings. Dit alles laat jou toe om baie nuttige dinge te doen, maar ongelukkig laat dit sykarretjies in grootte opblaas.
Diens ontdekking
Netramesh voeg geen bykomende meganismes vir diensontdekking by nie. Alle verkeer word deursigtig deur netra-syspan gestuur.
Netramesh ondersteun HTTP/1-toepassingsprotokol. Om dit te definieer, word 'n konfigureerbare lys poorte gebruik. Tipies het die stelsel verskeie poorte waardeur HTTP-kommunikasie plaasvind. Ons gebruik byvoorbeeld 80, 8890, 8080 vir interaksie tussen dienste en eksterne versoeke. In hierdie geval kan hulle gestel word deur gebruik te maak van 'n omgewingsveranderlike NETRA_HTTP_PORTS.
As jy Kubernetes as 'n orkestreerder en sy Diens-entiteitmeganisme gebruik vir intra-kluster kommunikasie tussen dienste, dan bly die meganisme presies dieselfde. Eerstens kry die mikrodiens 'n diens-IP-adres met behulp van kube-dns en maak 'n nuwe verbinding daarmee oop. Hierdie verbinding word eers met die plaaslike netra-syspan tot stand gebring en alle TCP-pakkies arriveer aanvanklik by netra. Vervolgens vestig netra-sidecar 'n verbinding met die oorspronklike bestemming. NAT op pod IP op die nodus bly presies dieselfde as sonder netra.
Verspreide opsporing en konteksversending
Netramesh bied die funksionaliteit wat nodig is om opsporingsspanne oor HTTP-interaksies te stuur. Netra-sidecar ontleed die HTTP-protokol, meet versoekvertragings en onttrek die nodige inligting uit HTTP-opskrifte. Uiteindelik kry ons al die spore in 'n enkele Jaeger-stelsel. Vir fynkorrelige konfigurasie kan jy ook die omgewingsveranderlikes gebruik wat deur die amptelike biblioteek verskaf word .
Maar daar is 'n probleem. Totdat dienste 'n spesiale uber-opskrif genereer en stuur, sal ons nie gekoppelde opsporingsspanne in die stelsel sien nie. En dit is wat ons nodig het om vinnig die oorsaak van probleme te vind. Hier het Netramesh weer 'n oplossing. Gevolmagtigdes lees HTTP-opskrifte en genereer een as hulle nie die uber-spoor-ID bevat nie. Netramesh stoor ook inligting oor inkomende en uitgaande versoeke in 'n syspan en pas dit deur hulle te verryk met die nodige uitgaande versoekopskrifte. Al wat jy in die dienste moet doen, is om net een kopskrif te stuur X-Request-Id, wat gekonfigureer kan word met behulp van 'n omgewingsveranderlike NETRA_HTTP_REQUEST_ID_HEADER_NAME. Om die grootte van die konteks in Netramesh te beheer, kan jy die volgende omgewingsveranderlikes stel: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (die tyd waarvoor die konteks gestoor sal word) en NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (frekwensie van konteksopruiming).
Dit is ook moontlik om verskeie paaie op jou stelsel te kombineer deur hulle met 'n spesiale sessietoken te merk. Netra laat jou toe om te installeer HTTP_HEADER_TAG_MAP om HTTP-opskrifte in ooreenstemmende opsporingspan-etikette te verander. Dit kan veral nuttig wees vir toetsing. Nadat u die funksionele toets geslaag het, kan u sien watter deel van die stelsel geraak is deur die filter deur die ooreenstemmende sessiesleutel.
Bepaling van die versoekbron
Om te bepaal waar die versoek vandaan kom, kan jy die funksionaliteit gebruik om outomaties 'n kop by die bron by te voeg. Gebruik 'n omgewingsveranderlike NETRA_HTTP_X_SOURCE_HEADER_NAME Jy kan 'n kopnaam spesifiseer wat outomaties geïnstalleer sal word. Deur die gebruik van NETRA_HTTP_X_SOURCE_VALUE jy kan die waarde stel waarop die X-Source-opskrif vir alle uitgaande versoeke gestel sal word.
Dit laat toe dat die verspreiding van hierdie nuttige kop eenvormig deur die netwerk versprei word. Dan kan jy dit in dienste gebruik en dit by logs en metrieke voeg.
Verkeer roetering en Netramesh internals
Netramesh bestaan uit twee hoofkomponente. Die eerste, netra-init, stel netwerkreëls om verkeer te onderskep. Hy gebruik om die hele of 'n gedeelte van die verkeer op syspan te onderskep, wat die tweede hoofkomponent van Netramesh is. U kan opstel watter poorte onderskep moet word vir inkomende en uitgaande TCP-sessies: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Die instrument het ook 'n interessante kenmerk - waarskynlike roetering. As jy Netramesh uitsluitlik gebruik vir die insameling van naspeurspanne, dan kan jy in 'n produksie-omgewing hulpbronne bespaar en waarskynlike roetering moontlik maak deur veranderlikes te gebruik NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (van 0 tot 1). Die verstekwaarde is 1 (alle verkeer word onderskep).
Na suksesvolle onderskepping, aanvaar netra sidecar die nuwe verbinding en gebruike SO_ORIGINAL_DST socket opsie om die oorspronklike bestemming te kry. Netra maak dan 'n nuwe verbinding na die oorspronklike IP-adres oop en vestig tweerigting TCP-kommunikasie tussen die partye, en luister na alle verkeer wat deurgaan. As die poort as HTTP gedefinieer word, probeer Netra om dit te ontleed en op te spoor. As HTTP-ontleding misluk, val Netra terug na TCP en gee die grepe deursigtig.
Bou 'n afhanklikheidsgrafiek
Nadat ek 'n groot hoeveelheid opsporingsinligting in Jaeger ontvang het, wil ek 'n volledige grafiek van interaksies in die stelsel kry. Maar as jou stelsel taamlik gelaai is en biljoene opsporingsspanne per dag ophoop, word dit nie so 'n maklike taak om dit saam te voeg nie. Daar is 'n amptelike manier om dit te doen: . Dit sal egter ure neem om 'n volledige grafiek te bou en sal jou dwing om die hele datastel van Jaeger af te laai vir die afgelope XNUMX uur.
As jy Elasticsearch gebruik om spoorstreke te stoor, kan jy dit gebruik , wat dieselfde grafiek in minute sal bou deur die kenmerke en vermoëns van Elasticsearch te gebruik.
Hoe om Netramesh te gebruik
Netra kan maklik by enige diens gevoeg word wat enige orkeseerder bestuur. Jy kan 'n voorbeeld sien .
Op die oomblik het Netra nie die vermoë om outomaties syspan by dienste te implementeer nie, maar daar is planne vir implementering.
Die toekoms van Netramesh
hoof doel is om minimale hulpbronkoste en hoë werkverrigting te bereik, wat basiese vermoëns bied vir waarneembaarheid en beheer van interdienskommunikasie.
In die toekoms sal Netramesh ander toepassingslaagprotokolle behalwe HTTP ondersteun. L7-roetering sal in die nabye toekoms beskikbaar wees.
Gebruik Netramesh as jy soortgelyke probleme teëkom en skryf aan ons met vrae en voorstelle.
Bron: will.com