Здрасти! Аз съм Вадим Мадисон и ръководя разработката на 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, имейл);
• проследяване на задачи; (Jira)
• съставяне на документация.

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

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

Провеждането на единна „партийна политика“ сред многото микросервизи на Авито е улеснено от:

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

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

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

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

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

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

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

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

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

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

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

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

CLI-push

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

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

— Създава услуга по шаблон — стъпка по стъпка, в режим на "wizard". Имаме шаблони за основните програмни езици в бекенда на Авито: 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 трябва да сигнализира на собственика на услугата, когато стане безопасно да се приложи.

Bake

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

• Сглобяване на приложението. По класическия начин — в Docker образ.
• Генериране на Helm чартове за самата услуга и свързаните с нея ресурси. Включително за бази данни и кеш. Те се създават автоматично в съответствие с конфигурацията app.toml, която е била генерирана на етапа на CLI-push.
• Създаване на билети за администраторите за отваряне на портове (когато това е необходимо).
• Изпълнение на модулни тестове и изчисляване на 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 е твърде много, тогава вероятно има някаква грешка и някой от endpoint-овете е спрял да изпълнява полезната натовареност, а просто сработва някакъв return true;

Canary тестове

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

Squeeze Testing

Тестът чрез изстискване също се нарича тестиране чрез «изплъзване». Методологията е въведена в Netflix. Основната му идея е, че първо запълваме един инстанс с реален трафик до отказ и по този начин определяме неговия предел. След това добавяме още един инстанс и натоварваме тази двойка — отново до максимума; виждаме какъв е техният таван и разликата с първия «сквиз». И така добавяме по един инстанс в стъпка и изчисляваме закономерността в промените.
Данните от тестовете чрез «изстискване» също се натрупват в обща база метрики, където или обогатяваме резултатите от изкуствени натоварвания, или изцяло заменяме «синтетиката» с тях.

Продукция

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

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

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

Поддръжка

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

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

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

Табло

Ако искаме да кажем накратко, таблото е контролен панел на всичките ни PaaS.

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

Итого

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

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

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

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

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

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

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