Երբ մենք միաձույլ հավելվածից անցնում ենք միկրոծառայությունների ճարտարապետության, մենք բախվում ենք նոր մարտահրավերների:

Մոնոլիտ հավելվածում սովորաբար բավականին հեշտ է որոշել, թե համակարգի որ մասում է տեղի ունեցել սխալը: Ամենայն հավանականությամբ, խնդիրը հենց մոնոլիտի կոդի մեջ է, կամ տվյալների բազայում։ Բայց երբ մենք սկսում ենք խնդիր փնտրել միկրոսերվիսային ճարտարապետության մեջ, ամեն ինչ այլևս այնքան էլ ակնհայտ չէ: Մենք պետք է գտնենք այն ամբողջ ճանապարհը, որն անցել է հարցումը սկզբից մինչև վերջ և ընտրենք այն հարյուրավոր միկրոսերվիսներից: Ավելին, նրանցից շատերն ունեն նաև իրենց պահեստային հնարավորությունները, որոնք կարող են նաև առաջացնել տրամաբանական սխալներ, ինչպես նաև խնդիրներ կատարման և սխալների հանդուրժողականության հետ:

Ես երկար ժամանակ փնտրում էի գործիք, որը կօգնի հաղթահարել նման խնդիրները (այս մասին գրել եմ Habré-ում. 1, 2), բայց ի վերջո ես պատրաստեցի իմ սեփական բաց կոդով լուծումը։ Այս հոդվածում ես խոսում եմ ծառայության ցանցի մոտեցման առավելությունների մասին և կիսում եմ դրա իրականացման նոր գործիքը:

Բաշխված հետագծումը բաշխված համակարգերում սխալներ գտնելու խնդրի ընդհանուր լուծումն է: Բայց ինչ անել, եթե ցանցային փոխազդեցությունների մասին տեղեկություններ հավաքելու այս մոտեցումը դեռ չի ներդրվել համակարգում, կամ, ավելի վատ, համակարգի մի մասում այն ​​արդեն ճիշտ է աշխատում, բայց մասամբ՝ ոչ, քանի որ այն չի ավելացվել հին ծառայություններին։ ? Խնդրի ստույգ բուն պատճառը որոշելու համար անհրաժեշտ է համակարգում կատարվողի ամբողջական պատկերացում ունենալ: Հատկապես կարևոր է հասկանալ, թե որ միկրոծառայություններն են ներգրավված բիզնեսի համար կարևորագույն ուղիներում:

Այստեղ մեզ կարող է օգնել սպասարկման ցանցի մոտեցումը, որը կզբաղվի ցանցի տեղեկատվության հավաքագրման բոլոր մեխանիզմներով ավելի ցածր մակարդակով, քան իրենք գործում են ծառայությունները: Այս մոտեցումը մեզ թույլ է տալիս ընդհատել ողջ երթևեկությունը և վերլուծել այն անմիջապես: Ավելին, հավելվածները նույնիսկ պարտավոր չեն դրա մասին որևէ բան իմանալ։

Սպասարկման ցանցի մոտեցում

Ծառայությունների ցանցի մոտեցման հիմնական գաղափարը ցանցի վրա ենթակառուցվածքի ևս մեկ շերտ ավելացնելն է, որը թույլ կտա մեզ ցանկացած բան անել միջսպասարկման փոխազդեցությամբ: Իրականացումների մեծ մասն աշխատում է հետևյալ կերպ. յուրաքանչյուր միկրոսերվիսում ավելացվում է լրացուցիչ կողային կոնտեյներ՝ թափանցիկ պրոքսիով, որի միջոցով փոխանցվում է ծառայության ողջ մուտքային և ելքային տրաֆիկը: Եվ սա հենց այն վայրն է, որտեղ մենք կարող ենք կատարել հաճախորդների հավասարակշռում, կիրառել անվտանգության քաղաքականություն, սահմանափակումներ դնել հարցումների քանակի վրա և հավաքել կարևոր տեղեկատվություն արտադրության մեջ ծառայությունների փոխազդեցության վերաբերյալ:

Решения

Այս մոտեցման մի քանի իրականացում արդեն կա. Իստիո и կապող2. Նրանք ապահովում են բազմաթիվ առանձնահատկություններ առանց տուփի: Բայց միևնույն ժամանակ ռեսուրսների վրա մեծ գերբեռնվածություն կա: Ավելին, որքան մեծ լինի կլաստերը, որում գործում է նման համակարգը, այնքան ավելի շատ ռեսուրսներ կպահանջվեն նոր ենթակառուցվածքը պահպանելու համար: Avito-ում մենք աշխատում ենք kubernetes կլաստերներ, որոնք պարունակում են հազարավոր սպասարկման օրինակներ (և դրանց թիվը շարունակում է արագ աճել): Իր ընթացիկ իրականացման ընթացքում Istio-ն սպառում է ~ 300 Մբ օպերատիվ հիշողություն մեկ ծառայության օրինակի համար: Հնարավորությունների մեծ քանակի պատճառով թափանցիկ հավասարակշռումն ազդում է նաև ծառայությունների ընդհանուր արձագանքման ժամանակի վրա (մինչև 10 մս):

Արդյունքում, մենք հենց հիմա նայեցինք, թե ինչ հնարավորություններ են մեզ անհրաժեշտ և որոշեցինք, որ հիմնական պատճառը, թե ինչու ենք սկսել նման լուծումներ իրականացնել, ամբողջ համակարգից թափանցիկ կերպով հետագծող տեղեկատվություն հավաքելու հնարավորությունն է: Մենք նաև ցանկանում էինք վերահսկել ծառայությունների փոխազդեցությունը և տարբեր մանիպուլյացիաներ անել վերնագրերի հետ, որոնք փոխանցվում են ծառայությունների միջև:

Արդյունքում մենք եկանք մեր որոշմանը.  Նետրամեշ.

Նետրամեշ

Նետրամեշ թեթև սպասարկման ցանցային լուծում է՝ անվերջ մասշտաբավորելու ունակությամբ՝ անկախ համակարգում ծառայությունների քանակից:

Նոր լուծման հիմնական նպատակներն էին ռեսուրսների ցածր ծախսերը և բարձր արդյունավետությունը: Հիմնական հատկանիշների թվում մենք անմիջապես ցանկացանք, որ կարողանանք թափանցիկ կերպով ուղարկել հետագծման տարածություններ մեր Jaeger համակարգին:

Այսօր ամպային լուծումների մեծ մասն իրականացվում է Գոլանգում: Եվ, իհարկե, դրա համար կան պատճառներ։ Գոլանգում ցանցային հավելվածներ գրելը, որոնք ասինխրոն աշխատում են I/O-ի հետ և անհրաժեշտության դեպքում չափում են միջուկները, հարմար է և բավականին պարզ: Եվ, ինչը նույնպես շատ կարևոր է, կատարումը բավարար է այս խնդիրը լուծելու համար։ Դրա համար մենք նույնպես ընտրեցինք Գոլանգը։

Արտադրողականություն

Մենք մեր ջանքերը կենտրոնացրել ենք առավելագույն արտադրողականության հասնելու վրա։ Ծառայության յուրաքանչյուր օրինակի կողքին տեղադրված լուծման համար պահանջվում է RAM-ի և պրոցեսորի ժամանակի փոքր սպառում: Եվ, իհարկե, արձագանքման ուշացումը նույնպես պետք է փոքր լինի։

Տեսնենք, թե ինչ արդյունքներ ենք ստացել։

RAM

Netramesh-ը սպառում է ~ 10 Մբ առանց երթևեկության և 50 Մբ առավելագույնը՝ մինչև 10000 RPS բեռի դեպքում:

Istio envoy proxy-ը միշտ սպառում է ~300 Մբ մեր կլաստերներում՝ հազարավոր օրինակներով: Սա թույլ չի տալիս այն մասշտաբավորել ամբողջ կլաստերին:

Netramesh-ի հետ մենք ստացել ենք հիշողության սպառման ~ 10 անգամ կրճատում:

CPU

CPU-ի օգտագործումը համեմատաբար հավասար է ծանրաբեռնվածության դեպքում: Դա կախված է կողային սայլին ուղղված ժամանակի մեկ միավորի հարցումների քանակից: Արժեքները 3000 հարցում/վայրկյանում առավելագույն պահին.

Կա ևս մեկ կարևոր կետ. Netramesh - լուծումը առանց կառավարման հարթության և առանց բեռի չի սպառում պրոցեսորի ժամանակը: Istio-ի հետ կողային մեքենաները միշտ թարմացնում են ծառայության վերջնակետերը: Արդյունքում մենք կարող ենք տեսնել այս նկարը առանց բեռի.

Մենք օգտագործում ենք HTTP/1 ծառայությունների միջև հաղորդակցության համար: Istio-ի համար արձագանքման ժամանակի աճը, երբ միջնորդի միջոցով փոխանցվում էր միջնորդի, կազմում էր մինչև 5-10 մվ, ինչը բավականին մեծ է ծառայությունների համար, որոնք պատրաստ են արձագանքել մեկ միլիվայրկյանում: Netramesh-ի հետ այս ժամանակը նվազել է մինչև 0.5-2ms:

Մասշտաբայնություն

Յուրաքանչյուր վստահված անձի կողմից սպառվող ռեսուրսների փոքր քանակությունը հնարավորություն է տալիս այն տեղադրել յուրաքանչյուր ծառայության կողքին: Netramesh-ը միտումնավոր ստեղծվել է առանց կառավարող ինքնաթիռի բաղադրիչի՝ յուրաքանչյուր կողային սայլը պարզապես թեթև պահելու համար: Հաճախ սպասարկման ցանցային լուծումներում կառավարման հարթությունը բաժանում է ծառայության հայտնաբերման տեղեկատվությունը յուրաքանչյուր կողային սայլին: Դրա հետ մեկտեղ գալիս են տեղեկություններ դադարների և հավասարակշռման կարգավորումների մասին: Այս ամենը թույլ է տալիս շատ օգտակար բաներ անել, բայց, ցավոք, փչում է կողային սայլերը չափերով։

Ծառայության բացահայտում

Netramesh-ը որևէ լրացուցիչ մեխանիզմ չի ավելացնում ծառայության հայտնաբերման համար: Ամբողջ երթևեկությունը թափանցիկ կերպով իրականացվում է netra sidecar-ի միջոցով:

Netramesh-ն աջակցում է HTTP/1 հավելվածի արձանագրությանը: Այն սահմանելու համար օգտագործվում է նավահանգիստների կարգավորելի ցուցակ: Սովորաբար, համակարգն ունի մի քանի նավահանգիստներ, որոնց միջոցով տեղի է ունենում HTTP հաղորդակցություն: Օրինակ՝ մենք օգտագործում ենք 80, 8890, 8080 ծառայությունների և արտաքին հարցումների միջև փոխազդեցության համար: Այս դեպքում դրանք կարող են սահմանվել՝ օգտագործելով շրջակա միջավայրի փոփոխական: NETRA_HTTP_PORTS.

Եթե ​​դուք օգտագործում եք Kubernetes-ը որպես նվագախմբի և նրա ծառայության միավորի մեխանիզմը ծառայությունների միջև ներկլաստերային հաղորդակցության համար, ապա մեխանիզմը մնում է նույնը: Նախ, միկրոսերվիսը ստանում է ծառայության IP հասցե՝ օգտագործելով kube-dns և բացում նոր կապ դրա հետ։ Այս կապը սկզբում հաստատվում է տեղական netra-sidecar-ի հետ և բոլոր TCP փաթեթները սկզբում հասնում են netra-ին: Հաջորդը, netra-sidecar-ը կապ է հաստատում սկզբնական նպատակակետի հետ: NAT-ը հանգույցի վրա pod IP-ի վրա մնում է նույնը, ինչ առանց նետրա:

Բաշխված հետագծում և համատեքստի վերահասցեավորում

Netramesh-ն ապահովում է HTTP փոխազդեցությունների վերաբերյալ հետագծման տարածություններ ուղարկելու համար անհրաժեշտ ֆունկցիոնալությունը: Netra-sidecar-ը վերլուծում է HTTP արձանագրությունը, չափում է հարցումների հետաձգումները և անհրաժեշտ տեղեկատվությունը քաղում HTTP վերնագրերից: Ի վերջո, մենք ստանում ենք բոլոր հետքերը մեկ Jaeger համակարգում: Հստակ կազմաձևման համար կարող եք նաև օգտագործել պաշտոնական գրադարանի կողմից տրամադրված միջավայրի փոփոխականները jaeger go գրադարան.

Բայց կա մի խնդիր. Մինչև ծառայությունները չստեղծեն և չուղարկեն հատուկ uber վերնագիր, մենք համակարգում չենք տեսնի միացված հետագծման միջակայքերը: Եվ սա այն է, ինչ մեզ անհրաժեշտ է արագ գտնելու խնդիրների պատճառը։ Այստեղ կրկին Նեթրամեշը լուծում ունի. Վստահված սերվերները կարդում են HTTP վերնագրերը և, եթե դրանք չեն պարունակում uber հետքի id, ստեղծում են մեկը: Netramesh-ը նաև պահում է մուտքային և ելքային հարցումների մասին տեղեկատվությունը կողային սայլում և համապատասխանեցնում է դրանք՝ հարստացնելով դրանք անհրաժեշտ ելքային հարցումների վերնագրերով: Ծառայություններում ձեզ անհրաժեշտ է ընդամենը մեկ վերնագիր ուղարկել X-Request-Id, որը կարող է կազմաձևվել՝ օգտագործելով շրջակա միջավայրի փոփոխական NETRA_HTTP_REQUEST_ID_HEADER_NAME. Netramesh-ում համատեքստի չափը վերահսկելու համար կարող եք սահմանել հետևյալ միջավայրի փոփոխականները. NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (ժամանակը, որի համար կպահվի համատեքստը) և NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (համատեքստի մաքրման հաճախականությունը):

Հնարավոր է նաև միավորել բազմաթիվ ուղիներ ձեր համակարգում՝ նշելով դրանք հատուկ նստաշրջանի նշանով: Netra-ն թույլ է տալիս տեղադրել HTTP_HEADER_TAG_MAP HTTP վերնագրերը վերածելու համապատասխան հետագծման միջակայքի պիտակների: Սա կարող է հատկապես օգտակար լինել թեստավորման համար: Ֆունկցիոնալ թեստն անցնելուց հետո կարող եք տեսնել, թե համակարգի որ մասի վրա է ազդել համապատասխան նստաշրջանի ստեղնով զտումը:

Հարցման աղբյուրի որոշում

Որոշելու համար, թե որտեղից է եկել հարցումը, կարող եք օգտագործել աղբյուրի հետ վերնագիր ավտոմատ ավելացնելու գործառույթը: Օգտագործելով շրջակա միջավայրի փոփոխական NETRA_HTTP_X_SOURCE_HEADER_NAME Դուք կարող եք նշել վերնագրի անունը, որը ավտոմատ կերպով կտեղադրվի: Օգտագործելով NETRA_HTTP_X_SOURCE_VALUE Դուք կարող եք սահմանել այն արժեքը, որով կսահմանվի X-Source վերնագիրը բոլոր ելքային հարցումների համար:

Սա թույլ է տալիս այս օգտակար վերնագրի բաշխումը միատեսակ բաշխել ցանցում: Այնուհետև կարող եք օգտագործել այն ծառայություններում և ավելացնել տեղեկամատյաններում և չափումներում:

Երթևեկության երթուղի և Netramesh ներքին սարքեր

Netramesh-ը բաղկացած է երկու հիմնական բաղադրիչներից. Առաջինը՝ netra-init-ը, սահմանում է ցանցի կանոններ՝ երթևեկությունը կասեցնելու համար: Նա օգտագործում է iptables վերահղման կանոնները ընդհատել երթևեկության ամբողջ կամ մի մասը կողային սայլով, որը Netramesh-ի երկրորդ հիմնական բաղադրիչն է: Դուք կարող եք կարգավորել, թե որ նավահանգիստները պետք է ընդհատվեն մուտքային և ելքային TCP նիստերի համար. INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

Գործիքը ունի նաև հետաքրքիր առանձնահատկություն՝ հավանականական երթուղիավորում: Եթե ​​դուք օգտագործում եք Netramesh-ը բացառապես հետագծման միջակայքերը հավաքելու համար, ապա արտադրական միջավայրում կարող եք խնայել ռեսուրսները և միացնել հավանական երթուղին՝ օգտագործելով փոփոխականներ։ NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (0-ից 1): Լռելյայն արժեքը 1 է (ամբողջ երթևեկությունը խափանում է):

Հաջող արգելափակումից հետո netra sidecar-ն ընդունում է նոր կապը և օգտագործում SO_ORIGINAL_DST վարդակից տարբերակ՝ սկզբնական նպատակակետը ստանալու համար: Այնուհետև Netra-ն նոր կապ է բացում սկզբնական IP հասցեի հետ և հաստատում է երկկողմանի TCP հաղորդակցություն կողմերի միջև՝ լսելով անցնող ողջ տրաֆիկը: Եթե ​​նավահանգիստը սահմանված է որպես HTTP, Netra-ն փորձում է վերլուծել և հետագծել այն: Եթե ​​HTTP վերլուծությունը ձախողվի, Netra-ն հետ է ընկնում TCP-ին և թափանցիկորեն փոխանցում է բայթերը:

Կախվածության գրաֆիկի կառուցում

Jaeger-ում մեծ քանակությամբ հետագծման տեղեկատվություն ստանալուց հետո ես ցանկանում եմ ստանալ համակարգում փոխազդեցությունների ամբողջական գրաֆիկ: Բայց եթե ձեր համակարգը բավականին ծանրաբեռնված է, և օրական միլիարդավոր հետագծման միջակայքներ են կուտակվում, դրանց համախմբումը այնքան էլ հեշտ խնդիր չի դառնում: Դա անելու պաշտոնական միջոց կա. կայծ-կախվածություններ. Այնուամենայնիվ, ամբողջական գրաֆիկ ստեղծելու համար ժամեր կպահանջվեն և կստիպեն ձեզ ներբեռնել Jaeger-ից անցած XNUMX ժամվա ընթացքում ամբողջ տվյալների բազան:

Եթե ​​դուք օգտագործում եք Elasticsearch-ը հետագծման բացերը պահելու համար, կարող եք օգտագործել պարզ Golang կոմունալ, որը րոպեների ընթացքում կկառուցի նույն գրաֆիկը՝ օգտագործելով Elasticsearch-ի հնարավորություններն ու հնարավորությունները։

Ինչպես օգտագործել Netramesh-ը

Netra-ն հեշտությամբ կարելի է ավելացնել ցանկացած նվագախմբի աշխատող ցանկացած ծառայությանը: Դուք կարող եք տեսնել մի օրինակ այստեղ.

Ներկա պահին Netra-ն հնարավորություն չունի ավտոմատ կերպով ներդնելու կողային մեքենաներ ծառայություններին, սակայն կան ծրագրեր իրականացնելու համար:

Նեթրամեշի ապագան

հիմնական նպատակը Նետրամեշ ռեսուրսների նվազագույն ծախսերի և բարձր կատարողականության հասնելն է` ապահովելով միջսպասարկման հաղորդակցության դիտարկելիության և վերահսկման հիմնական հնարավորությունները:

Ապագայում Netramesh-ը HTTP-ից բացի կաջակցի այլ կիրառական շերտերի արձանագրություններին։ L7 երթուղիչը հասանելի կլինի մոտ ապագայում:

Օգտագործեք Netramesh-ը, եթե հանդիպում եք նմանատիպ խնդիրների և գրեք մեզ հարցերով և առաջարկներով:

Source: www.habr.com