Здравейте! Казвам се Вадим Мадисън, ръководя разработката на системната платформа Avito. Как ние в компанията преминаваме от монолитна архитектура към микроуслуга е казано повече от веднъж. Време е да споделим как трансформирахме нашата инфраструктура, за да извлечем максимума от микроуслугите и да не се изгубим в тях. Как PaaS ни помага тук, как опростихме внедряването и намалихме създаването на микроуслуга до едно кликване - прочетете нататък. Не всичко, за което пиша по-долу, е напълно внедрено в Avito, част от това е как развиваме нашата платформа.

(И в края на тази статия ще говоря за възможността да стигнете до тридневен семинар от експерт по микросервизна архитектура, Крис Ричардсън).

Как стигнахме до микроуслугите

Avito е един от най-големите обяви в света, публикува повече от 15 милиона нови реклами на ден. Нашият бекенд приема повече от 20 хиляди заявки в секунда. Сега имаме няколкостотин микроуслуги.

Ние изграждаме архитектура на микросервиз повече от година. Как точно - нашите колеги подробно каза в нашия раздел на RIT++ 2017. На CodeFest 2017 (вж видео), Сергей Орлов и Михаил Прокопчук обясниха подробно защо изобщо се нуждаехме от прехода към микроуслуги и каква роля изигра Kubernetes тук. Е, сега правим всичко, за да минимизираме разходите за мащабиране, които са присъщи на такава архитектура.

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

Сега, в помощната програма PaaS CLI, един екип създава нова услуга, а други два добавят нова база данни и я внедряват в Stage.

Как да преодолеем ерата на „фрагментацията на микроуслугите“

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

В допълнение, за да бъде ефективна архитектурата на микросервизите, е необходимо да се установят много процеси, а именно:

• дърводобив;
• проследяване на заявка (Jaeger);
• агрегиране на грешки (Sentry);
• статуси, съобщения, събития от Kubernetes (Event Stream Processing);
• ограничение на състезанието / прекъсвач (можете да използвате Hystrix);
• контрол на свързаността на услугата (използваме Netramesh);
• мониторинг (Графана);
• монтаж (TeamCity);
• комуникация и уведомяване (Slack, имейл);
• проследяване на задачи; (Джира)
• изготвяне на документация.

За да гарантираме, че системата няма да загуби целостта си и ще остане ефективна, докато се мащабира, ние преосмислихме организацията на микроуслугите в Avito.

Как управляваме микроуслуги

Avito помага за провеждането на една "партийна политика" сред многото микроуслуги:

• разделяне на инфраструктурата на слоеве;
• концепцията за платформа като услуга (PaaS);
• следене на всичко, което се случва с микроуслугите.

Нивата на абстракция на инфраструктурата включват три слоя. Да вървим отгоре надолу.

А. Горна - сервизна мрежа. Първоначално опитахме Istio, но се оказа, че използва твърде много ресурси, което е твърде скъпо за нашите обеми. Затова старшият инженер в архитектурния екип Александър Лукянченко разработи свое собствено решение − Нетрамеш (наличен в Open Source), който в момента използваме в производство и който консумира няколко пъти по-малко ресурси от Istio (но не прави всичко, с което Istio може да се похвали).
B. Среден - Kubernetes. На него внедряваме и управляваме микроуслуги.
В. Дъно - гол метал. Ние не използваме облаци и неща като OpenStack, но стоим изцяло на гол метал.

Всички слоеве са комбинирани PaaS. А тази платформа от своя страна се състои от три части.

I. Генератори, управлявани чрез помощната програма CLI. Именно тя помага на разработчика да създаде микроуслуга по правилния начин и с минимални усилия.

II. Консолидиран колектор с управление на всички инструменти чрез общо табло.

III. съхранение. Свързва се със програмисти за планиране, които автоматично задават тригери за значими действия. Благодарение на такава система не се пропуска нито една задача само защото някой е забравил да постави задача в Jira. За това използваме вътрешен инструмент, наречен Atlas.

Внедряването на микроуслуги в Avito също се извършва по една схема, което опростява контрола върху тях на всеки етап от разработката и пускането.

Как работи стандартният тръбопровод за разработка на микроуслуги

Като цяло веригата за създаване на микроуслуга изглежда така:

CLI-push → Continuous Integration → Bake → Deploy → Artificial tests → Canary tests → Squeeze Testing → Production → Maintenance.

Нека го прегледаме точно в този ред.

CLI-натискане

• Създаване на микроуслуга.
Борихме се дълго време да научим всеки разработчик как да прави микроуслуги. Включително написа подробни инструкции в Confluence. Но схемите се променяха и допълваха. Резултатът - в началото на пътуването се образува тясно място: отне много повече време за стартиране на микроуслугите от допустимото и въпреки това често имаше проблеми при създаването им.

В крайна сметка създадохме проста CLI помощна програма, която автоматизира основните стъпки за създаване на микроуслуга. Всъщност той замества първия git push. Ето какво точно прави тя.

- Създава услуга по шаблон - стъпка по стъпка, в режим "wizard". Имаме шаблони за основните езици за програмиране в бекенда на Avito: PHP, Golang и Python.

- Една команда разгръща локална среда за разработка на конкретна машина - Minikube се издига, Helm диаграмите се генерират автоматично и се изпълняват в локални kubernetes.

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

- Той сам извършва сглобяване на живо. Да приемем, че разработчикът коригира нещо в микроуслугата чрез своята IDE. Помощната програма вижда промени във файловата система и въз основа на тях възстановява приложението (за Golang) и рестартира. За PHP ние просто препращаме директорията вътре в куба и там презареждането на живо се получава „автоматично“.

- Генерира автотестове. Под формата на заготовки, но доста използваеми.

• Разположете микросервиз.

Преди беше малко скучно да разположим микроуслуга при нас. Задължително задължително:

I. Докер файл.

II. Конфиг.
III. Хелм-диаграма, която сама по себе си е тромава и включва:

- самите графики;
- шаблони;
- специфични стойности, като се вземат предвид различните среди.

Премахнахме болката от преработването на манифестите на Kubernetes и сега те се генерират автоматично. Но най-важното е, че опростихме внедряването до краен предел. Отсега нататък имаме Dockerfile и разработчикът записва цялата конфигурация в един кратък app.toml файл.

Да, и в самия app.toml сега има въпрос за минута. Ние предписваме къде колко копия на услугата да се създадат (на dev-сървъра, на сцената, на продукцията), посочваме нейните зависимости. Обърнете внимание на размера на реда = "малък" в блока [двигател]. Това е ограничението, което ще бъде разпределено за услугата чрез Kubernetes.

Освен това, въз основа на конфигурацията, автоматично се генерират всички необходими Helm-диаграми и се създават връзки към базите данни.

• Основно валидиране. Такива проверки също са автоматизирани.
Трябва да проследите:
- има ли Dockerfile;
- има ли app.toml;
- Има ли документация?
— дали в реда на зависимост;
— дали са зададени правила за предупреждение.
До последната точка: собственикът на услугата сам определя кои продуктови показатели да се следят.

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

I. Кратко описание на услугата. Само няколко изречения за това какво прави и за какво служи.

II. Връзка към диаграма на архитектурата. Важно е с един поглед да е лесно да се разбере, например, дали използвате Redis за кеширане или като основно хранилище на данни в постоянен режим. В Avito засега това е връзка към Confluence.

III. runbook. Кратко ръководство за стартиране на услугата и тънкостите при работа с нея.

IV. ЧЗВ, където би било добре да предвидите проблемите, които вашите колеги могат да срещнат при работа с услугата.

V. Описание на крайните точки на API. Ако изведнъж не сте посочили дестинации, колегите, чиито микроуслуги са свързани с вашите, почти сигурно ще платят за това. Сега използваме Swagger за това и нашето решение се нарича brief.

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

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

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

Непрекъснато интегриране

• Подготовка на хранилища.
• Създаване на конвейер в TeamCity.
• Предоставяне на права.
• Търсене на собственици на услуги. Ето една хибридна схема - ръчно маркиране и минимална автоматизация от PaaS. Напълно автоматичната схема се проваля, когато услугите се прехвърлят към поддръжка в друг екип за разработка или, например, ако разработчикът на услугата напусне.
• Регистрация на услугата в Atlas (виж по-горе). С всичките си собственици и зависимости.
• Проверка на миграциите. Проверяваме дали сред тях няма потенциално опасни. Например в един от тях изскача таблица за промяна или нещо друго, което може да наруши съвместимостта на схемата на данните между различните версии на услугата. Тогава миграцията не се извършва, а се поставя в абонамент - PaaS трябва да сигнализира на собственика на услугата, когато стане безопасно да я приложи.

пека

Следващият етап са опаковъчните услуги преди внедряването.

• Сглобяване на приложението. Според класиката - в Docker изображение.
• Генериране на диаграми на Helm за самата услуга и свързаните с нея ресурси. Включително за бази данни и кеш. Те се създават автоматично в съответствие с конфигурацията на app.toml, която е генерирана на етапа на CLI-push.
• Създаване на билети за администратори за отваряне на портове (когато е необходимо).
• Изпълнение на модулни тестове и изчисляване на покритието на кода. Ако покритието на кода е под определената прагова стойност, тогава най-вероятно услугата няма да отиде по-нататък - до внедряването. Ако е на ръба на приемливото, тогава на услугата ще бъде присвоен „песимизиращ“ коефициент: тогава, ако няма подобрение на индикатора с течение на времето, разработчикът ще получи известие, че няма напредък по отношение на тестовете ( и трябва да се направи нещо по въпроса).
• Отчитане на ограниченията на паметта и процесора. По принцип ние пишем микроуслуги в Golang и ги изпълняваме в Kubernetes. Следователно, една тънкост, свързана с функцията на езика Golang: по подразбиране всички ядра на машината се използват при стартиране, ако не зададете изрично променливата GOMAXPROCS и когато няколко такива услуги се стартират на една и съща машина, те започват да се конкурират за ресурси, като си пречат. Графиките по-долу показват как се променя времето за изпълнение, ако приложението се изпълнява без конкуренция и в режим на състезание за ресурси. (Източниците на графиките са тук).

Време за изпълнение, по-малко е по-добре. Максимум: 643ms, минимум: 42ms. Снимката може да се кликне.

Време е за операция, по-малко е по-добре. Максимум: 14091 ns, минимум: 151 ns. Снимката може да се кликне.

На етапа на подготовка на сглобяването можете да зададете тази променлива изрично или можете да използвате библиотеката automaxprocs от момчетата в Uber.

Разположете

• Проверка на конвенциите. Преди да започнете да доставяте компилации на услуги в предвидените от вас среди, трябва да проверите следното:
- API крайни точки.
— Съответствие на отговорите на крайните точки на API към схемата.
- Формат на регистрационния файл.
- Задаване на заглавки за заявки към услугата (сега това се прави от netramesh)
- Настройка на маркера на собственика при изпращане на съобщения до автобуса (шина за събития). Това е необходимо за проследяване на свързаността на услугите през автобуса. Можете да изпращате както идемпотентни данни към шината, които не увеличават свързаността на услугите (което е добре), така и бизнес данни, които подобряват свързаността на услугите (което е много лошо!). И в момента, когато тази свързаност се превърне в проблем, разбирането кой пише и чете автобуса помага за правилното разделяне на услугите.

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

Синтетични тестове

• Тестване в затворен цикъл. За него сега използваме отворен код hoverfly.io. Първо записва реалното натоварване на услугата, след което - само в затворен цикъл - емулира.

• Стрес тестване. Ние се опитваме да доведем всички услуги до оптимална производителност. И всички версии на всяка услуга трябва да бъдат подложени на тестване за натоварване - за да можем да разберем текущата производителност на услугата и разликата с предишните версии на същата услуга. Ако след актуализация на услугата нейната производителност е паднала с един и половина пъти, това е ясен сигнал за нейните собственици: трябва да копаете в кода и да коригирате ситуацията.
Започваме от събраните данни, например, за да приложим правилно автоматичното мащабиране и в крайна сметка да разберем като цяло колко мащабируема е услугата.

По време на тестването на натоварване проверяваме дали потреблението на ресурси отговаря на зададените ограничения. И ние се фокусираме предимно върху крайностите.

а) Разглеждаме общото натоварване.
- Твърде малък - най-вероятно нещо изобщо не работи, ако товарът внезапно падне няколко пъти.
- Твърде голям - необходима е оптимизация.

b) Вижте прекъсването на RPS.
Тук разглеждаме разликата между текущата версия и предишната и общия брой. Например, ако услугата дава 100 rps, тогава тя е или лошо написана, или това е нейната специфика, но във всеки случай това е причина да разгледате услугата много внимателно.
Ако, напротив, има твърде много RPS, тогава може би някакъв вид грешка и някои от крайните точки са спрели да изпълняват полезния товар, но само някои return true;

Канарски тестове

След преминаване на синтетичните тестове, ние изпълняваме микроуслугата на малък брой потребители. Започваме внимателно, с малък дял от целевата аудитория на услугата - под 0,1%. На този етап е много важно в мониторинга да бъдат въведени правилните технически и продуктови показатели, така че те да покажат проблема в услугата възможно най-бързо. Минималното време за тест за канарчета е 5 минути, основното е 2 часа. За комплексни услуги задаваме времето в ръчен режим.
Ние анализираме:
- специфични за езика показатели, по-специално php-fpm работници;
— грешки в Sentry;
— състояния на отговор;
— време за реакция (време за реакция), точно и средно;
— латентност;
- изключения, обработени и необработени;
- продуктови показатели.

Тестване на притискане

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

производство

• Мащабиране. Разпространявайки услугата в производство, ние наблюдаваме как се мащабира. В същото време наблюдението само на индикаторите на процесора според нашия опит е неефективно. Автоматичното мащабиране с RPS бенчмаркинг работи в най-чистата си форма, но само за определени услуги, като например онлайн стрийминг. Така че ние разглеждаме предимно продуктови показатели за конкретно приложение.

В резултат на това при мащабиране анализираме:
- Индикатори за CPU и RAM,
- броя на заявките в опашката,
- време за реакция,
— прогноза въз основа на натрупани исторически данни.

При мащабиране на услуга е важно също така да следим нейните зависимости, за да не се случи така, че да скалираме първата услуга във веригата и тези, до които тя има достъп, да попаднат под натоварване. За да установим приемливо натоварване за целия набор от услуги, ние разглеждаме историческите данни на „най-близката“ зависима услуга (по отношение на CPU и RAM, заедно със специфични за приложението показатели) и ги сравняваме с историческите данни на инициализиращата услуга и така нататък по цялата „верига на зависимостта“, отгоре надолу.

обслужване

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

Ето типични ситуации, в които тригерите работят.
- Открити са потенциално опасни миграции.
- Актуализациите за сигурност са пуснати.
- Самата услуга не е актуализирана от дълго време.
— Натоварването на услугата забележимо е намаляло или някои от нейните продуктови показатели са извън нормата.
— Услугата вече не отговаря на новите изисквания на платформата.

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

Табло

Накратко, таблото за управление е контролният панел на целия ни PaaS.

• Единна точка на информация за услугата, с данни за нейното тестово покритие, броя на нейните изображения, броя на производствените копия, версиите и др.
• Инструмент за филтриране на данни по услуги и етикети (токени за принадлежност към бизнес единици, функционалност на продукта и др.)
• Инструмент за интегриране с инфраструктурни инструменти за проследяване, регистриране, наблюдение.
• Единна точка на документация за услуги.
• Единна гледна точка на всички събития по услуга.

Общо

Преди въвеждането на PaaS, нов разработчик може да прекара няколко седмици в разбиране на всички инструменти, необходими за стартиране на микроуслуга в производство: Kubernetes, Helm, нашите вътрешни функции на TeamCity, настройка на връзка с бази данни и кешове по безопасен начин и т.н. , Сега отнема няколко часа, за да прочетете бърз старт и да направите самата услуга.

Направих доклад по тази тема за HighLoad ++ 2018, можете да видите видео и представяне.

Бонус песен за тези, които четат до края

Ние от Avito организираме вътрешно тридневно обучение за разработчици от Крис Ричардсън, експерт по архитектура на микросервизи. Искаме да дадем възможност да участва в него на някой от читателите на тази публикация. Тук програмата за обучение е публикувана.

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

Можете да заявите участие в тази гугъл форма. От вас - отговорът на въпроса защо трябва да присъствате на обучението и информация как да се свържем с вас. Отговорете на английски, защото участникът, който ще стигне до обучението, ще бъде избран от самия Крис.
Ще обявим името на участника в обучението с актуализация на тази публикация и в социалните мрежи Avito за разработчици (AvitoTech в Фейсбуке, VKontakte, кикотене) не по-късно от 19 юли.

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