Tunapohama kutoka kwa programu ya monolithic kwenda kwa usanifu wa huduma ndogo, tunakabiliwa na changamoto mpya.
Katika programu ya monolithic, kawaida ni rahisi kuamua ni sehemu gani ya mfumo ambayo hitilafu ilitokea. Uwezekano mkubwa zaidi, shida iko katika msimbo wa monolith yenyewe, au kwenye hifadhidata. Lakini tunapoanza kutafuta tatizo katika usanifu wa microservice, kila kitu sio wazi tena. Tunahitaji kutafuta njia nzima ambayo ombi lilichukua kutoka mwanzo hadi mwisho na kuichagua kutoka kwa mamia ya huduma ndogo. Aidha, wengi wao pia wana vifaa vyao vya kuhifadhi, ambavyo vinaweza pia kusababisha makosa ya kimantiki, pamoja na matatizo ya utendaji na uvumilivu wa makosa.
Nimekuwa nikitafuta zana ambayo inaweza kusaidia kukabiliana na shida kama hizi kwa muda mrefu (niliandika juu ya hii kwenye HabrΓ©: , ), lakini mwishowe nilifanya suluhisho langu la chanzo wazi. Katika makala hii ninazungumza juu ya faida za mbinu ya mesh ya huduma na kushiriki chombo kipya cha utekelezaji wake.
Ufuatiliaji uliosambazwa ni suluhisho la kawaida kwa shida ya kupata makosa katika mifumo iliyosambazwa. Lakini vipi ikiwa mbinu hii ya kukusanya habari kuhusu mwingiliano wa mtandao bado haijatekelezwa katika mfumo, au, mbaya zaidi, katika sehemu ya mfumo tayari inafanya kazi vizuri, lakini kwa sehemu haifanyi, kwani haijaongezwa kwa huduma za zamani. ? Kuamua sababu halisi ya tatizo, ni muhimu kuwa na picha kamili ya kile kinachotokea katika mfumo. Ni muhimu sana kuelewa ni huduma gani ndogo zinazohusika katika njia muhimu za biashara.
Hapa mbinu ya mesh ya huduma inaweza kuja kwa msaada wetu, ambayo itashughulika na mashine zote za kukusanya taarifa za mtandao kwa kiwango cha chini kuliko huduma zenyewe. Mbinu hii huturuhusu kuzuia trafiki yote na kuichanganua kwa kuruka. Kwa kuongezea, programu sio lazima hata kujua chochote kuihusu.
Mbinu ya matundu ya huduma
Wazo kuu la mbinu ya matundu ya huduma ni kuongeza safu nyingine ya miundombinu kwenye mtandao, ambayo itaturuhusu kufanya jambo lolote na mwingiliano wa huduma. Utekelezaji mwingi hufanya kazi kama ifuatavyo: kontena ya ziada ya kando iliyo na proksi ya uwazi huongezwa kwa kila huduma ndogo, ambayo trafiki yote inayoingia na inayotoka ya huduma hupitishwa. Na hapa ndipo mahali ambapo tunaweza kufanya kusawazisha mteja, kutumia sera za usalama, kuweka vikwazo kwa idadi ya maombi na kukusanya taarifa muhimu juu ya mwingiliano wa huduma katika uzalishaji.
Suluhisho
Tayari kuna utekelezaji kadhaa wa mbinu hii: ΠΈ . Wanatoa vipengele vingi nje ya boksi. Lakini wakati huo huo, kuna uboreshaji mkubwa wa rasilimali. Zaidi ya hayo, kadiri kundi ambalo mfumo kama huo unavyofanya kazi, ndivyo rasilimali nyingi zaidi zitahitajika ili kudumisha miundombinu mpya. Katika Avito, tunaendesha makundi ya kubernetes ambayo yana maelfu ya matukio ya huduma (na idadi yao inaendelea kukua kwa kasi). Katika utekelezaji wake wa sasa, Istio hutumia ~ 300Mb ya RAM kwa kila mfano wa huduma. Kutokana na idadi kubwa ya uwezekano, kusawazisha kwa uwazi pia huathiri muda wa jumla wa majibu ya huduma (hadi 10ms).
Matokeo yake, tuliangalia ni uwezo gani hasa tuliohitaji hivi sasa, na tukaamua kuwa sababu kuu iliyotufanya tuanze kutekeleza masuluhisho hayo ilikuwa ni uwezo wa kukusanya taarifa za ufuatiliaji kutoka kwa mfumo mzima kwa uwazi. Pia tulitaka kuwa na udhibiti wa mwingiliano wa huduma na kufanya hila mbalimbali na vichwa vinavyohamishwa kati ya huduma.
Kama matokeo, tulifikia uamuzi wetu:β .
Netramesh
ni suluhisho la mesh ya huduma nyepesi na uwezo wa kuongeza ukubwa, bila kujali idadi ya huduma katika mfumo.
Malengo makuu ya suluhisho jipya yalikuwa juu ya rasilimali ya chini na utendaji wa juu. Kati ya vipengele vikuu, mara moja tulitaka kuweza kutuma kwa uwazi nafasi za ufuatiliaji kwenye mfumo wetu wa Jaeger.
Leo, suluhisho nyingi za wingu zinatekelezwa huko Golang. Na, bila shaka, kuna sababu za hili. Kuandika programu za mtandao katika Golang ambazo hufanya kazi kwa usawa na I/O na kuongeza alama kama inavyohitajika ni rahisi na rahisi sana. Na, nini pia ni muhimu sana, utendaji ni wa kutosha kutatua tatizo hili. Ndio maana pia tulichagua Golang.
Uzalishaji
Tumeelekeza juhudi zetu katika kufikia tija ya juu zaidi. Kwa suluhisho ambalo linatumika karibu na kila tukio la huduma, matumizi kidogo ya RAM na wakati wa CPU inahitajika. Na, bila shaka, kuchelewa kwa majibu lazima pia kuwa ndogo.
Wacha tuone ni matokeo gani tuliyopata.
RAM
Netramesh hutumia ~ 10Mb bila trafiki na kiwango cha juu cha 50Mb na mzigo wa hadi RPS 10000 kwa kila tukio.
Wakala wa mjumbe wa Istio kila mara hutumia ~300Mb katika makundi yetu na maelfu ya matukio. Hii hairuhusu kuongezwa kwa nguzo nzima.
Na Netramesh tulipata ~ 10x kupunguza matumizi ya kumbukumbu.
CPU
Matumizi ya CPU ni sawa chini ya mzigo. Inategemea idadi ya maombi kwa kila kitengo cha muda kwa sidecar. Thamani katika maombi 3000 kwa sekunde kwa kilele:
Kuna jambo moja muhimu zaidi: Netramesh - suluhisho bila ndege ya kudhibiti na bila mzigo haitumii muda wa CPU. Ukiwa na Istio, gari za pembeni husasisha miisho ya huduma kila wakati. Kama matokeo, tunaweza kuona picha hii bila mzigo:
Tunatumia HTTP/1 kwa mawasiliano kati ya huduma. Ongezeko la muda wa kujibu kwa Istio wakati wa kutoa uwakilishi kupitia mjumbe lilikuwa hadi milisekunde 5-10, ambayo ni nyingi sana kwa huduma ambazo ziko tayari kujibu kwa milisekunde. Kwa Netramesh wakati huu umepungua hadi 0.5-2ms.
Scalability
Kiasi kidogo cha rasilimali zinazotumiwa na kila wakala hufanya iwezekane kuiweka karibu na kila huduma. Netramesh iliundwa kimakusudi bila kijenzi cha ndege ya kudhibiti ili kuweka kila gari la pembeni kuwa nyepesi. Mara nyingi katika ufumbuzi wa matundu ya huduma, ndege ya udhibiti inasambaza taarifa za ugunduzi wa huduma kwa kila kando. Pamoja nayo huja habari kuhusu kuisha kwa muda na mipangilio ya kusawazisha. Yote hii inakuwezesha kufanya mambo mengi muhimu, lakini, kwa bahati mbaya, inapunguza ukubwa wa sidecars.
Ugunduzi wa huduma
Netramesh haiongezi mbinu zozote za ziada za ugunduzi wa huduma. Trafiki yote imewekwa kwa uwazi kupitia netra sidecar.
Netramesh inasaidia itifaki ya programu ya HTTP/1. Ili kuifafanua, orodha inayoweza kusanidiwa ya bandari hutumiwa. Kwa kawaida, mfumo una bandari kadhaa ambazo mawasiliano ya HTTP hutokea. Kwa mfano, tunatumia 80, 8890, 8080 kwa mwingiliano kati ya huduma na maombi ya nje. Katika hali hii, zinaweza kuwekwa kwa kutumia mabadiliko ya mazingira. NETRA_HTTP_PORTS.
Ikiwa unatumia Kubernetes kama orchestrator na utaratibu wake wa huluki ya Huduma kwa mawasiliano ya ndani ya nguzo kati ya huduma, basi utaratibu unasalia kuwa sawa kabisa. Kwanza, huduma ndogo hupata anwani ya IP ya huduma kwa kutumia kube-dns na kufungua muunganisho mpya kwake. Muunganisho huu huanzishwa kwa mara ya kwanza na netra-sidecar ya ndani na pakiti zote za TCP hufika kwenye netra. Kisha, netra-sidecar huanzisha muunganisho na lengwa la asili. NAT kwenye ganda IP kwenye nodi inabakia sawa kabisa na bila netra.
Ufuatiliaji uliosambazwa na usambazaji wa muktadha
Netramesh hutoa utendakazi unaohitajika kutuma muda wa kufuatilia kuhusu mwingiliano wa HTTP. Netra-sidecar huchanganua itifaki ya HTTP, hupima ucheleweshaji wa ombi, na kutoa maelezo muhimu kutoka kwa vichwa vya HTTP. Hatimaye, tunapata athari zote katika mfumo mmoja wa Jaeger. Kwa usanidi mzuri, unaweza pia kutumia anuwai za mazingira zinazotolewa na maktaba rasmi .
Lakini kuna tatizo. Hadi huduma zitengeneze na kutuma kichwa maalum cha uber, hatutaona vipindi vilivyounganishwa vya ufuatiliaji katika mfumo. Na hii ndio tunahitaji kupata haraka sababu ya shida. Hapa tena Netramesh ina suluhisho. Wakala husoma vichwa vya HTTP na, ikiwa havina kitambulisho cha uber, toa kimoja. Netramesh pia huhifadhi taarifa kuhusu maombi yanayoingia na kutoka kwenye gari la kando na kuyalinganisha kwa kuyaboresha kwa vichwa vya ombi vinavyohitajika kutoka. Unachohitaji kufanya katika huduma ni kutuma kichwa kimoja tu X-Request-Id, ambayo inaweza kusanidiwa kwa kutumia mabadiliko ya mazingira NETRA_HTTP_REQUEST_ID_HEADER_NAME. Ili kudhibiti saizi ya muktadha katika Netramesh, unaweza kuweka anuwai za mazingira zifuatazo: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (wakati ambao muktadha utahifadhiwa) na NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (marudio ya usafishaji wa muktadha).
Pia inawezekana kuchanganya njia nyingi kwenye mfumo wako kwa kuzitia alama na ishara maalum ya kikao. Netra hukuruhusu kusakinisha HTTP_HEADER_TAG_MAP kugeuza vichwa vya HTTP kuwa tagi za muda za ufuatiliaji zinazolingana. Hii inaweza kuwa muhimu hasa kwa majaribio. Baada ya kupita mtihani wa kazi, unaweza kuona ni sehemu gani ya mfumo iliyoathiriwa na kuchuja kwa ufunguo wa kikao unaofanana.
Kuamua Chanzo cha Ombi
Kuamua ambapo ombi lilitoka, unaweza kutumia utendakazi wa kuongeza kichwa kiotomatiki na chanzo. Kwa kutumia mabadiliko ya mazingira NETRA_HTTP_X_SOURCE_HEADER_NAME Unaweza kubainisha jina la kichwa ambalo litasakinishwa kiotomatiki. Kwa kutumia NETRA_HTTP_X_SOURCE_VALUE unaweza kuweka thamani ambayo kichwa cha X-Chanzo kitawekwa kwa maombi yote yanayotoka.
Hii inaruhusu usambazaji wa kichwa hiki muhimu kusambazwa kwa usawa katika mtandao. Kisha unaweza kuitumia katika huduma na kuiongeza kwenye kumbukumbu na vipimo.
Uelekezaji wa trafiki na wa ndani wa Netramesh
Netramesh ina sehemu kuu mbili. Ya kwanza, netra-init, huweka sheria za mtandao ili kuzuia trafiki. Anatumia kukatiza trafiki yote au sehemu kwenye sidecar, ambayo ni sehemu kuu ya pili ya Netramesh. Unaweza kusanidi ni milango ipi inayohitaji kuingiliwa kwa vipindi vya TCP vinavyoingia na kutoka: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Chombo pia kina kipengele cha kuvutia - uelekezaji wa uwezekano. Ikiwa unatumia Netramesh pekee kwa ajili ya kukusanya nafasi za kufuatilia, basi katika mazingira ya uzalishaji unaweza kuhifadhi rasilimali na kuwezesha uelekezaji unaowezekana kwa kutumia vigeu. NETRA_INBOUND_PROBABILITY ΠΈ NETRA_OUTBOUND_PROBABILITY (kutoka 0 hadi 1). Thamani chaguo-msingi ni 1 (trafiki yote imezuiwa).
Baada ya kukatiza kwa mafanikio, netra sidecar inakubali muunganisho na matumizi mapya SO_ORIGINAL_DST chaguo la soketi kupata marudio asili. Netra kisha hufungua muunganisho mpya kwa anwani ya IP ya asili na kuanzisha mawasiliano ya njia mbili ya TCP kati ya wahusika, kusikiliza trafiki yote inayopita. Ikiwa lango limefafanuliwa kama HTTP, Netra hujaribu kuichanganua na kuifuatilia. Uchanganuzi wa HTTP usipofaulu, Netra itarudi kwa TCP na kwa uwazi kutoa seva mbadala za baiti.
Kuunda grafu ya utegemezi
Baada ya kupokea kiasi kikubwa cha taarifa za ufuatiliaji katika Jaeger, nataka kupata grafu kamili ya mwingiliano katika mfumo. Lakini ikiwa mfumo wako umejaa kabisa na mabilioni ya nafasi za ufuatiliaji hujilimbikiza kwa siku, kuzijumlisha inakuwa si kazi rahisi. Kuna njia rasmi ya kufanya hivi: . Hata hivyo, itachukua saa nyingi kuunda grafu kamili na itakulazimisha kupakua mkusanyiko mzima wa data kutoka kwa Jaeger kwa saa 24 zilizopita.
Ikiwa unatumia Elasticsearch kuhifadhi nafasi za ufuatiliaji, unaweza kutumia , ambayo itaunda grafu sawa kwa dakika kwa kutumia vipengele na uwezo wa Elasticsearch.
Jinsi ya kutumia Netramesh
Netra inaweza kuongezwa kwa urahisi kwa huduma yoyote inayoendesha orchestrator yoyote. Unaweza kuona mfano .
Kwa sasa, Netra haina uwezo wa kutekeleza moja kwa moja sidecars kwa huduma, lakini kuna mipango ya utekelezaji.
Wakati ujao wa Netramesh
Lengo kuu ni kufikia gharama ndogo za rasilimali na utendaji wa juu, kutoa uwezo wa kimsingi wa uangalizi na udhibiti wa mawasiliano kati ya huduma.
Katika siku zijazo, Netramesh itatumia itifaki zingine za safu ya programu kando na HTTP. Uelekezaji wa L7 utapatikana katika siku za usoni.
Tumia Netramesh ikiwa utapata matatizo sawa na utuandikie kwa maswali na mapendekezo.
Chanzo: mapenzi.com