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

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

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

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

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

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

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

Как да преодолеем епохата на 'микросервисната разпокъсаност'

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

Освен това, за да е ефективна микросервисната архитектура, е нужно да се организират множество процеси, а именно:

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

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

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

Единната «политика на партията» сред многото микросервизи на Авито се подпомага от:

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

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

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

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

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

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

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

Реализацията на микросервиси в Авито също се извършва по единен модел, което опростява контрола над тях на всяка фаза от разработката и пускането.

Как е структуриран стандартният конвейер за разработка на микросервис?

В общи линии, веригата за създаване на микросервис изглежда по следния начин:

CLI-push → Непрекъсната интеграция → Бейкване → Деплойване → Изкуствени тестове → Канарски тестове → Стрес тестове → Продукция → Поддръжка.

Да преминем през нея точно в тази последователност.

CLI-push

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

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

— Създава сервиз по шаблон — стъпка по стъпка, в режим на «магьосник». Имаме шаблони за основните програмни езици в бекенда на Авито: PHP, Golang и Python.

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

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

— Също така извършва live билд. Предположим, разработчикът е направил промяна в микросервиса чрез своята IDE. Инструментът вижда промените в файловата система и на базата на тях пренастройва приложението (за Golang) и рестартира. За PHP просто прехвърляме директорията в куба и там live reload се получава «автоматично».

— Генерира автоматични тестове. Във вид на шаблони, но напълно пригодни за употреба.

• Деплой на микросервиз..

Разгръщането на микросервиз у нас преди беше малко сложно. Задължително бяха нужни:

I. Dockerfile.

II. Конфигурационен файл.
III. Helm чарт, който сам по себе си е тромав и включва:

— самите чарта;
— шаблони;
— конкретни стойности с оглед на различни среди.

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

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

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

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

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

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

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

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

IV. FAQ., където е добре да предвиди проблемите, с които могат да се сблъскат вашите колеги при работа с услугата.

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

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

VII. Притежател или притежатели на услугата. В повечето случаи тях — или неговите — можем да определим автоматично чрез PaaS, но за сигурност изискваме от разработчика да ги посочи и ръчно.

Накрая, добра практика е да се провеждат ревюта на документацията, подобно на код ревюта.

Continuous Integration

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

Опаковка

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

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

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

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

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

Деплой

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

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

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

• Тестиране в затворен контур. Сега използваме опен сорс Hoverfly.io. Първо записва реалното натоварване на услугата и след това - точно в затворения контур - го емулира.

• Тестиране на натоварване. Стремим се да доведем всички услуги до оптимална производителност. И всички версии на всяка услуга трябва да се подлагат на тестиране на натоварване — така можем да разберем текущата производителност на услугата и разликата с предходните версии на същата услуга. Ако след обновление производителността на услугата е спаднала с 50%, това е ясен сигнал за нейния собственик: необходимо е да се копае в кода и да се поправи ситуацията.
От събраните данни черпим, например, за да реализираме правилно автомасштабиране и, в крайна сметка, да разберем колко добре услугата се поддава на мащабиране.

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

a) Гледаме на общото натоварване.
— Прекалено ниско — вероятно нещо изобщо не работи, ако натоварването е спаднало многократно.
— Прекалено високо — необходима е оптимизация.

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

Canary-тестове

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

Squeeze Testing

Squeeze тестове, известни още като тестове чрез "издлъгване", бяха въведени от Netflix. Същността на методологията е, че първо запълваме един инстанс с реален трафик до отказ и така установяваме пределите му. След това добавяме още един инстанс и натоварваме тези два инстанса отново до максимума; наблюдаваме техния таван и разликата с първия "сквиз". И така, свързваме по един инстанс в стъпки и изчисляваме закономерностите на промените.
Данните от тестовете чрез "издлъгване" също се инжектират в обща база метрики, където или обогатяваме резултатите от изкуствено натоварване, или напълно ги заменяме с "синтетично".

Продукция

• Мащабиране. Когато пускаме услугата в продукция, следим как се мащабира. По наш опит, мониторингът само на показателите на CPU е неефективен. Автоматичното мащабиране с бенчмаркинг RPS в чист вариан е ефективно, но само за определени услуги, като онлайн стрийминг. Затова преди всичко гледаме на специфични за приложението продуктови метрики.

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

При мащабиране на услугата е също важно да проследяваме зависимостите, за да не се случи така, че първата услуга в веригата да се мащабира, а тези, към които тя се обръща, да паднат под натоварване. За да установим приемливо натоварване за целия пул услуги, гледаме историческите данни на "близката" зависима услуга (по комбинация от показатели на CPU и RAM заедно с app-specific metrics) и ги съпоставяме с историческите данни на инициализиращата услуга, и така нататък по цялата "верига от зависимости", отгоре надолу.

Поддръжка

След като микросервисът е пуснат в действие, можем да добавим тригери към него.

Ето типични ситуации, в които се задействат тригерите.
— Открити са потенциално опасни миграции.
— Издадени са актуализации за сигурност.
— Самата услуга отдавна не е актуализирана.
— Значително е намаляло натоварването на услугата или някои от продуктови ѝ метрики излизат извън нормите.
— Услугата е престанала да отговаря на новите изисквания на платформата.

Част от тригерите отговаря за стабилността на работата, част — като функция за обслужване на системата — например, някаква услуга отдавна не е била внедрена и основният ѝ образ е спрял да преминава сигурностната проверка.

Дашборд

Накратко, дашбордът е контролният панел за всичките ни PaaS услуги.

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

Общо

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

Презентирах на тази тема на HighLoad++ 2018, може да погледнете видеото и презентацията.

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

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

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

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

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