Þegar við förum frá einhæfu forriti yfir í örþjónustuarkitektúr stöndum við frammi fyrir nýjum áskorunum.
Í einhæfu forriti er venjulega frekar auðvelt að ákvarða í hvaða hluta kerfisins villan kom upp. Líklegast er vandamálið í kóðanum á monolith sjálfum, eða í gagnagrunninum. En þegar við byrjum að leita að vandamáli í örþjónustuarkitektúr er allt ekki lengur svo augljóst. Við þurfum að finna alla leiðina sem beiðnin tók frá upphafi til enda og velja hana úr hundruðum örþjónustu. Þar að auki hafa margir þeirra einnig sína eigin geymsluaðstöðu, sem getur einnig valdið rökvillum, sem og vandamálum með frammistöðu og bilanaþol.
Ég hef lengi verið að leita að tæki sem gæti hjálpað til við að takast á við slík vandamál (ég skrifaði um þetta á Habré: , ), en á endanum bjó ég til mína eigin opna lausn. Í þessari grein tala ég um kosti þjónustunets nálgunarinnar og deili nýju tæki til innleiðingar hennar.
Dreifð rakning er algeng lausn á því vandamáli að finna villur í dreifðum kerfum. En hvað ef þessi aðferð við að safna upplýsingum um netsamskipti hefur ekki enn verið innleidd í kerfið, eða það sem verra er, í hluta kerfisins virkar hún nú þegar rétt, en að hluta ekki, þar sem henni hefur ekki verið bætt við gamla þjónustu ? Til að ákvarða nákvæmlega undirrót vandamála er nauðsynlegt að hafa heildarmynd af því sem er að gerast í kerfinu. Það er sérstaklega mikilvægt að skilja hvaða örþjónustur taka þátt í lykilviðskiptum mikilvægum leiðum.
Hér getur þjónustunetsaðferðin komið okkur til hjálpar, sem mun takast á við allar vélar til að safna netupplýsingum á lægra stigi en þjónustan sjálf rekur. Þessi nálgun gerir okkur kleift að stöðva alla umferð og greina hana á flugu. Þar að auki þurfa umsóknir ekki einu sinni að vita neitt um það.
Þjónustunet nálgun
Meginhugmynd þjónustumesh nálgunarinnar er að bæta við öðru innviðalagi yfir netið, sem gerir okkur kleift að gera hvað sem er með samskipti milli þjónustu. Flestar útfærslur virka sem hér segir: auka hliðarvagni með gagnsæjum umboði er bætt við hverja örþjónustu, þar sem öll inn- og út umferð þjónustunnar fer í gegnum. Og þetta er einmitt staðurinn þar sem við getum gert jafnvægi viðskiptavina, beitt öryggisstefnu, sett takmarkanir á fjölda beiðna og safnað mikilvægum upplýsingum um samspil þjónustu í framleiðslu.
Lausnir
Það eru nú þegar nokkrar útfærslur á þessari nálgun: и . Þeir bjóða upp á mikið af eiginleikum úr kassanum. En á sama tíma kemur mikill kostnaður á auðlindir. Þar að auki, því stærri klasi sem slíkt kerfi starfar í, því meira fjármagn þarf til að viðhalda nýjum innviðum. Hjá Avito rekum við kubernetes klasa sem innihalda þúsundir þjónustutilvika (og fjöldi þeirra heldur áfram að vaxa hratt). Í núverandi útfærslu eyðir Istio ~300Mb af vinnsluminni á hvert þjónustutilvik. Vegna mikils fjölda möguleika hefur gagnsæ jafnvægi einnig áhrif á heildarviðbragðstíma þjónustu (allt að 10 ms).
Þess vegna skoðuðum við nákvæmlega hvaða getu við þurftum núna og ákváðum að aðalástæðan fyrir því að við byrjuðum að innleiða slíkar lausnir væri hæfileikinn til að safna rakningarupplýsingum úr öllu kerfinu á gagnsæjan hátt. Við vildum líka hafa stjórn á samspili þjónustu og gera ýmsar aðgerðir með hausana sem eru fluttir á milli þjónustu.
Í kjölfarið komumst við að ákvörðun okkar: .
Netramesh
er létt þjónustunetslausn með getu til að skala endalaust, óháð fjölda þjónustu í kerfinu.
Meginmarkmið nýju lausnarinnar voru lítil auðlindakostnaður og mikil afköst. Meðal helstu eiginleika, vildum við strax geta sent rakningarsvið á gagnsæjan hátt til Jaeger kerfisins okkar.
Í dag eru flestar skýjalausnir innleiddar í Golang. Og auðvitað eru ástæður fyrir þessu. Það er þægilegt og frekar einfalt að skrifa netforrit í Golang sem vinna ósamstillt við I/O og skala yfir kjarna eftir þörfum. Og það sem er líka mjög mikilvægt, árangur er nægjanlegur til að leysa þetta vandamál. Þess vegna völdum við líka Golang.
Framleiðni
Við höfum einbeitt okkur að því að ná hámarks framleiðni. Fyrir lausn sem er sett upp við hliðina á hverju tilviki þjónustunnar þarf lítilsháttar notkun á vinnsluminni og örgjörvatíma. Og auðvitað ætti seinkun á svörum líka að vera lítil.
Við skulum sjá hvaða niðurstöður við fengum.
RAM
Netramesh eyðir ~10Mb án umferðar og 50Mb að hámarki með allt að 10000 RPS álag á hvert tilvik.
Istio sendifulltrúi eyðir alltaf ~300Mb í klösunum okkar með þúsundum tilvika. Þetta gerir það að verkum að það er ekki hægt að skala það í allan klasann.
Með Netramesh fengum við ~10x minnkun á minnisnotkun.
CPU
Örgjörvanotkun er tiltölulega jöfn undir álagi. Það fer eftir fjölda beiðna á hverja tímaeiningu í hliðarvagninn. Gildi við 3000 beiðnir á sekúndu þegar mest var:
Það er eitt mikilvægara atriði: Netramesh - lausn án stjórnunarplans og án álags eyðir ekki CPU tíma. Með Istio uppfæra hliðarvagnar alltaf þjónustuendapunkta. Fyrir vikið getum við séð þessa mynd án hleðslu:
Við notum HTTP/1 fyrir samskipti milli þjónustu. Aukning á viðbragðstíma fyrir Istio við umboð í gegnum sendifulltrúa var allt að 5-10ms, sem er töluvert mikið fyrir þjónustur sem eru tilbúnar til að svara á millisekúndu. Með Netramesh hefur þessi tími minnkað í 0.5-2ms.
Stærð
Lítið magn af auðlindum sem hver umboðsmaður notar gerir það mögulegt að setja það við hlið hverrar þjónustu. Netramesh var viljandi búið til án stjórnflugvélarhluta til að halda hverjum hliðarvagni léttum. Oft í þjónustunetslausnum dreifir stjórnvélin þjónustuuppgötvunarupplýsingum til hvers hliðarvagns. Ásamt því koma upplýsingar um tímamörk og jafnvægisstillingar. Allt þetta gerir þér kleift að gera fullt af gagnlegum hlutum, en því miður stækkar það hliðarvagnar að stærð.
Þjónustuuppgötvun
Netramesh bætir ekki við neinum viðbótaraðferðum til að uppgötva þjónustu. Öll umferð er send á gagnsæjan hátt í gegnum netra hliðarvagn.
Netramesh styður HTTP/1 forritasamskiptareglur. Til að skilgreina það er stillanleg listi yfir höfn notaður. Venjulega hefur kerfið nokkrar hafnir þar sem HTTP samskipti eiga sér stað. Til dæmis notum við 80, 8890, 8080 fyrir samskipti milli þjónustu og ytri beiðna. Í þessu tilviki er hægt að stilla þær með því að nota umhverfisbreytu NETRA_HTTP_PORTS.
Ef þú notar Kubernetes sem hljómsveitarstjóra og þjónustueiningakerfi þess fyrir samskipti innan klasa milli þjónustu, þá er vélbúnaðurinn nákvæmlega sá sami. Í fyrsta lagi fær örþjónustan IP-tölu þjónustunnar með því að nota kube-dns og opnar nýja tengingu við hana. Þessari tengingu er fyrst komið á við staðbundna netra-hliðarvagninn og allir TCP pakkar koma upphaflega til netra. Næst kemur netra-sidecar á tengingu við upprunalega áfangastaðinn. NAT á pod IP á hnútnum er nákvæmlega það sama og án netra.
Dreifð rakning og framsending samhengis
Netramesh veitir þá virkni sem þarf til að senda rakningarsvið um HTTP-samskipti. Netra-sidecar greinir HTTP samskiptareglur, mælir tafir á beiðnum og dregur út nauðsynlegar upplýsingar úr HTTP hausum. Að lokum fáum við öll ummerki í einu Jaeger kerfi. Fyrir fínkorna uppsetningu geturðu líka notað umhverfisbreyturnar sem opinbera bókasafnið gefur .
En það er vandamál. Þangað til þjónusta býr til og sendir sérstakan uber haus munum við ekki sjá tengd rekjasvið í kerfinu. Og þetta er það sem við þurfum til að finna fljótt orsök vandamála. Hér hefur Netramesh aftur lausn. Umboðsmenn lesa HTTP hausa og, ef þeir innihalda ekki uber rekja auðkennið, búa þeir til einn. Netramesh geymir einnig upplýsingar um innkomnar og útleiðar beiðnir í hliðarvagni og passar við þær með því að auðga þær með nauðsynlegum útbeiðnahausum. Allt sem þú þarft að gera í þjónustunni er að senda aðeins einn haus X-Request-Id, sem hægt er að stilla með því að nota umhverfisbreytu NETRA_HTTP_REQUEST_ID_HEADER_NAME. Til að stjórna stærð samhengisins í Netramesh geturðu stillt eftirfarandi umhverfisbreytur: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (tíminn sem samhengið verður geymt fyrir) og NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (tíðni samhengishreinsunar).
Það er líka hægt að sameina margar slóðir á kerfinu þínu með því að merkja þær með sérstöku lotumerki. Netra gerir þér kleift að setja upp HTTP_HEADER_TAG_MAP til að breyta HTTP hausum í samsvarandi rekjasviðsmerki. Þetta getur verið sérstaklega gagnlegt til að prófa. Eftir að hafa staðist virkniprófið geturðu séð hvaða hluti kerfisins var fyrir áhrifum af síun eftir samsvarandi lotulykli.
Að ákvarða uppruna beiðninnar
Til að ákvarða hvaðan beiðnin kom geturðu notað þá virkni að bæta sjálfkrafa við haus með upprunanum. Notkun umhverfisbreytu NETRA_HTTP_X_SOURCE_HEADER_NAME Þú getur tilgreint hausheiti sem verður sjálfkrafa sett upp. Með því að nota NETRA_HTTP_X_SOURCE_VALUE þú getur stillt gildið sem X-Source hausinn verður stilltur á fyrir allar sendar beiðnir.
Þetta gerir kleift að dreifa dreifingu þessa gagnlega haus jafnt um netið. Síðan er hægt að nota það í þjónustu og bæta því við logs og mælikvarða.
Umferðarleiðsögn og Netramesh innri hluti
Netramesh samanstendur af tveimur meginþáttum. Sú fyrsta, netra-init, setur netreglur til að stöðva umferð. Hann notar að stöðva alla eða hluta umferðarinnar á hliðarvagni, sem er annar aðalþáttur Netramesh. Þú getur stillt hvaða höfn þarf að stöðva fyrir komandi og útleiðandi TCP lotur: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Tólið hefur einnig áhugaverðan eiginleika - líkindaleiðsögn. Ef þú notar Netramesh eingöngu til að safna rekjasviðum, þá geturðu í framleiðsluumhverfi sparað fjármagn og virkjað líkindaleið með því að nota breytur NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (frá 0 til 1). Sjálfgefið gildi er 1 (öll umferð er stöðvuð).
Eftir vel heppnaða hlerun samþykkir netra hliðarvagn nýju tenginguna og notar SO_ORIGINAL_DST falsvalkostur til að fá upprunalega áfangastaðinn. Netra opnar síðan nýja tengingu við upprunalegu IP töluna og kemur á tvíhliða TCP samskiptum milli aðila og hlustar á alla umferð sem fer í gegnum. Ef gáttin er skilgreind sem HTTP reynir Netra að flokka og rekja hana. Ef HTTP þáttun mistekst, fellur Netra aftur í TCP og umboðsbætin á gagnsæjan hátt.
Að búa til graf fyrir ósjálfstæði
Eftir að hafa fengið mikið magn af rakningarupplýsingum í Jaeger vil ég fá heilt graf yfir samskipti í kerfinu. En ef kerfið þitt er töluvert hlaðið og milljarðar rekjasviða safnast upp á dag, verður það ekki svo auðvelt verkefni að safna þeim saman. Það er til opinber leið til að gera þetta: . Hins vegar mun það taka klukkustundir að búa til heill línurit og mun neyða þig til að hlaða niður öllu gagnasafninu frá Jaeger síðasta sólarhringinn.
Ef þú ert að nota Elasticsearch til að geyma rekjasvið geturðu notað , sem mun byggja sama línuritið á nokkrum mínútum með því að nota eiginleika og getu Elasticsearch.
Hvernig á að nota Netramesh
Auðvelt er að bæta Netra við hvaða þjónustu sem er sem keyrir hvaða hljómsveitarstjóra sem er. Þú getur séð dæmi .
Eins og er hefur Netra ekki getu til að innleiða hliðarvagna sjálfkrafa í þjónustu en áætlanir eru uppi um innleiðingu.
Framtíð Netramesh
meginmarkmið er að ná lágmarks auðlindakostnaði og mikilli afköstum, sem veitir grunngetu til að fylgjast með og stjórna samskiptum milli þjónustuaðila.
Í framtíðinni mun Netramesh styðja aðrar samskiptareglur forritalags fyrir utan HTTP. L7 leið verður í boði á næstunni.
Notaðu Netramesh ef þú lendir í svipuðum vandamálum og skrifaðu okkur með spurningum og ábendingum.
Heimild: www.habr.com