Како што преминуваме од монолитна апликација кон архитектура на микросервис, се соочуваме со нови предизвици.

Во монолитна апликација, обично е прилично лесно да се одреди во кој дел од системот настанала грешката. Најверојатно, проблемот е во кодот на самиот монолит, или во базата на податоци. Но, кога ќе почнеме да бараме проблем во архитектурата на микросервис, сè веќе не е толку очигледно. Треба да ја пронајдеме целата патека што ја помина барањето од почеток до крај и да ја избереме од стотици микросервиси. Покрај тоа, многу од нив имаат и свои капацитети за складирање, што исто така може да предизвика логички грешки, како и проблеми со перформансите и толеранција на грешки.

Долго време барав алатка која ќе помогне да се справам со вакви проблеми (напишав за ова на Хабре: 1, 2), но на крајот направив свое решение со отворен код. Во оваа статија зборувам за придобивките од пристапот на сервисната мрежа и споделувам нова алатка за нејзина имплементација.

Дистрибуираното следење е вообичаено решение за проблемот со наоѓање грешки во дистрибуираните системи. Но, што ако овој пристап за собирање информации за мрежните интеракции сè уште не е имплементиран во системот, или, уште полошо, во дел од системот тој веќе работи правилно, но делумно не, бидејќи не е додаден на старите услуги ? За да се утврди точната основна причина за проблемот, неопходно е да се има целосна слика за тоа што се случува во системот. Особено е важно да се разбере кои микроуслуги се вклучени во клучните бизнис-критични патеки.

Овде може да ни дојде на помош пристапот на сервисна мрежа, кој ќе се справи со целата машинерија за собирање мрежни информации на ниво пониско отколку што работат самите сервиси. Овој пристап ни овозможува да го пресретнеме целиот сообраќај и да го анализираме во лет. Покрај тоа, апликациите дури и не мора да знаат ништо за тоа.

Сервисна мрежа пристап

Главната идеја на пристапот на сервисната мрежа е да додадеме уште еден инфраструктурен слој преку мрежата, што ќе ни овозможи да правиме што било со интеракција меѓу услугите. Повеќето имплементации функционираат на следниов начин: дополнителен контејнер со проѕирен прокси се додава на секој микросервис, преку кој се пренесува целиот дојдовен и појдовен сообраќај на услугата. И ова е самото место каде што можеме да направиме балансирање на клиентите, да примениме безбедносни политики, да наметнеме ограничувања на бројот на барања и да собираме важни информации за интеракцијата на услугите во производството.

Решенија

Веќе има неколку имплементации на овој пристап: Истио и поврзувач2. Тие обезбедуваат многу функции надвор од кутијата. Но, во исто време, има големи трошоци за ресурсите. Покрај тоа, колку е поголем кластерот во кој функционира таков систем, толку повеќе ресурси ќе бидат потребни за одржување на новата инфраструктура. Во Avito, управуваме со кластери kubernetes кои содржат илјадници примероци на услуги (и нивниот број продолжува брзо да расте). Во својата сегашна имплементација, Istio троши ~ 300Mb RAM меморија по пример на услуга. Поради големиот број на можности, транспарентното балансирање влијае и на целокупното време на одговор на услугите (до 10 ms).

Како резултат на тоа, погледнавме точно какви способности ни се потребни во моментов и одлучивме дека главната причина зошто почнавме да имплементираме такви решенија е можноста транспарентно да собираме информации за следење од целиот систем. Исто така, сакавме да имаме контрола врз интеракцијата на услугите и да правиме разни манипулации со заглавјата кои се пренесуваат помеѓу сервисите.

Како резултат, дојдовме до нашата одлука:  Нетрамеш.

Нетрамеш

Нетрамеш е лесно сервисно мрежно решение со можност за бесконечно скалирање, без оглед на бројот на услуги во системот.

Главните цели на новото решение беа ниски трошоци за ресурси и високи перформанси. Од главните карактеристики, веднаш сакавме да можеме транспарентно да испраќаме распони за следење до нашиот систем Јегер.

Денес, повеќето облак решенија се имплементирани во Голанг. И, се разбира, постојат причини за ова. Пишувањето мрежни апликации во Golang кои работат асинхроно со I/O и размеруваат низ јадра по потреба е практично и прилично едноставно. И што е исто така многу важно, перформансите се доволни за да се реши овој проблем. Затоа го избравме и Голанг.

Перформанси

Нашите напори ги насочивме кон постигнување максимална продуктивност. За решение што е распоредено до секој примерок на услугата, потребна е мала потрошувачка на време на RAM и процесорот. И, се разбира, доцнењето на одговорот исто така треба да биде мало.

Ајде да видиме какви резултати добивме.

RAM меморија

Netramesh троши ~10Mb без сообраќај и 50Mb максимум со оптоварување до 10000 RPS по пример.

Istio envoy proxy секогаш троши ~ 300Mb во нашите кластери со илјадници примероци. Ова не дозволува да се скалира на целиот кластер.

Со Netramesh добивме ~ 10x намалување на потрошувачката на меморија.

Процесорот

Употребата на процесорот е релативно еднаква под оптоварување. Тоа зависи од бројот на барања по единица време до бочната кола. Вредности од 3000 барања во секунда на врвот:

Има уште една важна точка: Netramesh - решението без контролна рамнина и без оптоварување не троши време на процесорот. Со Istio, страничните возила секогаш ги ажурираат крајните точки на услугата. Како резултат на тоа, можеме да ја видиме оваа слика без оптоварување:

Ние користиме HTTP/1 за комуникација помеѓу услугите. Зголемувањето на времето на одговор за Istio при прокси преку претставник беше до 5-10 ms, што е доста за услугите што се подготвени да одговорат во милисекунда. Со Netramesh ова време се намали на 0.5-2ms.

Приспособливост

Малата количина на ресурси потрошени од секој прокси овозможува да се постави до секоја услуга. Нетрамеш беше намерно создаден без компонента на контролната рамнина за едноставно да ја одржува лесна секоја бочна кола. Често во сервисните мрежни решенија, контролната рамнина ги дистрибуира информациите за откривање на услугата на секоја странична кара. Заедно со него доаѓаат информации за тајмаути и поставки за балансирање. Сето ова ви овозможува да правите многу корисни работи, но, за жал, ги надувува страничните кола по големина.

Откривање на услугата

Нетрамеш не додава никакви дополнителни механизми за откривање услуга. Целиот сообраќај е проксиран проксиран преку нетра страничната кола.

Netramesh поддржува протокол за апликација HTTP/1. За да се дефинира, се користи конфигурабилна листа на порти. Типично, системот има неколку порти преку кои се јавува HTTP комуникација. На пример, ние користиме 80, 8890, 8080 за интеракција помеѓу услугите и надворешните барања NETRA_HTTP_PORTS.

Ако користите Kubernetes како оркестратор и механизмот на неговиот ентитет на услугата за интер-кластерска комуникација помеѓу услугите, тогаш механизмот останува потполно ист. Прво, микросервисот добива IP адреса на услугата користејќи kube-dns и отвора нова врска со неа. Оваа врска прво се воспоставува со локалната нетра-страна карта и сите TCP пакети првично пристигнуваат на нетра. Следно, netra-sidecar воспоставува врска со оригиналната дестинација. NAT на pod IP на јазолот останува сосема ист како без нетра.

Дистрибуирано следење и проследување контекст

Netramesh ја обезбедува функционалноста потребна за испраќање распони за следење за интеракциите на HTTP. Netra-sidecar го анализира протоколот HTTP, ги мери доцнењата на барањата и ги извлекува потребните информации од заглавијата на HTTP. На крајот на краиштата, ги добиваме сите траги во еден систем Јегер. За ситно-грануларна конфигурација, можете да ги користите и променливите на околината обезбедени од официјалната библиотека jaeger go библиотека.

Но, постои проблем. Сè додека услугите не генерираат и испратат специјално убер заглавие, нема да видиме поврзани распони за следење во системот. И ова е она што ни треба за брзо да ја пронајдеме причината за проблемите. Еве повторно Нетрамеш има решение. Прокси-сериите ги читаат заглавијата на HTTP и, доколку не го содржат идентификаторот за трага uber, генерираат еден. Нетрамеш, исто така, складира информации за дојдовни и појдовни барања во странична лента и ги совпаѓа со збогатување со потребните заглавија на појдовни барања. Сè што треба да направите во услугите е да испратите само едно заглавие X-Request-Id, што може да се конфигурира со помош на променлива на околината NETRA_HTTP_REQUEST_ID_HEADER_NAME. За да ја контролирате големината на контекстот во Netramesh, можете да ги поставите следните променливи на околината: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (времето за кое ќе се чува контекстот) и NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (фреквенција на чистење на контекстот).

Исто така, можно е да се комбинираат повеќе патеки на вашиот систем со означување на нив со посебен токен за сесија. Нетра ви овозможува да инсталирате HTTP_HEADER_TAG_MAP за претворање на заглавијата на HTTP во соодветни ознаки за распон на следење. Ова може да биде особено корисно за тестирање. Откако ќе го поминете функционалниот тест, можете да видите кој дел од системот бил засегнат од филтрирањето со соодветното копче за сесија.

Одредување на изворот на барањето

За да одредите од каде доаѓа барањето, можете да ја користите функционалноста за автоматско додавање заглавие со изворот. Користење на променлива на околината NETRA_HTTP_X_SOURCE_HEADER_NAME Можете да наведете име на заглавие кое автоматски ќе се инсталира. Со користење на NETRA_HTTP_X_SOURCE_VALUE можете да ја поставите вредноста на која ќе се постави заглавјето на X-Source за сите појдовни барања.

Ова овозможува дистрибуцијата на ова корисно заглавие да се дистрибуира подеднакво низ мрежата. Потоа можете да го користите во услугите и да го додадете во дневници и метрика.

Рутирање на сообраќајот и внатрешни работи на Нетрамеш

Нетрамеш се состои од две главни компоненти. Првиот, netra-init, ги поставува мрежните правила за пресретнување на сообраќајот. Тој користи Правилата за пренасочување на iptables да го пресретне целиот или дел од сообраќајот на бочната кола, која е втората главна компонента на Нетрамеш. Можете да конфигурирате кои порти треба да бидат пресретнати за дојдовни и појдовни TCP сесии: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

Алатката има и интересна карактеристика - веројатностичко рутирање. Ако користите Netramesh исклучиво за собирање распони за следење, тогаш во производствена средина можете да заштедите ресурси и да овозможите веројатностичко рутирање користејќи променливи NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (од 0 до 1). Стандардната вредност е 1 (целиот сообраќај е пресретнат).

По успешното пресретнување, netra sidecar ја прифаќа новата врска и користи SO_ORIGINAL_DST сокет опција за да ја добиете оригиналната дестинација. Нетра потоа отвора нова врска со оригиналната IP адреса и воспоставува двонасочна TCP комуникација помеѓу страните, слушајќи го целиот сообраќај што минува низ. Ако портата е дефинирана како HTTP, Netra се обидува да ја анализира и следи. Ако HTTP парсирањето не успее, Netra се враќа на TCP и транспарентно ги проксира бајтите.

Изградба на графикон за зависност

Откако добив голема количина на информации за следење во Јегер, сакам да добијам целосен график на интеракции во системот. Но, ако вашиот систем е доста натоварен и се акумулираат милијарди распони за следење дневно, нивното собирање не станува толку лесна задача. Постои официјален начин да го направите ова: искра-зависности. Сепак, ќе бидат потребни часови за да се изгради целосен графикон и ќе ве принуди да ја преземете целата база на податоци од Јегер во изминатите 24 часа.

Ако користите Elasticsearch за складирање на распони за следење, можете да го користите едноставна алатка Golang, кој ќе го изгради истиот графикон за неколку минути користејќи ги карактеристиките и можностите на Elasticsearch.

Како да се користи Netramesh

Нетра лесно може да се додаде на која било услуга која работи на кој било оркестратор. Можете да видите пример тука.

Во моментот, Нетра нема можност за автоматско имплементирање на странични картички на услугите, но има планови за имплементација.

Иднината на Нетрамеш

Главната цел Нетрамеш е да се постигнат минимални трошоци за ресурси и високи перформанси, обезбедувајќи основни можности за набљудување и контрола на меѓусервисната комуникација.

Во иднина, Netramesh ќе поддржува и други протоколи на апликациски слој, освен HTTP. Рутирањето L7 ќе биде достапно во блиска иднина.

Користете Netramesh доколку наидете на слични проблеми и пишете ни со прашања и предлози.

Извор: www.habr.com