Како прелазимо са монолитне апликације на архитектуру микросервиса, суочавамо се са новим изазовима.
У монолитној апликацији, обично је прилично лако одредити у ком делу система је дошло до грешке. Највероватније је проблем у коду самог монолита, или у бази података. Али када почнемо да тражимо проблем у архитектури микросервиса, све више није тако очигледно. Морамо да пронађемо целу путању којом је захтев прошао од почетка до краја и да је изаберемо међу стотинама микросервиса. Штавише, многи од њих такође имају своје складишне капацитете, што такође може изазвати логичке грешке, као и проблеме са перформансама и толеранцијом грешака.
Дуго сам тражио алат који би помогао да се носим са таквим проблемима (писао сам о томе на Хабре: , ), али на крају сам направио своје решење отвореног кода. У овом чланку говорим о предностима приступа сервисне мреже и делим нови алат за његову имплементацију.
Дистрибуирано праћење је уобичајено решење за проблем проналажења грешака у дистрибуираним системима. Али шта ако овај приступ прикупљању информација о мрежним интеракцијама још увек није имплементиран у систему, или, још горе, у делу система већ функционише како треба, али делимично не, пошто није додат старим сервисима ? Да бисте утврдили тачан узрок проблема, потребно је имати потпуну слику о томе шта се дешава у систему. Посебно је важно разумети које микросервисе су укључене у кључне пословно-критичне путеве.
Овде нам у помоћ може прискочити приступ сервисне мреже, који ће се бавити свом машинеријом за прикупљање мрежних информација на нивоу нижем него што раде саме услуге. Овај приступ нам омогућава да пресретнемо сав саобраћај и анализирамо га у ходу. Штавише, апликације чак и не морају ништа да знају о томе.
Приступ сервисној мрежи
Главна идеја приступа сервисне мреже је додавање још једног инфраструктурног слоја преко мреже, што ће нам омогућити да урадимо било шта уз интеракцију између услуга. Већина имплементација функционише на следећи начин: сваком микросервису се додаје додатни сидецар контејнер са транспарентним проксијем, кроз који се пропушта сав долазни и одлазни саобраћај услуге. И то је баш место где можемо да радимо балансирање клијената, примењујемо безбедносне политике, постављамо ограничења на број захтева и прикупљамо важне информације о интеракцији услуга у продукцији.
Решења
Већ постоји неколико имплементација овог приступа: и . Пружају много функција ван кутије. Али у исто време долази до великих трошкова за ресурсе. Штавише, што је већи кластер у којем такав систем функционише, то ће више ресурса бити потребно за одржавање нове инфраструктуре. У Авито-у управљамо кубернетес кластерима који садрже хиљаде инстанци услуге (и њихов број наставља брзо да расте). У својој тренутној имплементацији, Истио троши ~300Мб РАМ-а по инстанци услуге. Због великог броја могућности, транспарентно балансирање утиче и на укупно време одзива услуга (до 10мс).
Као резултат тога, погледали смо тачно које су нам могућности тренутно потребне и одлучили да је главни разлог зашто смо почели да имплементирамо таква решења била могућност да се транспарентно прикупљају информације о праћењу из целог система. Такође смо желели да имамо контролу над интеракцијом сервиса и да радимо разне манипулације са заглављима који се преносе између сервиса.
Као резултат тога, дошли смо до наше одлуке: .
Нетрамесх
је лако сервисно мрежасто решење са могућношћу бесконачног скалирања, без обзира на број услуга у систему.
Главни циљеви новог решења били су мали трошкови ресурса и високе перформансе. Међу главним карактеристикама, одмах смо желели да будемо у могућности да транспарентно шаљемо распоне праћења у наш Јаегер систем.
Данас се већина решења у облаку имплементира у Голанг. И, наравно, постоје разлози за то. Писање мрежних апликација на Голанг-у које раде асинхроно са И/О и скалирају преко језгара по потреби је згодно и прилично једноставно. И, што је такође веома важно, перформансе су довољне за решавање овог проблема. Зато смо и изабрали Голанг.
Перформансе
Усредсредили смо напоре на постизање максималне продуктивности. За решење које се примењује поред сваке инстанце услуге, потребна је мала потрошња РАМ-а и ЦПУ времена. И, наравно, кашњење одговора такође треба да буде мало.
Да видимо какве смо резултате добили.
РАМ-
Нетрамесх троши ~10Мб без саобраћаја и максимално 50Мб са оптерећењем до 10000 РПС по инстанци.
Истио енвои проки увек троши ~300Мб у нашим кластерима са хиљадама инстанци. Ово не дозвољава да се скалира на цео кластер.
Са Нетрамесх-ом смо добили ~10к смањење потрошње меморије.
Процесор
Употреба ЦПУ-а је релативно једнака под оптерећењем. Зависи од броја захтева по јединици времена до приколице. Вредности на 3000 захтева у секунди на врхунцу:
Постоји још једна важна тачка: Нетрамесх - решење без контролне равни и без оптерећења не троши ЦПУ време. Уз Истио, приколице увек ажурирају крајње тачке услуге. Као резултат, можемо видети ову слику без оптерећења:
Користимо ХТТП/1 за комуникацију између услуга. Повећање времена одговора за Истио приликом проксија преко енвои-а било је до 5-10 мс, што је доста за сервисе који су спремни да одговоре у милисекунди. Са Нетрамесх-ом ово време је смањено на 0.5-2мс.
Прилагодљивост
Мала количина ресурса коју троши сваки прокси омогућава да се постави поред сваке услуге. Нетрамесх је намерно креиран без компоненте контролне равни да једноставно задржи сваку приколицу лаганом. Често у решењима сервисне мреже, контролна раван дистрибуира информације о откривању услуге свакој приколици. Уз то долазе и информације о тајм-аутима и поставкама балансирања. Све ово вам омогућава да урадите много корисних ствари, али, нажалост, повећава величину бочних приколица.
Откриће услуге
Нетрамесх не додаје никакве додатне механизме за откривање услуге. Сав саобраћај се преноси транспарентно кроз нетра сидецар.
Нетрамесх подржава ХТТП/1 апликацијски протокол. Да бисте га дефинисали, користи се конфигурабилна листа портова. Типично, систем има неколико портова преко којих се одвија ХТТП комуникација. На пример, користимо 80, 8890, 8080 за интеракцију између услуга и екстерних захтева. У овом случају, они се могу подесити помоћу променљиве окружења NETRA_HTTP_PORTS.
Ако користите Кубернетес као оркестратор и његов механизам сервисног ентитета за комуникацију између услуга унутар кластера, онда механизам остаје потпуно исти. Прво, микросервис добија ИП адресу услуге користећи кубе-днс и отвара нову везу са њом. Ова веза се прво успоставља са локалном нетра-сидецаром и сви ТЦП пакети прво стижу у нетра. Затим, нетра-сидецар успоставља везу са оригиналном дестинацијом. НАТ на под ИП на чвору остаје потпуно исти као без нетра.
Дистрибуирано праћење и прослеђивање контекста
Нетрамесх пружа функционалност потребну за слање распона праћења о ХТТП интеракцијама. Нетра-сидецар анализира ХТТП протокол, мери кашњења захтева и издваја потребне информације из ХТТП заглавља. На крају, добијамо све трагове у једном Јаегер систему. За детаљну конфигурацију, можете користити и променљиве окружења које обезбеђује званична библиотека .
Али постоји проблем. Све док услуге не генеришу и пошаљу посебно убер заглавље, нећемо видети повезане распоне праћења у систему. А то је оно што нам је потребно да брзо пронађемо узрок проблема. Овде поново Нетрамесх има решење. Проксији читају ХТТП заглавља и, ако не садрже убер траце ИД, генеришу га. Нетрамесх такође чува информације о долазним и одлазним захтевима у приколици и упарује их тако што их обогаћује неопходним заглављима одлазних захтева. Све што треба да урадите у услугама је да пошаљете само једно заглавље X-Request-Id, који се може конфигурисати помоћу променљиве окружења NETRA_HTTP_REQUEST_ID_HEADER_NAME. Да бисте контролисали величину контекста у Нетрамесх-у, можете поставити следеће променљиве окружења: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (време за које ће се контекст чувати) и NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (учесталост чишћења контекста).
Такође је могуће комбиновати више путања на вашем систему тако што ћете их означити посебним токеном сесије. Нетра вам омогућава да инсталирате HTTP_HEADER_TAG_MAP да претворите ХТТП заглавља у одговарајуће ознаке распона праћења. Ово може бити посебно корисно за тестирање. Након проласка функционалног теста, можете видети на који део система је утицало филтрирање помоћу одговарајућег кључа сесије.
Одређивање извора захтева
Да бисте утврдили одакле је дошао захтев, можете користити функцију аутоматског додавања заглавља са извором. Коришћење променљиве окружења NETRA_HTTP_X_SOURCE_HEADER_NAME Можете одредити име заглавља које ће се аутоматски инсталирати. Коришћењем NETRA_HTTP_X_SOURCE_VALUE можете подесити вредност на коју ће заглавље Кс-Соурце бити подешено за све одлазне захтеве.
Ово омогућава да се дистрибуција овог корисног заглавља равномерно дистрибуира широм мреже. Затим га можете користити у услугама и додати у евиденције и метрике.
Рутирање саобраћаја и Нетрамесх интерни елементи
Нетрамесх се састоји од две главне компоненте. Први, нетра-инит, поставља мрежна правила за пресретање саобраћаја. Он користи да пресретне цео или део саобраћаја на приколици, која је друга главна компонента Нетрамеша. Можете да конфигуришете који портови треба да буду пресретнути за долазне и одлазне ТЦП сесије: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.
Алат такође има занимљиву особину - вероватноћа рутирања. Ако користите Нетрамесх искључиво за прикупљање распона праћења, онда у производном окружењу можете да уштедите ресурсе и омогућите вероватноћа рутирања помоћу променљивих NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (од 0 до 1). Подразумевана вредност је 1 (сав саобраћај је пресретнут).
Након успешног пресретања, нетра сидецар прихвата нову везу и користи SO_ORIGINAL_DST опција утичнице да бисте добили оригинално одредиште. Нетра затим отвара нову везу са оригиналном ИП адресом и успоставља двосмерну ТЦП комуникацију између страна, слушајући сав саобраћај који пролази. Ако је порт дефинисан као ХТТП, Нетра покушава да га рашчлани и прати. Ако ХТТП рашчлањивање не успе, Нетра се враћа на ТЦП и транспарентно преноси бајтове.
Изградња графа зависности
Након што сам добио велику количину информација о праћењу у Јаегеру, желим да добијем комплетан графикон интеракција у систему. Али ако је ваш систем прилично оптерећен и милијарде распона праћења се акумулирају дневно, њихово обједињавање није тако лак задатак. Постоји званични начин да се то уради: . Међутим, биће потребни сати да се направи комплетан графикон и приморатиће вас да преузмете цео скуп података са Јаегер-а за последња 24 сата.
Ако користите Еластицсеарцх за чување распона праћења, можете да користите , који ће изградити исти графикон за неколико минута користећи функције и могућности Еластицсеарцх-а.
Како користити Нетрамесх
Нетра се може лако додати било којој услузи која покреће било који оркестратор. Можете видети пример .
У овом тренутку, Нетра нема могућност да аутоматски имплементира помоћне приколице у услуге, али постоје планови за имплементацију.
Будућност Нетрамеша
Главни циљ је постизање минималних трошкова ресурса и високих перформанси, обезбеђујући основне могућности за уочљивост и контролу комуникације међу службама.
У будућности, Нетрамесх ће подржавати и друге протоколе слоја апликације осим ХТТП-а. Л7 рутирање ће бити доступно у блиској будућности.
Користите Нетрамесх ако наиђете на сличне проблеме и пишите нам са питањима и предлозима.
Извор: ввв.хабр.цом