Monoliitrakenduselt mikroteenuste arhitektuurile üleminekul seisame silmitsi uute probleemidega.

Monoliitrakenduses on tavaliselt piisav, et lihtsalt määrata, kus süsteemis probleem tekkis. Tõenäoliselt on probleem ise monoliidi koodis või andmebaasis. Kuid kui hakkame probleemi otsima mikroteenuste arhitektuuris, ei ole enam nii selge. Peame leidma kogu tee, mida päring läbis algusest lõpuni, eristades seda sadadest mikroteenustest. Paljudel neist on ka oma andmehoidlad, kus võivad esineda nii loogilised vead kui ka jõudlus- ja talitlushäired.

Otsisin pikka aega tööriista, mis aitaks selliste probleemidega tegeleda (kirjutasin sellest Habrisse: 1, 2), kuid lõppkokkuvõttes tegin oma avatud lähtekoodiga lahenduse. Artiklis räägin teenuste mesh'i lähenemisviisi eelistest ja jagan uut tööriista selle rakendamiseks.

Jaotatud jälgimine on levinud lahendus probleemide leidmiseks jaotatud süsteemides. Kuid mis siis, kui süsteemis ei ole sellist lähenemist veel sisse viidud või, mis on veel halvem, toimib see süsteemi osas korralikult, kuid teises osas ei ole see olemas, kuna see ei ole vanadesse teenustesse lisatud? Probleemi täpse juurpõhjuse määramiseks on oluline omada täielikku ülevaadet sellest, mis süsteemis toimub. Eriti tähtis on mõista, millised mikroteenused osalevad peamistes äri jaoks kriitilistes teedes.

Siin saab meile appi tulla teenuste mesh'i lähenemine, mis tegeleb kogu võrguinfo kogumise alustegevustega, mis toimib madalamal tasemel kui teenused ise. See lähenemine võimaldab meil kogu liiklust pealt kuulata ja seda reaalajas analüüsida. Ja veel, rakendused ei pea sellest isegi midagi teadma.

Teenuste mesh'i lähenemine

Service mesh lähenemise peamine idee on lisada võrgu kohal veel üks infrastruktuuri kiht, mis võimaldab meil teha kõikvõimalikke asju teenustevahelise suhtluse osas. Enamik teostusi töötab järgmiselt: iga mikroteenusele lisatakse täiendav sidecar konteiner koos läbipaistva proksiga, mille kaudu suunatakse kogu teenuse sisenev ja väljuv liiklus. Ja siin saame me teha kliendipoolset koormuse tasakaalustamist, rakendada turvapoliitikaid, seada piiranguid päringute arvule ning koguda olulist teavet teenustevahelise suhtluse kohta tootmises.

Lahendused

Juba on olemas mitu selle lähenemise teostust: Istio ja linkerd2. Need pakuvad palju funktsioone kohe välja pakkudes. Kuid koos sellega tuleb ka suur ressursi ületäitus. Mida suurem on klaster, milles selline süsteem töötab, seda rohkem ressursse on vaja uue infrastruktuuri toetamiseks. Avitos kasutame Kubernetes klastreid, milles on tuhandeid teenuse eksemplare (ja nende arv kasvab kiiresti). Praeguses teostuses tarvitab Istio ~300Mb RAM-i igas teenuse eksemplaris. Suure hulga võimaluste tõttu mõjutab läbipaistev koormuse tasakaalustamine ka teenuste koguaega (kuni 10ms).

Kokkuvõttes vaatasime, milliseid võimalusi me just nüüd vajame, ja otsustasime, et peamine põhjus, miks alustasime selliste lahenduste rakendamist, oli võimalus koguda jälgimisteavet kogu süsteemist läbipaistvalt. Samuti soovisime omada kontrolli teenustevahelise suhtluse üle ja teha erinevaid manipulatsioone teenuste vahel edastatavate pealkirjadega.

Lõppkokkuvõttes jõudsime oma lahenduseni:  Netramesh.

Netramesh

Netramesh on kerge service mesh lahendus, mis võimaldab piiramatu skaleerimist sõltumata teenuste arvust süsteemis.

Uue lahenduse peamised eesmärgid olid väike ressursi ületäide ja kõrge jõudlus. Peamistest funktsioonidest soovisime kohe võimalust saadetada jälgimisseadet meie Jaeger süsteemi läbipaistvalt.

Tänapäeval põhinevad enamik pilve lahendusi Golangil. Ja sellel on oma põhjused. Golangis võrgu rakenduste kirjutamine, mis töötavad asünkroonselt sisendi-väljundi ja skaleeruvad vajadusel tuumadele, on mugav ja piisavalt lihtne. Ja mis veelgi olulisem, jõudlus on piisav sellise ülesande lahendamiseks. Seetõttu valisime ka meie Golangi.

Tõhusus

Keskendusime oma pingutustes maksimaalse jõudluse saavutamisele. Lahenduse puhul, mida kasutatakse iga teenuse eksemplari kõrval, on oluline väike mälu ja protsessori kasutus. Ja loomulikult peab vastuse hilinemine olema samuti minimaalne.

Vaatame, millised tulemused saime.

RAM

Netramesh tarbib ~10Mb ilma liikluseta ja 50Mb maksimaalselt koormuse korral kuni 10000 RPS ühe eksemplari kohta.

Istio envoy proxy tarbib alati ~300Mb meie klastrites tuhandete eksemplaridega. See ei võimalda skaleerida seda kogu klastrile.

Netrameshiga saime mälu tarbimist vähendada ~10 korda.

CPU

CPU kasutus on koormuse all suhteliselt ühtlane. See sõltub soovide hulgast ajaühikus sidecarile. 3000 soovi sekundis tipptasemel väärtused:

On veel üks oluline aspekt: Netramesh on lahendus ilma kontrollplaanita ja ilma koormuseta ei tarbi see protsessori aega. Istio sidecarid uuendavad alati teenuste lõpp-punkte. Lõppkokkuvõttes saame sellise pildi ilma koormuseta:

Kasutame teenuste vahel suhtlemiseks HTTP/1. Istio vastuse hilinemine envoy kaudu proksitamisel oli kuni 5-10ms, mis on piisavalt palju teenuste jaoks, mis on valmis vastama millisekundi jooksul. Netrameshiga vähenes see aeg 0.5-2ms.

Skaleeritavus

Iga proxy vähene ressursside kasutamine võimaldab seda paigutada igasse teenusesse lähemale. Netramesh loodi sihilikult ilma kontrollplaani komponendita, et säilitada iga sidecar'i kerge kaal. Tihti teenuse masinas lahendustes jagab kontrollplaan teenuse avastamise teavet igasse sidecar'i. Koos sellega tuleb ka teave ajutiste piirangute ja tasakaalustamiseseadete kohta. Kõik see võimaldab palju kasulikke asju, kuid kahjuks paisutab see sidecar'e suuruses.

Teenuse avastamine

Netramesh ei lisa teenuse avastamiseks mingeid täiendavaid mehhanisme. Kogu liiklus proksitakse läbipaistvalt netra sidecar'i kaudu.

Netramesh toetab HTTP/1 rakendusprotokolli. Selle määramiseks kasutatakse konfigureeritavat sadamate loendit. Tüüpiliselt on süsteemis mitu porti, mille kaudu toimub HTTP suhtlemine. Näiteks meie süsteemis kasutame teenuste ja väliste päringute vahel 80, 8890, 8080. Sel juhul saab neid määrata keskkonnamuutujaga. NETRA_HTTP_PORTS.

Kui kasutate Kubernetes'i orkestratsioonina ja selle Service mehhanismi siseklastri teenuste vaheliseks suhtlemiseks, jääb mehhanism samaks. Esiteks saab mikroteenus service IP-aadressi kube-dns-i kaudu ja avab sellele uue ühenduse. See ühendus luuakse esmalt kohaliku netra-sidecariga ja kõik TCP paketid jõuavad esmalt netra juurde. Edasi loob netra-sidecar ühenduse algse sihtkoha juurde. NAT pod IP-l sõlmes jääb samaks nagu ka ilma netra'ita.

Jaotatud jälgimine ja konteksti edastamine

Netramesh pakub funktsionaalsust, mis on vajalik HTTP suhtlemise jälgimisfuuside saatmiseks. Netra-sidecar analüüsib HTTP protokolli, mõõdab päringute viivitusi ja toob vajalikku teavet HTTP päistest. Lõppkokkuvõttes saame kõik jälgimised ühes Jaeger'i süsteemis. Peene konfigureerimise jaoks saab kasutada ka keskkonnamuutujaid, mida pakub ametlik raamatukogu. jaeger go library.

Kuid on probleem. Kuni teenused ei genereeri ja edasta spetsiaalset uber päist, ei näe me ühendatud jälgimisfuuse süsteemis. Ja see on see, mida meil on vaja probleemide kiireks tuvastamiseks. Siin on Netramesh'il taas lahendus. Proksid loevad HTTP päiseid ja kui neis ei ole uber jälgimise ID'd, genereerivad nad selle. Netramesh säilitab ka teavet sissetulevate ja väljaminevate päringute kohta sidecar'is ning seostab need vajalike päiste rikastamise teel väljaminevates päringutes. Kõik, mida on vaja teenustes teha, on edastada vaid üks päis. X-Request-Id, mida saab konfigureerida keskkonnamuutujaga. NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh'is konteksti suuruse juhtimiseks saab määrata järgmised keskkonnamuutujad: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (aeg, mille jooksul konteksti hoitakse) ja NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (konteksti puhastamise sagedus).

Samuti on võimalik kombineerida mitu teed teie süsteemis, tähistades neid erilise sessioonimarkeriga. Netra võimaldab seadistada HTTP_HEADER_TAG_MAP HTTP päiste muutmiseks vastavateks jälgimise span siltideks. See võib olla eriti kasulik testimise jaoks. Pärast funktsionaalset testi saab vaadata, milline osa süsteemist oli mõjutatud, filtreerides sobiva sessiooni võtme järgi.

Päringu allika määramine

Kuna määrata, kust päring tuli, saab kasutada automaatse pealkirja lisamise funktsiooni. Keskkonnamuutuja NETRA_HTTP_X_SOURCE_HEADER_NAME võimaldab määrata pealkirja nime, mis lisatakse automaatselt. Muutuja NETRA_HTTP_X_SOURCE_VALUE lubab määrata väärtuse, millega X-Source pealkiri seotakse kõikide väljuvate päringute puhul.

See võimaldab ühtselt kogu võrgus säilitada seda kasulikku pealkirja. Edasi on võimalik seda kasutada teenustes ja lisada logidesse, mõõtmistesse.

Liikluse suunamine ja Netrameshi sisemus

Netramesh koosneb kahest peamisest komponendist. Esimene, netra-init, seadistab võrgu reeglid liikluse püüdmiseks. See kasutab iptables redirect reegleid kogu või osa liikluse püüdmiseks sidecari, mis on Netrameshi teine peamine komponent. Saate seadistada, milliseid porte tuleb püüda sissetulevates ja väljaminevates TCP sessioonides: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

Samuti on tööriistal huvitav võimalus — tõenäosuslik suunamine. Kui kasutada Netrameshi ainult jälgimise span'ide kogumiseks, siis võib tootmisolukorras ressursse kokku hoida ja lubada tõenäosuslikku suunamist muutuja abil NETRA_INBOUND_PROBABILITY ja NETRA_OUTBOUND_PROBABILITY (0 kuni 1). Vaikimisi on väärtus 1 (kogu liiklus on püütud).

Pärast eduka püüdmist võtab netra sidecar uue ühenduse ja kasutab SO_ORIGINAL_DST soketi valikut, et saada algne sihtpunkt. Seejärel avab Netra uue ühenduse algse IP-aadressiga ja loob kahepoolse TCP suhtluse osapoolte vahel, kuulates kogu liikumat liiklust. Kui port on määratud kui HTTP, proovib Netra seda analüüsida ja jälgida. Kui HTTP analüüs ebaõnnestub, teeb Netra tagasiulatuva TCP ja läbipaistvalt proksib byte.

Sõltuvuste graafi koostamine

Pärast suuri tracing teabe kogumise sessioone Jaegeris tahaksin saada süsteemis täielikku suhtlemisgraafi. Kuid kui teie süsteem on piisavalt koormatud ja ühe päeva jooksul koguneb miljardite tracing span'ide arv, siis nende agregatsioon ei ole enam lihtne ülesanne. Selleks on ametlik viis: spark-dependencies. Siiski võib selle täieliku graafi koostamine võtta tunde ja sunnib teid alla laadima kogu jaotuse Jaegerist viimase 24 tunni kohta.

Kui kasutate tracing span'ide salvestamiseks Elasticsearch'i, siis saate kasutada lihtsat utiliiti Golang'is, mis koostab sarnase graafi minutitega, kasutades Elasticsearch'i omadusi ja võimalusi.

Kuidas kasutada Netrameshi

Netra saab lihtsalt lisada igale teenusele, mis töötab mis tahes orkestratori haldusel. Võite vaadata näidet siit.

Hetkel ei pakku Netra automaatset sidumise võimalust teenustele, kuid plaanid selle rakendamiseks on olemas.

Netrameshi tulevik

Peamine eesmärk Netramesh on saavutada minimaalne ressursikasutus ja kõrge sooritusvõime, pakkudes põhifunktsioone observability ja teenustevahelise suhtlemise kontrollimiseks.

Tulevikus toetab Netramesh lisaks HTTP-le ka teisi rakendusprotokolle. Varsti tuleb välja L7 suunamine.

Kasutage Netrameshi, kui seisate silmitsi sarnaste probleemidega, ja saatke meile oma küsimused ja ettepanekud.

Allikas: habr.com