As wy ferhúzje fan in monolityske applikaasje nei in arsjitektuer foar mikrotsjinsten, steane wy foar nije útdagings.
Yn in monolityske tapassing is it normaal frij maklik om te bepalen yn hokker diel fan it systeem de flater barde. Meast wierskynlik is it probleem yn 'e koade fan' e monolyt sels, of yn 'e databank. Mar as wy begjinne te sykjen nei in probleem yn in microservice arsjitektuer, alles is net mear sa fanselssprekkend. Wy moatte it hiele paad fine dat it fersyk naam fan begjin oant ein en selektearje it út hûnderten mikrotsjinsten. Boppedat hawwe in protte fan harren ek har eigen opslachfoarsjenningen, dy't ek logyske flaters kinne feroarsaakje, lykas problemen mei prestaasjes en fouttolerânsje.
Ik haw in lange tiid socht nei in ark dat soe helpe om te gean mei sokke problemen (ik skreau hjiroer op Habré: , ), mar op it lêst makke ik myn eigen iepen boarne-oplossing. Yn dit artikel praat ik oer de foardielen fan 'e tsjinstmesh-oanpak en diel in nij ark foar de ymplemintaasje dêrfan.
Ferspraat tracing is in mienskiplike oplossing foar it probleem fan it finen fan flaters yn ferspraat systemen. Mar wat as dizze oanpak foar it sammeljen fan ynformaasje oer netwurkynteraksjes noch net yn it systeem is ymplementearre, of, slimmer, yn in diel fan it systeem wurket it al goed, mar foar in part net, om't it net is tafoege oan âlde tsjinsten ? Om de krekte oarsaak fan in probleem te bepalen, is it nedich om in folslein byld te hawwen fan wat der bart yn it systeem. It is foaral wichtich om te begripen hokker mikrotsjinsten belutsen binne by wichtige saaklike krityske paden.
Hjir kin de tsjinstmesh-oanpak ús helpe, dy't sil omgean mei alle masines foar it sammeljen fan netwurkynformaasje op in nivo leger as de tsjinsten sels wurkje. Dizze oanpak lit ús alle ferkear ûnderskeppe en it op 'e flecht analysearje. Boppedat hoege applikaasjes der sels neat fan te witten.
Service mesh oanpak
It haadidee fan 'e tsjinstmesh-oanpak is om in oare ynfrastruktuerlaach ta te foegjen oer it netwurk, wêrtroch wy alles kinne dwaan mei ynteraksje ynteraksje. De measte ymplemintaasjes wurkje as folget: in ekstra sidecar-container mei in transparante proxy wurdt tafoege oan elke mikroservice, wêrtroch alle ynkommende en útgeande ferkear fan 'e tsjinst trochjûn wurdt. En dit is it krekte plak wêr't wy klantbalansearje kinne, feiligensbelied tapasse, beheiningen oplizze op it oantal oanfragen en wichtige ynformaasje sammelje oer de ynteraksje fan tsjinsten yn produksje.
Oplossingen
D'r binne al ferskate ymplemintaasjes fan dizze oanpak: и . Se jouwe in protte funksjes út 'e doaze. Mar tagelyk komt der in grutte overhead op middels. Boppedat, hoe grutter it kluster dêr't sa'n systeem yn wurket, hoe mear middels nedich binne om de nije ynfrastruktuer te ûnderhâlden. By Avito operearje wy kubernetes-klusters dy't tûzenen tsjinstynstânsjes befetsje (en har oantal bliuwt hurd groeie). Yn syn hjoeddeistige ymplemintaasje verbruikt Istio ~300Mb RAM per tsjinsteksimplaar. Troch it grutte oantal mooglikheden hat trochsichtige balâns ek ynfloed op de totale antwurdtiid fan tsjinsten (oant 10ms).
As gefolch hawwe wy krekt sjoen nei hokker mooglikheden wy no krekt nedich wiene, en besletten dat de wichtichste reden wêrom't wy begon te ymplementearjen fan sokke oplossingen wie de mooglikheid om tracingynformaasje fan it heule systeem transparant te sammeljen. Wy woenen ek kontrôle hawwe oer de ynteraksje fan tsjinsten en ferskate manipulaasjes dwaan mei de kopteksten dy't oerdroegen wurde tusken tsjinsten.
Dêrtroch kamen wy ta ús beslút: .
Netramesh
is in lichtgewicht tsjinstmesh-oplossing mei de mooglikheid om ûneinich te skaaljen, nettsjinsteande it oantal tsjinsten yn it systeem.
De haaddoelen fan 'e nije oplossing wiene lege boarne-overhead en hege prestaasjes. Under de haadfunksjes woene wy fuortdaliks tracingspannen transparant kinne stjoere nei ús Jaeger-systeem.
Tsjintwurdich wurde de measte wolkoplossingen ymplementearre yn Golang. En, fansels, binne d'r redenen foar dit. It skriuwen fan netwurkapplikaasjes yn Golang dy't asynchronysk wurkje mei I/O en skaal oer kearnen as nedich is handich en frij ienfâldich. En, wat ek heul wichtich is, de prestaasjes is genôch om dit probleem op te lossen. Dêrom hawwe wy ek foar Golang keazen.
Produktiviteit
Wy hawwe ús ynspanningen rjochte op it berikken fan maksimale produktiviteit. Foar in oplossing dy't wurdt ynset neist elke eksimplaar fan de tsjinst, is in lyts konsumpsje fan RAM en CPU tiid nedich. En fansels moat de antwurdfertraging ek lyts wêze.
Litte wy sjen hokker resultaten wy krigen.
RAAM
Netramesh konsumearret ~10Mb sûnder ferkear en 50Mb maksimum mei in lading fan maksimaal 10000 RPS per eksimplaar.
Istio envoy proxy konsumearret altyd ~300Mb yn ús klusters mei tûzenen eksimplaren. Dit makket it net mooglik om te skaaljen nei it hiele kluster.
Mei Netramesh krigen wy in ~ 10x reduksje yn ûnthâldferbrûk.
CPU
CPU-gebrûk is relatyf gelyk ûnder load. It hinget ôf fan it oantal oanfragen per ienheid fan tiid nei de sydspan. Wearden by 3000 oanfragen per sekonde by peak:
D'r is noch ien wichtich punt: Netramesh - in oplossing sûnder kontrôlefleantúch en sûnder lading ferbrûkt gjin CPU-tiid. Mei Istio update sidecars altyd tsjinsteinpunten. As gefolch kinne wy dizze foto sûnder lading sjen:
Wy brûke HTTP/1 foar kommunikaasje tusken tsjinsten. De ferheging fan reaksjetiid foar Istio by proxying fia envoy wie oant 5-10ms, wat frijwat is foar tsjinsten dy't ree binne om te reagearjen yn in millisekonde. Mei Netramesh is dizze tiid ôfnommen nei 0.5-2ms.
Skalberens
De lytse hoemannichte boarnen konsumeare troch elke proxy makket it mooglik om it neist elke tsjinst te pleatsen. Netramesh waard mei opsetsin makke sûnder in komponint fan in kontrôlefleanmasine om elke sidecar ienfâldich te hâlden. Faak yn tsjinstmesh-oplossingen distribuearret it kontrôlefleanmasine tsjinstûntdekkingynformaasje oan elke sidecar. Tegearre mei it komt ynformaasje oer timeouts en balânsynstellingen. Dit alles lit jo in protte nuttige dingen dwaan, mar spitigernôch blaast it sidecars yn grutte.
Service ûntdekking
Netramesh foeget gjin ekstra meganismen ta foar ûntdekking fan tsjinsten. Alle ferkear wurdt transparant proxied fia netra sidecar.
Netramesh stipet HTTP/1-applikaasjeprotokol. Om it te definiearjen, wurdt in ynstelbere list fan havens brûkt. Typysk hat it systeem ferskate havens wêrby't HTTP-kommunikaasje bart. Foar ynteraksje tusken tsjinsten en eksterne oanfragen brûke wy bygelyks 80, 8890, 8080. Yn dit gefal kinne se ynsteld wurde mei in omjouwingsfariabele NETRA_HTTP_PORTS.
As jo Kubernetes brûke as orkestrator en har Service-entiteitmeganisme foar intra-clusterkommunikaasje tusken tsjinsten, dan bliuwt it meganisme krekt itselde. Earst krijt de mikroservice in tsjinst IP-adres mei kube-dns en iepenet in nije ferbining dêrmei. Dizze ferbining wurdt earst oprjochte mei de lokale netra-sidecar en alle TCP-pakketten komme yn earste ynstânsje by netra. Dêrnei stelt netra-sidecar in ferbining mei de oarspronklike bestimming. NAT op pod IP op it knooppunt bliuwt krekt itselde as sûnder netra.
Ferspraat tracing en kontekst trochstjoere
Netramesh leveret de funksjonaliteit dy't nedich is om tracing-spannen oer HTTP-ynteraksjes te ferstjoeren. Netra-sidecar parseart it HTTP-protokol, mjit fertragingen foar fersyk, en ekstrakt de nedige ynformaasje út HTTP-headers. Uteinlik krije wy alle spoaren yn ien Jaeger-systeem. Foar fynkorrelige konfiguraasje kinne jo ek gebrûk meitsje fan de omjouwingsfariabelen levere troch de offisjele bibleteek .
Mar der is in probleem. Oant tsjinsten in spesjale uber-koptekst generearje en ferstjoere, sille wy gjin ferbûne tracing-spannen yn it systeem sjen. En dit is wat wy moatte fluch fine de oarsaak fan problemen. Hjir hat Netramesh wer in oplossing. Proxies lêze HTTP-headers en, as se de uber-trace-id net befetsje, generearje ien. Netramesh bewarret ek ynformaasje oer ynkommende en útgeande oanfragen yn in sidecar en komt oerien mei se troch se te ferrykjen mei de nedige útgeande fersykkoppen. Alles wat jo hoege te dwaan yn 'e tsjinsten is mar ien koptekst te stjoeren X-Request-Id, dat kin wurde konfigurearre mei in omjouwingsfariabele NETRA_HTTP_REQUEST_ID_HEADER_NAME. Om de grutte fan 'e kontekst yn Netramesh te kontrolearjen, kinne jo de folgjende omjouwingsfariabelen ynstelle: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (de tiid wêrfoar de kontekst wurdt opslein) en NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (frekwinsje fan kontekst skjinmeitsjen).
It is ek mooglik om meardere paden op jo systeem te kombinearjen troch se te markearjen mei in spesjale sesjetoken. Netra kinne jo ynstallearje HTTP_HEADER_TAG_MAP om HTTP-koppen te feroarjen yn korrespondearjende tracing span-tags. Dit kin benammen nuttich wêze foar testen. Nei it trochjaan fan de funksjonele test kinne jo sjen hokker diel fan it systeem beynfloede is troch filterjen troch de oerienkommende sesjekaai.
Bepale de boarne fan fersyk
Om te bepalen wêr't it fersyk weikomt, kinne jo de funksjonaliteit brûke fan automatysk in koptekst mei de boarne ta te foegjen. Mei help fan in omjouwingsfariabele NETRA_HTTP_X_SOURCE_HEADER_NAME Jo kinne in koptekstnamme opjaan dy't automatysk ynstalleare sil. Troch te brûken NETRA_HTTP_X_SOURCE_VALUE jo kinne de wearde ynstelle wêrop de X-Source-koptekst sil wurde ynsteld foar alle útgeande oanfragen.
Hjirmei kin de ferdieling fan dizze nuttige koptekst unifoarm oer it netwurk ferdield wurde. Dan kinne jo it brûke yn tsjinsten en it tafoegje oan logs en metriken.
Ferkear routing en Netramesh ynterne
Netramesh bestiet út twa haadkomponinten. De earste, netra-init, stelt netwurkregels yn om ferkear te ûnderskeppen. Hy brûkt om it hiele of in part fan it ferkear op sidecar te ûnderskeppen, dat is de twadde haadkomponint fan Netramesh. Jo kinne ynstelle hokker havens moatte wurde ûnderskept foar ynkommende en útgeande TCP-sesjes: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
It ark hat ek in nijsgjirrige funksje - probabilistyske routing. As jo Netramesh eksklusyf brûke foar it sammeljen fan tracing-spannen, dan kinne jo yn in produksjeomjouwing boarnen besparje en probabilistyske routing ynskeakelje mei fariabelen NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (fan 0 oant 1). De standertwearde is 1 (alle ferkear wurdt ûnderskept).
Nei suksesfolle ûnderskepping akseptearret netra sidecar de nije ferbining en brûkt SO_ORIGINAL_DST socket opsje om de orizjinele bestimming te krijen. Netra iepenet dan in nije ferbining mei it orizjinele IP-adres en stelt twa-wei TCP-kommunikaasje tusken de partijen, harket nei alle ferkear dat troch giet. As de poarte is definiearre as HTTP, besiket Netra it te parsearjen en te spoaren. As HTTP-parsing mislearret, falt Netra werom nei TCP en proxearret de bytes transparant.
It bouwen fan in ôfhinklikensgrafyk
Nei it ûntfangen fan in grutte hoemannichte tracing-ynformaasje yn Jaeger, wol ik in folsleine grafyk krije fan ynteraksjes yn it systeem. Mar as jo systeem frijwat laden is en miljarden tracing-spannen per dei sammelje, wurdt it aggregearjen net sa'n maklike taak. D'r is in offisjele manier om dit te dwaan: . It sil lykwols oeren duorje om in folsleine grafyk te bouwen en sil jo twinge om de folsleine dataset fan Jaeger foar de ôfrûne XNUMX oeren te downloaden.
As jo Elasticsearch brûke om tracing-spans op te slaan, kinne jo gebrûk meitsje , dy't deselde grafyk yn minuten sil bouwe mei de funksjes en mooglikheden fan Elasticsearch.
Hoe kinne jo Netramesh brûke
Netra kin maklik wurde tafoege oan elke tsjinst dy't elke orkestrator útfiert. Jo kinne in foarbyld sjen .
Op it stuit hat Netra net de mooglikheid om sidecars automatysk oan tsjinsten te ymplementearjen, mar d'r binne plannen foar ymplemintaasje.
De takomst fan Netramesh
haaddoel is om minimale boarnekosten en hege prestaasjes te berikken, it leverjen fan basismooglikheden foar observabiliteit en kontrôle fan kommunikaasje tusken tsjinsten.
Yn 'e takomst sil Netramesh oare applikaasjeslaachprotokollen stypje neist HTTP. L7-routing sil yn 'e heine takomst beskikber wêze.
Brûk Netramesh as jo ferlykbere problemen tsjinkomme en skriuw nei ús mei fragen en suggestjes.
Boarne: www.habr.com