Mentre passemu da una applicazione monolitica à una architettura di microservizi, facemu novi sfide.
In una applicazione monolitica, di solitu hè abbastanza faciule per determinà quale parte di u sistema hè accadutu l'errore. Probabilmente, u prublema hè in u codice di u monolitu stessu, o in a basa di dati. Ma quandu avemu principiatu à circà un prublema in una architettura di microserviziu, tuttu ùn hè più cusì evidenti. Avemu bisognu di truvà u percorsu sanu chì a dumanda hà pigliatu da u principiu à a fine è selezziunate da centinaie di microservizii. Inoltre, assai di elli anu ancu e so propie facilità d'almacenamiento, chì ponu ancu causà errori lògichi, è ancu prublemi cù u rendiment è a toleranza di difetti.
Aghju cercatu per un bellu pezzu un strumentu chì aiutava à trattà cun tali prublemi (aghju scrittu annantu à questu nantu à Habré: , ), ma à a fine aghju fattu a mo propria suluzione open source. In questu articulu parlu di i beneficii di l'approcciu di a rete di serviziu è sparte un novu strumentu per a so implementazione.
A traccia distribuita hè una suluzione cumuni à u prublema di truvà errori in sistemi distribuiti. Ma ciò chì si stu approcciu à cullà infurmazione nantu à l'interazzione di a rete ùn hè micca statu ancu implementatu in u sistema, o, peghju, in parte di u sistema hè digià travagliatu bè, ma in parte ùn hè micca, postu chì ùn hè micca aghjuntu à i vechji servizii. ? Per determinà a causa esatta di u prublema, hè necessariu avè una stampa cumpleta di ciò chì succede in u sistema. Hè soprattuttu impurtante per capiscenu chì i microservizi sò implicati in i percorsi chjave di l'impresa.
Quì l'approcciu di a rete di serviziu pò vene à u nostru aiutu, chì trattà cù tutte e machini per a cullizzioni di l'infurmazioni di a rete à un livellu più bassu di i servizii stessi operati. Stu approcciu ci permette di interceptà tuttu u trafficu è analizà nantu à a mosca. Inoltre, l'applicazioni ùn anu mancu bisognu di sapè nunda.
Approccio di rete di serviziu
L'idea principale di l'approcciu di a rete di serviziu hè di aghjunghje una altra capa di infrastruttura nantu à a reta, chì ci permetterà di fà qualsiasi cosa cù l'interazzione inter-serviziu. A maiò parte di l'implementazione funziona cusì: un containeru sidecar supplementu cù un proxy trasparente hè aghjuntu à ogni microserviziu, attraversu quale tuttu u trafficu entrante è in uscita di u serviziu hè passatu. È questu hè u locu induve pudemu fà equilibriu di u cliente, applicà e pulitiche di sicurezza, impone restrizioni à u numeru di richieste è recullà infurmazioni impurtanti nantu à l'interazzione di servizii in a produzzione.
Soluzioni
Ci hè digià parechje implementazioni di stu approcciu: и . Anu furnisce assai funziunalità fora di a scatula. Ma à u listessu tempu, ci vene un grande overhead nantu à e risorse. Inoltre, più grande hè u cluster in quale un tali sistema opera, più risorse seranu necessarie per mantene a nova infrastruttura. In Avito, operemu clusters kubernetes chì cuntenenu millaie di istanze di serviziu (è u so numeru cuntinueghja à cresce rapidamente). In a so implementazione attuale, Istio cunsuma ~ 300 Mb di RAM per esempiu di serviziu. A causa di u gran numaru di pussibulità, l'equilibriu trasparente afecta ancu u tempu di risposta generale di i servizii (finu à 10 ms).
In u risultatu, avemu vistu esattamente ciò chì capacità avemu bisognu avà, è hà decisu chì u mutivu principale per quessa avemu cuminciatu à implementà tali suluzioni era a capacità di cullà l'infurmazioni di traccia da tuttu u sistema in modu trasparente. Vulemu ancu avè u cuntrollu di l'interazzione di servizii è fà diverse manipulazioni cù l'intestazione chì sò trasferiti trà servizii.
In u risultatu, avemu ghjuntu à a nostra decisione: .
Netramesh
hè una suluzione ligera di maglia di serviziu cù a capacità di scala infinitamente, indipendentemente da u numeru di servizii in u sistema.
L'ugettivi principali di a nova suluzione eranu bassi di risorsa overhead è altu rendiment. Di e caratteristiche principali, avemu immediatamente vulsutu esse capace di mandà trasparenza di traccia à u nostru sistema Jaeger.
Oghje, a maiò parte di e soluzioni di nuvola sò implementate in Golang. E, sicuru, ci sò ragiuni per questu. Scrive l'applicazioni di rete in Golang chì travaglianu in modu asincronu cù I / O è scala in core in quantu necessariu hè convenientu è abbastanza simplice. E, ciò chì hè ancu assai impurtante, u rendiment hè abbastanza per risolve stu prublema. Hè per quessa chì avemu ancu sceltu Golang.
Produttività
Avemu cuncentratu i nostri sforzi per ottene a produtividade massima. Per una suluzione chì hè implementata accantu à ogni istanza di u serviziu, un picculu cunsumu di RAM è tempu CPU hè necessariu. E, sicuru, u ritardu di risposta duveria ancu esse chjucu.
Videmu chì risultati avemu avutu.
RAM
Netramesh consuma ~ 10 Mb senza trafficu è 50 Mb massimu cù una carica di finu à 10000 XNUMX RPS per esempiu.
Istio envoy proxy consuma sempre ~ 300 Mb in i nostri clusters cù migliaia di istanze. Questu ùn permettenu micca esse scalatu à u cluster sanu.
Cù Netramesh avemu una riduzione ~ 10x in u cunsumu di memoria.
CPU
L'usu di CPU hè relativamente uguale sottu a carica. Dipende da u numeru di richieste per unità di tempu à u sidecar. Valori à 3000 richieste per seconda à u piccu:
Ci hè un puntu più impurtante: Netramesh - una suluzione senza un pianu di cuntrollu è senza carica ùn cunsuma micca u tempu di CPU. Cù Istio, i sidecars aghjurnanu sempre i punti finali di serviziu. In u risultatu, pudemu vede sta stampa senza carica:
Utilizemu HTTP/1 per a cumunicazione trà i servizii. L'aumentu di u tempu di risposta per Istio quandu u proxy through envoy era finu à 5-10ms, chì hè assai assai per i servizii chì sò pronti à risponde in un millisecondu. Cù Netramesh sta volta hè diminuitu à 0.5-2ms.
Scalabilità
A piccula quantità di risorse cunsumate da ogni proxy permette di pusà accantu à ogni serviziu. Netramesh hè statu creatu intenzionalmente senza un cumpunente di u pianu di cuntrollu per simplificà à mantene ogni sidecar ligeru. Spessu in soluzioni di rete di serviziu, u pianu di cuntrollu distribuisce l'infurmazioni di scuperta di serviziu à ogni sidecar. Inseme vene infurmazione nantu à i timeouts è i paràmetri di equilibriu. Tuttu chistu vi permette di fà assai cose utili, ma, sfurtunatamenti, bloats sidecars in size.
Scuperta di serviziu
Netramesh ùn aghjunghje micca miccanismi supplementari per a scuperta di serviziu. Tuttu u trafficu hè mandatu in modu trasparente attraversu netra sidecar.
Netramesh supporta u protocolu d'applicazione HTTP/1. Per definisce, una lista configurable di porti hè utilizata. Di genere, u sistema hà parechji porti attraversu quale a cumunicazione HTTP si faci. Per esempiu, usemu 80, 8890, 8080 per l'interazzione trà i servizii è e dumande esterne In questu casu, ponu esse stabilitu cù una variabile d'ambiente NETRA_HTTP_PORTS.
Se utilizate Kubernetes cum'è un orchestratore è u so mecanismu di entità di serviziu per a cumunicazione intra-cluster trà i servizii, u mecanismu resta esattamente u listessu. Prima, u microserviziu ottene un indirizzu IP di serviziu cù kube-dns è apre una nova cunnessione à questu. Sta cunnessione hè prima stabilita cù u netra-sidecar lucale è tutti i pacchetti TCP inizialmente arrivanu à netra. Dopu, netra-sidecar stabilisce una cunnessione cù a destinazione originale. NAT nantu à u pod IP nantu à u node resta esattamente u listessu cum'è senza netra.
Tracciamentu distribuitu è spedizione di cuntestu
Netramesh furnisce a funziunalità necessaria per mandà spazii di traccia nantu à l'interazzione HTTP. Netra-sidecar analizza u protocolu HTTP, misura i ritardi di dumanda, è estrae l'infurmazioni necessarii da l'intestazione HTTP. In ultimamente, avemu tutte e tracce in un solu sistema Jaeger. Per a cunfigurazione fine, pudete ancu aduprà e variabili di l'ambiente furnite da a biblioteca ufficiale .
Ma ci hè un prublema. Finu à chì i servizii generanu è mandanu un intestazione uber speciale, ùn vedemu micca spazii di traccia cunnessi in u sistema. È questu hè ciò chì avemu bisognu di truvà rapidamente a causa di i prublemi. Quì dinò Netramesh hà una suluzione. I proxy leghjenu l'intestazione HTTP è, se ùn cuntenenu micca l'ID di traccia uber, generanu unu. Netramesh guarda ancu l'infurmazioni nantu à e richieste in entrata è in uscita in un sidecar è li currisponde arricchenduli cù l'intestazione di e dumande in uscita necessarie. Tuttu ciò chì duvete fà in i servizii hè di mandà solu un capu X-Request-Id, chì pò esse cunfiguratu cù una variabile d'ambiente NETRA_HTTP_REQUEST_ID_HEADER_NAME. Per cuntrullà a dimensione di u cuntestu in Netramesh, pudete stabilisce e seguenti variabili di l'ambiente: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (u tempu per quale u cuntestu serà guardatu) è NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (frequenza di pulizia di u cuntestu).
Hè ancu pussibule di cumminà parechje strade nantu à u vostru sistema marchendu cù un token di sessione speciale. Netra permette di stallà HTTP_HEADER_TAG_MAP per trasfurmà l'intestazione HTTP in tag span di traccia currispondenti. Questu pò esse particularmente utile per a prova. Dopu avè passatu a prova funziunale, pudete vede quale parte di u sistema hè stata affettata da u filtru da a chjave di sessione currispundente.
Determinà a Fonte di Richiesta
Per determinà da induve vene a dumanda, pudete aduprà a funziunalità di aghjunghje automaticamente un capu cù a fonte. Utilizà una variabile d'ambiente NETRA_HTTP_X_SOURCE_HEADER_NAME Pudete specificà un nome di header chì serà installatu automaticamente. Utilizendu NETRA_HTTP_X_SOURCE_VALUE pudete stabilisce u valore à quale l'intestazione X-Source serà stabilitu per tutte e dumande in uscita.
Questu permette chì a distribuzione di questa intestazione utile sia distribuita uniformemente in tutta a reta. Allora pudete aduprà in i servizii è aghjunghje à logs è metrica.
Instradamentu di u trafficu è internu Netramesh
Netramesh hè custituitu di dui cumpunenti principali. U primu, netra-init, stabilisce e regule di rete per intercepte u trafficu. Ellu usa per interceptà tuttu o parte di u trafficu in sidecar, chì hè u sicondu cumpunente principale di Netramesh. Pudete cunfigurà i porti chì deve esse interceptati per e sessioni TCP entranti è in uscita: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
U strumentu hà dinù una funziunalità interessante - routing probabilistic. Se utilizate Netramesh esclusivamente per a cullizzioni di spazii di traccia, allora in un ambiente di produzzione pudete salvà risorse è attivà u routing probabilisticu utilizendu variabili. NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (da 0 à 1). U valore predeterminatu hè 1 (tuttu u trafficu hè interceptatu).
Dopu à l'interception successu, netra sidecar accetta a nova cunnessione è usa SO_ORIGINAL_DST opzione socket per uttene u destinazione originale. Netra apre una nova cunnessione à l'indirizzu IP originale è stabilisce una cumunicazione TCP bidirezionale trà i partiti, à sente à tuttu u trafficu chì passa. Se u portu hè definitu cum'è HTTP, Netra prova di analizà è traccia. Se l'analisi HTTP falla, Netra torna à TCP è traspare in modu trasparente i byte.
Custruì un graficu di dependenza
Dopu avè ricivutu una grande quantità di informazioni di traccia in Jaeger, vogliu avè un gràficu cumpletu di l'interazzione in u sistema. Ma se u vostru sistema hè abbastanza carcu è miliardi di spazii di traccia s'acumulanu per ghjornu, l'aggregazione ùn diventa micca cusì faciule. Ci hè un modu ufficiale per fà questu: . Tuttavia, ci hà da piglià ore per custruisce un graficu cumpletu è vi furzà à scaricà tuttu u dataset da Jaeger per l'ultime 24 ore.
Sè vo aduprate Elasticsearch per almacenà spans di traccia, pudete aduprà , chì custruirà u stessu graficu in minuti cù e funziunalità è e capacità di Elasticsearch.
Cumu aduprà Netramesh
Netra pò esse facilmente aghjuntu à qualsiasi serviziu chì gestisce qualsiasi orchestratore. Pudete vede un esempiu .
À u mumentu, Netra ùn hà micca a capacità di implementà automaticamente sidecars à i servizii, ma ci sò piani di implementazione.
U futuru di Netramesh
scopu principale hè di ottene un costu minimu di risorse è un altu rendiment, chì furnisce capacità basiche per l'osservabilità è u cuntrollu di a cumunicazione inter-serviziu.
In u futuru, Netramesh sustenerà altri protokolli di strata di l'applicazione oltre HTTP. L'itinerariu L7 serà dispunibule in un futuru vicinu.
Aduprate Netramesh se scontri prublemi simili è scriviteci cù dumande è suggerimenti.
Source: www.habr.com