Докато преминаваме от монолитно приложение към архитектура на микроуслуги, ние се изправяме пред нови предизвикателства.

В монолитно приложение обикновено е доста лесно да се определи в коя част от системата е възникнала грешката. Най-вероятно проблемът е в кода на самия монолит или в базата данни. Но когато започнем да търсим проблем в архитектура на микросервиз, всичко вече не е толкова очевидно. Трябва да намерим целия път, който е извървяла заявката от началото до края и да го изберем от стотици микроуслуги. Освен това, много от тях имат и собствени съоръжения за съхранение, което също може да причини логически грешки, както и проблеми с производителността и устойчивостта на грешки.

От дълго време търся инструмент, който би помогнал да се справя с подобни проблеми (писах за това на Habré: 1, 2), но в крайна сметка направих свое собствено решение с отворен код. В тази статия говоря за предимствата на мрежовия подход на услугата и споделям нов инструмент за внедряването му.

Разпределеното проследяване е често срещано решение на проблема с намирането на грешки в разпределени системи. Но какво ще стане, ако този подход за събиране на информация за мрежовите взаимодействия все още не е внедрен в системата или, по-лошо, в част от системата вече работи правилно, но отчасти не, тъй като не е добавен към стари услуги ? За да се определи точната първопричина за даден проблем, е необходимо да имате пълна картина на случващото се в системата. Особено важно е да разберете кои микроуслуги участват в ключови критични за бизнеса пътища.

Тук на помощ може да ни дойде мрежовият подход на услугата, който ще се справи с всички машини за събиране на мрежова информация на ниво, по-ниско от това, което работят самите услуги. Този подход ни позволява да прихванем целия трафик и да го анализираме в движение. Освен това приложенията дори не трябва да знаят нищо за това.

Сервизен мрежов подход

Основната идея на подхода на услугата mesh е да добавим друг инфраструктурен слой върху мрежата, което ще ни позволи да правим всичко с взаимодействие между услугите. Повечето реализации работят по следния начин: към всяка микроуслуга се добавя допълнителен контейнер с прозрачен прокси, през който преминава целият входящ и изходящ трафик на услугата. И това е мястото, където можем да правим балансиране на клиенти, да прилагаме политики за сигурност, да налагаме ограничения върху броя на заявките и да събираме важна информация за взаимодействието на услугите в производството.

Решения

Вече има няколко реализации на този подход: Истио и linkerd2. Те предоставят много функции извън кутията. Но в същото време има големи разходи за ресурси. Освен това, колкото по-голям е клъстерът, в който работи такава система, толкова повече ресурси ще са необходими за поддържане на новата инфраструктура. В Avito ние управляваме kubernetes клъстери, които съдържат хиляди екземпляри на услуги (и броят им продължава да расте бързо). В текущото си изпълнение Istio консумира ~300Mb RAM на екземпляр на услуга. Поради големия брой възможности, прозрачното балансиране също влияе върху общото време за реакция на услугите (до 10ms).

В резултат на това разгледахме точно от какви възможности се нуждаем в момента и решихме, че основната причина, поради която започнахме да внедряваме такива решения, е възможността за прозрачно събиране на информация за проследяване от цялата система. Също така искахме да имаме контрол върху взаимодействието на услугите и да правим различни манипулации със заглавките, които се прехвърлят между услугите.

В резултат на това стигнахме до нашето решение:  Нетрамеш.

Нетрамеш

Нетрамеш е леко мрежесто решение за услуги с възможност за безкрайно мащабиране, независимо от броя на услугите в системата.

Основните цели на новото решение бяха ниски разходи за ресурси и висока производителност. Сред основните характеристики, веднага поискахме да можем прозрачно да изпращаме проследяващи участъци към нашата система Jaeger.

Днес повечето облачни решения се внедряват в Golang. И, разбира се, има причини за това. Писането на мрежови приложения в Golang, които работят асинхронно с I/O и мащабират ядрата според нуждите, е удобно и доста просто. И което също е много важно, производителността е достатъчна, за да реши този проблем. Затова избрахме и Golang.

продуктивност

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

Да видим какви резултати имаме.

RAM

Netramesh консумира ~10Mb без трафик и 50Mb максимум с натоварване до 10000 XNUMX RPS на инстанция.

Istio envoy proxy винаги консумира ~300Mb в нашите клъстери с хиляди инстанции. Това не позволява да се мащабира към целия клъстер.

С Netramesh получихме ~10 пъти намаление на потреблението на памет.

процесор

Използването на процесора е относително равно при натоварване. Зависи от броя заявки за единица време към коша. Стойности при 3000 заявки в секунда при пик:

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

Използваме HTTP/1 за комуникация между услугите. Увеличаването на времето за реакция за Istio при прокси чрез пратеник беше до 5-10 ms, което е доста за услуги, които са готови да отговорят за милисекунда. С 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 на възела остава точно същият като без netra.

Разпределено проследяване и препращане на контекст

Netramesh предоставя функционалността, необходима за изпращане на проследяване на интервали за HTTP взаимодействия. Netra-sidecar анализира HTTP протокола, измерва закъсненията на заявките и извлича необходимата информация от HTTP заглавките. В крайна сметка получаваме всички следи в една единствена система Jaeger. За фина конфигурация можете също да използвате променливите на средата, предоставени от официалната библиотека jaeger go библиотека.

Но има проблем. Докато услугите не генерират и изпратят специална uber заглавка, няма да видим свързани проследяващи участъци в системата. И това е, от което се нуждаем, за да открием бързо причината за проблемите. И тук Netramesh има решение. Прокситата четат HTTP заглавки и, ако не съдържат uber trace 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 заглавки в съответни проследяващи span тагове. Това може да бъде особено полезно за тестване. След като преминете функционалния тест, можете да видите коя част от системата е била засегната от филтриране чрез съответния сесиен ключ.

Определяне на източника на заявка

За да определите откъде идва заявката, можете да използвате функцията за автоматично добавяне на заглавка с източника. Използване на променлива на средата 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

Основната цел Нетрамеш е да се постигнат минимални разходи за ресурси и висока производителност, осигурявайки основни възможности за наблюдение и контрол на комуникацията между службите.

В бъдеще Netramesh ще поддържа други протоколи на приложния слой освен HTTP. L7 маршрутизирането ще бъде налично в близко бъдеще.

Използвайте Netramesh, ако срещнете подобни проблеми и ни пишете с въпроси и предложения.

Източник: www.habr.com