Wrth inni symud o gymhwysiad monolithig i bensaernïaeth microwasanaethau, rydym yn wynebu heriau newydd.
Mewn cymhwysiad monolithig, fel arfer mae'n eithaf hawdd penderfynu ym mha ran o'r system y digwyddodd y gwall. Yn fwyaf tebygol, mae'r broblem yng nghod y monolith ei hun, neu yn y gronfa ddata. Ond pan fyddwn yn dechrau chwilio am broblem mewn pensaernïaeth microwasanaeth, nid yw popeth mor amlwg bellach. Mae angen inni ddod o hyd i'r llwybr cyfan a gymerodd y cais o'r dechrau i'r diwedd a'i ddewis o blith cannoedd o ficrowasanaethau. Ar ben hynny, mae gan lawer ohonynt eu cyfleusterau storio eu hunain hefyd, a all hefyd achosi gwallau rhesymegol, yn ogystal â phroblemau gyda pherfformiad a goddefgarwch bai.
Rwyf wedi bod yn chwilio ers amser maith am declyn a fyddai'n helpu i ymdopi â phroblemau o'r fath (ysgrifennais am hyn ar Habré: , ), ond yn y diwedd fe wnes i fy datrysiad ffynhonnell agored fy hun. Yn yr erthygl hon rwy'n siarad am fanteision y dull rhwyll gwasanaeth ac yn rhannu offeryn newydd ar gyfer ei weithredu.
Mae olrhain gwasgaredig yn ateb cyffredin i'r broblem o ddod o hyd i wallau mewn systemau gwasgaredig. Ond beth os nad yw'r dull hwn o gasglu gwybodaeth am ryngweithiadau rhwydwaith wedi'i weithredu yn y system eto, neu, yn waeth, mewn rhan o'r system mae eisoes yn gweithio'n iawn, ond yn rhannol nid yw'n gweithio'n iawn, gan nad yw wedi'i ychwanegu at hen wasanaethau ? Er mwyn pennu union achos y broblem, mae angen cael darlun cyflawn o'r hyn sy'n digwydd yn y system. Mae'n arbennig o bwysig deall pa ficrowasanaethau sy'n gysylltiedig â llwybrau allweddol sy'n hanfodol i fusnes.
Yma gall y dull rhwyll gwasanaeth ddod i'n cymorth, a fydd yn delio â'r holl beiriannau ar gyfer casglu gwybodaeth rhwydwaith ar lefel is na'r gwasanaethau eu hunain yn gweithredu. Mae'r dull hwn yn ein galluogi i atal yr holl draffig a'i ddadansoddi ar y hedfan. Ar ben hynny, nid oes rhaid i geisiadau hyd yn oed wybod dim amdano.
Dull rhwyll gwasanaeth
Prif syniad y dull rhwyll gwasanaeth yw ychwanegu haen seilwaith arall dros y rhwydwaith, a fydd yn caniatáu inni wneud unrhyw beth gyda rhyngweithio rhyng-wasanaeth. Mae'r rhan fwyaf o weithrediadau'n gweithio fel a ganlyn: mae cynhwysydd car ochr ychwanegol gyda dirprwy tryloyw yn cael ei ychwanegu at bob microwasanaeth, y mae holl draffig sy'n dod i mewn ac allan o'r gwasanaeth yn cael ei basio trwyddo. A dyma'r union le y gallwn wneud cydbwyso cleientiaid, cymhwyso polisïau diogelwch, gosod cyfyngiadau ar nifer y ceisiadau a chasglu gwybodaeth bwysig ar ryngweithio gwasanaethau wrth gynhyrchu.
Datrysiadau
Mae sawl gweithrediad o’r dull hwn eisoes: и . Maent yn darparu llawer o nodweddion allan o'r bocs. Ond ar yr un pryd, daw gorbenion mawr ar adnoddau. Ar ben hynny, po fwyaf yw'r clwstwr y mae system o'r fath yn gweithredu ynddo, y mwyaf o adnoddau fydd eu hangen i gynnal y seilwaith newydd. Yn Avito, rydym yn gweithredu clystyrau kubernetes sy'n cynnwys miloedd o achosion gwasanaeth (ac mae eu nifer yn parhau i dyfu'n gyflym). Yn ei weithrediad presennol, mae Istio yn defnyddio ~300Mb o RAM fesul achos gwasanaeth. Oherwydd y nifer fawr o bosibiliadau, mae cydbwyso tryloyw hefyd yn effeithio ar amser ymateb cyffredinol gwasanaethau (hyd at 10ms).
O ganlyniad, buom yn edrych ar ba alluoedd yn union yr oedd eu hangen arnom ar hyn o bryd, a phenderfynwyd mai'r prif reswm pam y gwnaethom ddechrau gweithredu atebion o'r fath oedd y gallu i gasglu gwybodaeth olrhain o'r system gyfan yn dryloyw. Roeddem hefyd am gael rheolaeth dros ryngweithiad gwasanaethau a gwneud amrywiol driniaethau â'r penawdau sy'n cael eu trosglwyddo rhwng gwasanaethau.
O ganlyniad, daethom i’n penderfyniad: .
Netramesh
yn ateb rhwyll gwasanaeth ysgafn gyda'r gallu i raddfa anfeidrol, waeth beth yw nifer y gwasanaethau yn y system.
Prif nodau'r datrysiad newydd oedd gorbenion adnoddau isel a pherfformiad uchel. O'r prif nodweddion, roeddem am allu anfon rhychwantau olrhain yn dryloyw i'n system Jaeger ar unwaith.
Heddiw, mae'r rhan fwyaf o atebion cwmwl yn cael eu gweithredu yn Golang. Ac, wrth gwrs, mae yna resymau am hyn. Mae ysgrifennu cymwysiadau rhwydwaith yn Golang sy'n gweithio'n anghydamserol ag I/O a graddio ar draws creiddiau yn ôl yr angen yn gyfleus ac yn eithaf syml. Ac, yr hyn sydd hefyd yn bwysig iawn, mae'r perfformiad yn ddigonol i ddatrys y broblem hon. Dyna pam y dewison ni Golang hefyd.
Cynhyrchiant
Rydym wedi canolbwyntio ein hymdrechion ar gyflawni cynhyrchiant mwyaf. Ar gyfer datrysiad sy'n cael ei ddefnyddio wrth ymyl pob achos o'r gwasanaeth, mae angen defnydd bach o amser RAM ac CPU. Ac, wrth gwrs, dylai'r oedi wrth ymateb fod yn fach hefyd.
Gawn ni weld pa ganlyniadau gawson ni.
RAM
Mae Netramesh yn defnyddio ~10Mb heb draffig ac uchafswm o 50Mb gyda llwyth o hyd at 10000 RPS fesul achos.
Mae dirprwy cennad Istio bob amser yn defnyddio ~300Mb yn ein clystyrau gyda miloedd o achosion. Nid yw hyn yn caniatáu iddo gael ei raddio i'r clwstwr cyfan.
Gyda Netramesh cawsom ostyngiad o ~10x yn y defnydd o gof.
CPU
Mae defnydd CPU yn gymharol gyfartal o dan lwyth. Mae'n dibynnu ar nifer y ceisiadau fesul uned o amser i'r car ochr. Gwerthoedd ar 3000 o geisiadau yr eiliad yn ystod oriau brig:
Mae un pwynt pwysicach: Netramesh - nid yw datrysiad heb awyren reoli a heb lwyth yn defnyddio amser CPU. Gydag Istio, mae sidecars bob amser yn diweddaru pwyntiau terfyn gwasanaeth. O ganlyniad, gallwn weld y llun hwn heb lwyth:
Rydym yn defnyddio HTTP/1 ar gyfer cyfathrebu rhwng gwasanaethau. Roedd y cynnydd yn yr amser ymateb i Istio wrth ddirprwyo trwy gennad hyd at 5-10ms, sy'n gryn dipyn ar gyfer gwasanaethau sy'n barod i ymateb mewn milieiliad. Gyda Netramesh mae'r amser hwn wedi gostwng i 0.5-2ms.
Scalability
Mae'r swm bach o adnoddau a ddefnyddir gan bob dirprwy yn ei gwneud hi'n bosibl ei osod wrth ymyl pob gwasanaeth. Crëwyd Netramesh yn fwriadol heb gydran awyren reoli i gadw pob car ochr yn ysgafn. Yn aml mewn datrysiadau rhwyll gwasanaeth, mae'r awyren reoli yn dosbarthu gwybodaeth darganfod gwasanaeth i bob car ochr. Ynghyd ag ef daw gwybodaeth am seibiannau a gosodiadau cydbwyso. Mae hyn i gyd yn caniatáu ichi wneud llawer o bethau defnyddiol, ond, yn anffodus, mae'n chwyddo maint y ceir ochr.
Darganfod gwasanaeth
Nid yw Netramesh yn ychwanegu unrhyw fecanweithiau ychwanegol ar gyfer darganfod gwasanaeth. Mae'r holl draffig yn cael ei brocsi'n dryloyw trwy netra sidecar.
Mae Netramesh yn cefnogi protocol cymhwysiad HTTP/1. Er mwyn ei ddiffinio, defnyddir rhestr ffurfweddadwy o borthladdoedd. Yn nodweddiadol, mae gan y system sawl porthladd lle mae cyfathrebu HTTP yn digwydd. Er enghraifft, rydym yn defnyddio 80, 8890, 8080 ar gyfer rhyngweithio rhwng gwasanaethau a cheisiadau allanol.Yn yr achos hwn, gellir eu gosod gan ddefnyddio newidyn amgylchedd NETRA_HTTP_PORTS.
Os ydych chi'n defnyddio Kubernetes fel cerddorfa a'i fecanwaith endid Gwasanaeth ar gyfer cyfathrebu o fewn clwstwr rhwng gwasanaethau, yna mae'r mecanwaith yn aros yn union yr un fath. Yn gyntaf, mae'r microwasanaeth yn cael cyfeiriad IP gwasanaeth gan ddefnyddio kube-dns ac yn agor cysylltiad newydd ag ef. Mae'r cysylltiad hwn yn cael ei sefydlu gyntaf gyda'r netra-sidecar lleol ac mae holl becynnau TCP yn cyrraedd netra i ddechrau. Nesaf, mae netra-sidecar yn sefydlu cysylltiad â'r gyrchfan wreiddiol. Mae NAT ar IP pod ar y nod yn aros yn union yr un fath â heb netra.
Olrhain wedi'i ddosbarthu a blaenyrru cyd-destun
Mae Netramesh yn darparu'r ymarferoldeb sydd ei angen i anfon rhychwantau olrhain am ryngweithiadau HTTP. Mae Netra-sidecar yn dosrannu'r protocol HTTP, yn mesur oedi o ran ceisiadau, ac yn tynnu'r wybodaeth angenrheidiol o benawdau HTTP. Yn y pen draw, rydyn ni'n cael yr holl olion mewn un system Jaeger. Ar gyfer cyfluniad manwl, gallwch hefyd ddefnyddio'r newidynnau amgylchedd a ddarperir gan y llyfrgell swyddogol .
Ond mae yna broblem. Hyd nes y bydd gwasanaethau'n cynhyrchu ac yn anfon pennawd uber arbennig, ni fyddwn yn gweld rhychwantau olrhain cysylltiedig yn y system. A dyma sydd ei angen arnom i ddod o hyd i achos problemau yn gyflym. Yma eto mae gan Netramesh ateb. Mae dirprwyon yn darllen penawdau HTTP ac, os nad ydynt yn cynnwys yr uber trace id, yn cynhyrchu un. Mae Netramesh hefyd yn storio gwybodaeth am geisiadau sy'n dod i mewn ac sy'n mynd allan mewn car ochr ac yn eu paru trwy eu cyfoethogi â'r penawdau ceisiadau allanol angenrheidiol. Y cyfan sydd angen i chi ei wneud yn y gwasanaethau yw anfon un pennawd yn unig X-Request-Id, y gellir ei ffurfweddu gan ddefnyddio newidyn amgylchedd NETRA_HTTP_REQUEST_ID_HEADER_NAME. I reoli maint y cyd-destun yn Netramesh, gallwch osod y newidynnau amgylchedd canlynol: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (yr amser y bydd y cyd-destun yn cael ei storio ar ei gyfer) a NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (amlder glanhau cyd-destun).
Mae hefyd yn bosibl cyfuno llwybrau lluosog ar eich system trwy eu marcio â thocyn sesiwn arbennig. Mae Netra yn caniatáu ichi osod HTTP_HEADER_TAG_MAP i droi penawdau HTTP yn dagiau rhychwant olrhain cyfatebol. Gall hyn fod yn arbennig o ddefnyddiol ar gyfer profi. Ar ôl pasio'r prawf swyddogaethol, gallwch weld pa ran o'r system yr effeithiwyd arni gan hidlo gan yr allwedd sesiwn gyfatebol.
Pennu Ffynhonnell y Cais
I benderfynu o ble y daeth y cais, gallwch ddefnyddio'r swyddogaeth o ychwanegu pennawd gyda'r ffynhonnell yn awtomatig. Defnyddio newidyn amgylchedd NETRA_HTTP_X_SOURCE_HEADER_NAME Gallwch chi nodi enw pennawd a fydd yn cael ei osod yn awtomatig. Trwy ddefnyddio NETRA_HTTP_X_SOURCE_VALUE gallwch osod y gwerth y bydd y pennawd X-Source yn cael ei osod iddo ar gyfer pob cais sy'n mynd allan.
Mae hyn yn caniatáu i ddosbarthiad y pennawd defnyddiol hwn gael ei ddosbarthu'n unffurf ledled y rhwydwaith. Yna gallwch ei ddefnyddio mewn gwasanaethau a'i ychwanegu at logiau a metrigau.
Llwybro traffig a systemau mewnol Netramesh
Mae Netramesh yn cynnwys dwy brif gydran. Mae'r cyntaf, netra-init, yn gosod rheolau rhwydwaith i atal traffig. Mae'n defnyddio i atal y cyfan neu ran o'r traffig ar y car ochr, sef ail brif elfen Netramesh. Gallwch chi ffurfweddu pa borthladdoedd sydd angen eu rhyng-gipio ar gyfer sesiynau TCP sy'n dod i mewn ac yn mynd allan: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Mae gan yr offeryn hefyd nodwedd ddiddorol - llwybro tebygol. Os ydych yn defnyddio Netramesh ar gyfer casglu rhychwantau olrhain yn unig, yna mewn amgylchedd cynhyrchu gallwch arbed adnoddau a galluogi llwybro tebygol gan ddefnyddio newidynnau NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (o 0 i 1). Y gwerth rhagosodedig yw 1 (mae'r holl draffig yn cael ei ryng-gipio).
Ar ôl rhyng-gipio llwyddiannus, mae netra sidecar yn derbyn y cysylltiad a'r defnydd newydd SO_ORIGINAL_DST opsiwn soced i gael y gyrchfan wreiddiol. Yna mae Netra yn agor cysylltiad newydd â'r cyfeiriad IP gwreiddiol ac yn sefydlu cyfathrebu TCP dwy ffordd rhwng y partïon, gan wrando ar yr holl draffig sy'n mynd drwodd. Os diffinnir y porthladd fel HTTP, mae Netra yn ceisio ei ddosrannu a'i olrhain. Os bydd dosrannu HTTP yn methu, mae Netra yn disgyn yn ôl i TCP ac yn dirprwyo'r bytes yn dryloyw.
Adeiladu graff dibyniaeth
Ar ôl derbyn llawer iawn o wybodaeth olrhain yn Jaeger, rwyf am gael graff cyflawn o ryngweithiadau yn y system. Ond os yw'ch system yn eithaf llwythog a bod biliynau o rychwantau olrhain yn cronni bob dydd, nid yw eu cydgrynhoi yn dasg mor hawdd. Mae yna ffordd swyddogol o wneud hyn: . Fodd bynnag, bydd yn cymryd oriau i adeiladu graff cyflawn a bydd yn eich gorfodi i lawrlwytho'r set ddata gyfan o Jaeger am y 24 awr ddiwethaf.
Os ydych chi'n defnyddio Elasticsearch i storio rhychwantau olrhain, gallwch chi ei ddefnyddio , a fydd yn adeiladu'r un graff mewn munudau gan ddefnyddio nodweddion a galluoedd Elasticsearch.
Sut i ddefnyddio Netramesh
Gellir ychwanegu Netra yn hawdd at unrhyw wasanaeth sy'n rhedeg unrhyw gerddorfawr. Gallwch weld enghraifft .
Ar hyn o bryd, nid oes gan Netra'r gallu i weithredu ceir ochr i wasanaethau yn awtomatig, ond mae cynlluniau i'w rhoi ar waith.
Dyfodol Netramesh
Y prif nod yw cyflawni costau adnoddau isel a pherfformiad uchel, gan ddarparu galluoedd sylfaenol ar gyfer arsylwi a rheoli cyfathrebu rhwng gwasanaethau.
Yn y dyfodol, bydd Netramesh yn cefnogi protocolau haen cais eraill ar wahân i HTTP. Bydd llwybro L7 ar gael yn y dyfodol agos.
Defnyddiwch Netramesh os byddwch yn dod ar draws problemau tebyg ac ysgrifennwch atom gyda chwestiynau ac awgrymiadau.
Ffynhonnell: hab.com