Wéi mir vun enger monolithescher Applikatioun op eng Mikroservicerarchitektur plënneren, stellen mir nei Erausfuerderungen.
An enger monolithescher Applikatioun ass et normalerweis ganz einfach ze bestëmmen a wéi engem Deel vum System de Feeler geschitt ass. Wahrscheinlech ass de Problem am Code vum Monolith selwer oder an der Datebank. Awer wa mir ufänken no engem Problem an enger Mikroservicearchitektur ze sichen, ass alles net méi sou offensichtlech. Mir mussen de ganze Wee fannen deen d'Ufro vun Ufank bis Enn geholl huet a se aus Honnerte vu Mikroservicer auswielen. Desweideren, vill vun hinnen hunn och hir eege Stockage Ariichtungen, déi och logesch Feeler verursaache kann, wéi och Problemer mat Leeschtung a Feeler Toleranz.
Ech hu scho laang no engem Tool gesicht dat hëllefe mat sou Probleemer ze këmmeren (ech hunn iwwer dëst op Habré geschriwwen: , ), awer um Enn hunn ech meng eegen Open Source Léisung gemaach. An dësem Artikel schwätzen ech iwwer d'Virdeeler vun der Service Mesh Approche an deelen en neit Tool fir seng Ëmsetzung.
Verdeelt Tracing ass eng gemeinsam Léisung fir de Problem fir Feeler a verdeelt Systemer ze fannen. Awer wat wann dës Approche fir Informatioun iwwer Netzwierkinteraktiounen ze sammelen ass nach net am System ëmgesat ginn, oder, schlëmmer, an en Deel vum System funktionnéiert se scho richteg, awer deelweis net, well et net an al Servicer bäigefüügt gouf ? Fir d'exakt root Ursaach vun engem Problem ze bestëmmen, ass et néideg e komplett Bild ze hunn wat am System geschitt ass. Et ass besonnesch wichteg ze verstoen wéi eng Mikroservicer a Schlësselgeschäftskritesch Weeër involvéiert sinn.
Hei kann de Service Mesh Approche eis hëllefen, déi all d'Maschinnen beschäftegt fir Netzwierkinformatioun op engem Niveau méi niddereg wéi d'Servicer selwer ze bedreiwen. Dës Approche erlaabt eis all Traffic z'ënnerscheeden an et op der Flucht ze analyséieren. Ausserdeem mussen d'Applikatiounen net emol eppes doriwwer wëssen.
Service Mesh Approche
D'Haaptidee vun der Service Mesh Approche ass eng aner Infrastrukturschicht iwwer d'Netz ze addéieren, wat eis erlaabt alles mat Inter-Service Interaktioun ze maachen. Déi meescht Implementatioune funktionnéieren wéi follegt: en zousätzleche Sidecarbehälter mat engem transparenten Proxy gëtt zu all Mikroservice bäigefüügt, duerch deen all erakommen an erausgoende Verkéier vum Service passéiert. An dat ass déi ganz Plaz wou mir Client Balance maache kënnen, Sécherheetspolitik applizéieren, Restriktiounen op d'Zuel vun Ufroen opsetzen a wichteg Informatioun iwwer d'Interaktioun vu Servicer an der Produktioun sammelen.
Léisungen
Et gi scho verschidde Implementatioune vun dëser Approche: и . Si bidden vill Funktiounen aus der Këscht. Awer gläichzäiteg gëtt et e groussen Overhead op Ressourcen. Ausserdeem, wat méi grouss de Cluster an deem esou e System funktionnéiert, wat méi Ressourcen néideg sinn fir déi nei Infrastruktur z'erhalen. Bei Avito bedreiwen mir kubernetes Cluster déi Dausende vu Serviceinstanzen enthalen (an hir Zuel wiisst weider séier). A senger aktueller Ëmsetzung verbraucht Istio ~300Mb RAM pro Serviceinstanz. Wéinst der grousser Zuel vu Méiglechkeeten, beaflosst transparent Balance och d'allgemeng Äntwertzäit vu Servicer (bis zu 10ms).
Als Resultat hu mir genau gekuckt wéi eng Fäegkeeten mir elo brauchen, an hunn decidéiert datt den Haaptgrond firwat mir ugefaang hunn esou Léisungen ëmzesetzen d'Fäegkeet ass fir Tracinginformatioun aus dem ganze System transparent ze sammelen. Mir wollten och d'Kontroll iwwer d'Interaktioun vu Servicer hunn a verschidde Manipulatioune mat den Header maachen, déi tëscht Servicer transferéiert ginn.
Als Resultat si mir zu eiser Entscheedung komm: .
Netramesh
ass eng liicht Service Mesh Léisung mat der Fäegkeet fir onendlech ze skaléieren, onofhängeg vun der Unzuel vun de Servicer am System.
D'Haaptziler vun der neier Léisung waren niddereg Ressource-Overhead an héich Leeschtung. Ënnert den Haaptfeatures wollte mir direkt fäeg sinn Tracingspann an eise Jaeger System transparent ze schécken.
Haut ginn déi meescht Cloud-Léisungen a Golang implementéiert. An natierlech ginn et Grënn dofir. Netzapplikatiounen op Golang schreiwen déi asynchron mat I/O funktionnéieren an iwwer Cores skaléieren wéi néideg ass bequem an zimmlech einfach. An, wat och ganz wichteg ass, ass d'Performance genuch fir dëse Problem ze léisen. Dofir hu mir och Golang gewielt.
Produktivitéit
Mir hunn eis Efforte konzentréiert fir maximal Produktivitéit z'erreechen. Fir eng Léisung déi nieft all Instanz vum Service agesat gëtt, ass e klenge Konsum vu RAM an CPU Zäit néideg. An natierlech soll d'Reaktiounsverspéidung och kleng sinn.
Loosst eis kucken wéi eng Resultater mir kruten.
Ram
Netramesh verbraucht ~10Mb ouni Traffic an 50Mb maximal mat enger Laascht vu bis zu 10000 RPS pro Instanz.
Istio Envoy Proxy verbraucht ëmmer ~300Mb an eise Cluster mat Dausende vun Instanzen. Dëst erlaabt et net op de ganze Cluster ze skaléieren.
Mat Netramesh hu mir eng ~ 10x Reduktioun am Erënnerungsverbrauch kritt.
cpu
CPU Notzung ass relativ gläich ënner Laascht. Et hänkt vun der Unzuel vun Ufroen pro Zäitunitéit un de Sidecar of. Wäerter bei 3000 Ufroen pro Sekonn am Peak:
Et gëtt e méi wichtege Punkt: Netramesh - eng Léisung ouni Kontrollplang an ouni Laascht verbraucht keng CPU Zäit. Mat Istio update Sidecars ëmmer Service Endpunkter. Als Resultat kënne mir dëst Bild ouni Laascht gesinn:
Mir benotzen HTTP/1 fir Kommunikatioun tëscht Servicer. D'Erhéijung vun der Äntwertzäit fir Istio beim Proxying duerch Envoy war bis zu 5-10ms, wat zimmlech vill ass fir Servicer déi prett sinn an enger Millisekonnen ze reagéieren. Mat Netramesh ass dës Zäit op 0.5-2ms erofgaang.
Skalierbarkeet
Déi kleng Quantitéit vun Ressourcen vun all Proxy verbraucht mécht et méiglech et nieft all Service ze Plaz. Netramesh gouf bewosst ouni Kontrollplanekomponent erstallt fir einfach all Sidecar liicht ze halen. Dacks an Service Mesh Léisungen, verdeelt de Kontrollfliger Service Entdeckungsinformatioun un all Sidecar. Zesumme mat et kënnt Informatioun iwwer Timeouts a Balancéierungsastellungen. All dëst erlaabt Iech vill nëtzlech Saachen ze maachen, awer, leider, et bloats Sidecars an der Gréisst.
Service Entdeckung
Netramesh füügt keng zousätzlech Mechanismen fir Service Entdeckung. All Traffic gëtt transparent duerch Netra Sidecar proxéiert.
Netramesh ënnerstëtzt HTTP/1 Applikatiounsprotokoll. Fir et ze definéieren, gëtt eng konfiguréierbar Lëscht vu Ports benotzt. Typesch huet de System e puer Ports duerch déi HTTP-Kommunikatioun geschitt. Zum Beispill benotze mir 80, 8890, 8080 fir Interaktioun tëscht Servicer an externen Ufroen.An dësem Fall kënne se mat enger Ëmfeldvariabel gesat ginn NETRA_HTTP_PORTS.
Wann Dir Kubernetes als Orchester a säi Service Entity Mechanismus fir Intra-Cluster Kommunikatioun tëscht Servicer benotzt, da bleift de Mechanismus genau d'selwecht. Als éischt kritt de Mikroservice eng Service IP Adress mat kube-dns a mécht eng nei Verbindung dozou op. Dës Verbindung gëtt fir d'éischt mat der lokaler Netra-Sidecar etabléiert an all TCP-Päckchen ufanks ukomm bei Netra. Als nächst stellt netra-sidecar eng Verbindung mat der ursprénglecher Destinatioun. NAT op Pod IP um Node bleift genau d'selwecht wéi ouni Netra.
Verdeelt Tracing a Kontext Forwarding
Netramesh bitt d'Funktionalitéit déi néideg ass fir Tracingspann iwwer HTTP Interaktiounen ze schécken. Netra-sidecar parséiert den HTTP Protokoll, moosst Ufro Verspéidungen, an extrahéiert déi néideg Informatioun aus HTTP Header. Schlussendlech kréie mir all Spuren an engem eenzege Jaeger System. Fir feinkorrekt Konfiguratioun kënnt Dir och d'Ëmfeldvariablen benotzen, déi vun der offizieller Bibliothéik geliwwert gëtt .
Mä et gëtt e Problem. Bis d'Servicer e speziellen Uber Header generéieren a schécken, wäerte mir keng verbonne Tracingspann am System gesinn. An dat ass wat mir brauchen fir séier d'Ursaach vu Problemer ze fannen. Hei huet Netramesh erëm eng Léisung. Proxies liesen HTTP Header a, wa se net d'Uber Trace ID enthalen, generéiert een. Netramesh späichert och Informatioun iwwer erakommen an erausginn Ufroen an engem Sidecar a passt hinnen andeems se se mat den néidegen erausginn Ufro Header beräichert. Alles wat Dir maache musst an de Servicer ass just een Header ze schécken X-Request-Id, déi mat enger Ëmfeldvariabel konfiguréiert ka ginn NETRA_HTTP_REQUEST_ID_HEADER_NAME. Fir d'Gréisst vum Kontext am Netramesh ze kontrolléieren, kënnt Dir déi folgend Ëmfeldvariablen setzen: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (d'Zäit fir déi de Kontext gespäichert gëtt) an NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (Frequenz vum Kontextbotz).
Et ass och méiglech verschidde Weeër op Ärem System ze kombinéieren andeems Dir se mat engem speziellen Sessiounstoken markéiert. Netra erlaabt Iech ze installéieren HTTP_HEADER_TAG_MAP fir HTTP-Header an entspriechend Tracing-Spann-Tags ëmzewandelen. Dëst kann besonnesch nëtzlech sinn fir ze testen. Nodeems Dir de funktionnelle Test passéiert hutt, kënnt Dir gesinn wéi en Deel vum System duerch Filterung vum entspriechende Sessiounsschlëssel beaflosst gouf.
Bestëmmung vun der Ufro Quell
Fir ze bestëmmen wou d'Ufro hierkënnt, kënnt Dir d'Funktionalitéit benotzen fir automatesch en Header mat der Quell ze addéieren. Benotzt eng Ëmfeld Variabel NETRA_HTTP_X_SOURCE_HEADER_NAME Dir kënnt en Header Numm uginn, deen automatesch installéiert gëtt. Duerch d'Benotzung NETRA_HTTP_X_SOURCE_VALUE Dir kënnt de Wäert setzen op deen den X-Source Header fir all erausginn Ufroe gesat gëtt.
Dëst erlaabt d'Verdeelung vun dësem nëtzlechen Header eenheetlech am ganze Netz ze verdeelen. Da kënnt Dir et a Servicer benotzen an et zu Logbicher a Metriken addéieren.
Traffic Routing an Netramesh Interns
Netramesh besteet aus zwee Haaptkomponenten. Déi éischt, netra-init, setzt Netzwierkregele fir den Traffic z'ënnerscheeden. Hie benotzt fir de ganzen oder en Deel vum Verkéier um Sidecar z'ënnerscheeden, wat den zweeten Haaptkomponent vun Netramesh ass. Dir kënnt konfiguréieren wéi eng Ports musse fir Entréeën an erausginn TCP Sessiounen ofgeholl ginn: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Den Tool huet och eng interessant Feature - probabilistesch Routing. Wann Dir Netramesh exklusiv benotzt fir Tracing Spann ze sammelen, da kënnt Dir an engem Produktiounsëmfeld Ressourcen spueren a probabilistesch Routing mat Variablen aktivéieren NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (vun 0 bis 1). De Standardwäert ass 1 (all Traffic gëtt ofgefaangen).
No erfollegräich ofgefaangen, netra sidecar acceptéiert déi nei Verbindung a benotzt SO_ORIGINAL_DST Socket Optioun fir d'Original Destinatioun ze kréien. Netra mécht dann eng nei Verbindung mat der ursprénglecher IP Adress op a stellt zwee-Wee TCP Kommunikatioun tëscht de Parteien op, lauschtert op all Traffic, deen duerch passéiert. Wann den Hafen als HTTP definéiert ass, probéiert Netra et ze analyséieren an ze verfolgen. Wann HTTP-Parsing feelt, fällt Netra zréck op TCP a proxéiert transparent d'Bytes.
Bauen eng Ofhängegkeet Grafik
Nodeems ech eng grouss Quantitéit vun Tracing Informatioun am Jaeger kritt hunn, wëll ech eng komplett Grafik vun Interaktiounen am System kréien. Awer wann Äre System zimmlech gelueden ass a Milliarden Tracingspann pro Dag accumuléieren, gëtt se aggregéiert net sou eng einfach Aufgab. Et gëtt en offiziellen Wee fir dëst ze maachen: . Wéi och ëmmer, et wäert Stonnen daueren fir eng komplett Grafik ze bauen a wäert Iech zwéngen de ganzen Dataset vu Jaeger fir déi lescht XNUMX Stonnen erofzelueden.
Wann Dir Elasticsearch benotzt fir Tracingspann ze späicheren, kënnt Dir benotzen , déi déiselwecht Grafik a Minutten opbaut mat de Funktiounen a Fäegkeeten vun Elasticsearch.
Wéi benotzt Dir Netramesh
Netra kann einfach zu all Service bäigefüügt ginn, deen all Orchestrator leeft. Dir kënnt e Beispill gesinn .
Am Moment huet Netra net d'Fäegkeet fir automatesch Sidecars op Servicer ëmzesetzen, awer et gi Pläng fir d'Ëmsetzung.
D'Zukunft vun Netramesh
Haaptziel ass fir minimal Ressourcekäschten an héich Leeschtung z'erreechen, Basisfäegkeete fir Observabilitéit a Kontroll vun der Inter-Service Kommunikatioun ubidden.
An Zukunft wäert Netramesh aner Applikatiounsschichtprotokoller nieft HTTP ënnerstëtzen. L7 Routing wäert an der nächster Zukunft verfügbar sinn.
Benotzt Netramesh wann Dir ähnlech Probleemer begéint a schreift eis mat Froen a Virschléi.
Source: will.com