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

(И на крајот од оваа статија, ќе зборувам за можноста да присуствувам на тридневен семинар од експертот за архитектура на микросервис Крис Ричардсон).

Како дојдовме до микросервисите

Avito е една од најголемите доверливи страници во светот на неа се објавуваат повеќе од 15 милиони нови огласи дневно. Нашиот бекенд прифаќа повеќе од 20 илјади барања во секунда. Во моментов имаме неколку стотици микросервиси.

Веќе неколку години градиме микросервисна архитектура. Како точно - нашите колеги во детали раскажано во нашиот дел на RIT++ 2017. На CodeFest 2017 (види. видео), Сергеј Орлов и Михаил Прокопчук детално објаснија зошто ни требаше преминот кон микроуслуги и каква улога играше Кубернетес овде. Па, сега правиме сè за да ги минимизираме трошоците за скалирање што се својствени за таквата архитектура.

Првично, не создадовме екосистем кој сеопфатно ќе ни помогне да развиеме и лансираме микроуслуги. Тие едноставно собраа разумни решенија со отворен код, ги лансираа дома и го поканија развивачот да се справи со нив. Како резултат на тоа, тој отиде на десетина места (табла, внатрешни сервиси), по што стана посилен во желбата да го пресече кодот на стариот начин, во монолит. Зелената боја на дијаграмите подолу означува што прави развивачот на еден или друг начин со свои раце, а жолтата боја укажува на автоматизација.

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

Како да се надмине ерата на „фрагментација на микросервис“

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

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

• сеча;
• барање барање (Јегер);
• агрегација на грешки (Sentry);
• статуси, пораки, настани од Kubernetes (Обработка на тек на настани);
• ограничување на трката / прекинувач (можете да користите Hystrix);
• контрола на поврзаноста на услугите (користиме Netramesh);
• мониторинг (Графана);
• склопување (TeamCity);
• комуникација и известување (Slack, email);
• следење на задачите; (Џира)
• подготовка на документација.

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

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

Следниве помагаат да се имплементира обединета „партиска политика“ меѓу многу микросервиси на Avito:

• поделба на инфраструктурата во слоеви;
• Платформа како услуга (PaaS) концепт;
• следење на се што се случува со микросервисите.

Слоевите за апстракција на инфраструктурата вклучуваат три слоја. Ајде да одиме од врвот до дното.

A. Топ - сервисна мрежа. Отпрвин го пробавме Istio, но се покажа дека користи премногу ресурси, што е прескапо за нашите томови. Затоа, високиот инженер во архитектонскиот тим Александар Лукјанченко разви свое решение - Нетрамеш (достапен во Open Source), кој моментално го користиме во производството и кој троши неколку пати помалку ресурси од Istio (но не прави се со што може да се пофали Istio).
B. Медиум - Кубернетес. Ние распоредуваме и работиме со микросервиси на него.
В. Дното - гол метал. Не користиме облаци или работи како OpenStack, туку целосно се потпираме на гол метал.

Сите слоеви се комбинирани со PaaS. И оваа платформа, пак, се состои од три дела.

I. Генератори, контролирана преку CLI алатка. Таа е таа што му помага на развивачот да создаде микросервис на вистински начин и со минимум напор.

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

III. Складирање. Се поврзува со распоредувачи кои автоматски поставуваат предизвикувачи за значајни дејства. Благодарение на таквиот систем, ниту една задача не се пропушта само затоа што некој заборавил да постави задача во Jira. За ова користиме внатрешна алатка наречена Атлас.

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

Како функционира стандардниот цевковод за развој на микросервис?

Во принцип, синџирот за создавање микросервис изгледа вака:

CLI-push → Континуирана интеграција → Печете → Распоредување → Вештачки тестови → Тестови со канари → Тестирање со стискање → Производство → Одржување.

Ајде да поминеме низ него токму по овој редослед.

CLI-притискање

• Креирање на микросервис.
Долго време се мачевме да го научиме секој развивач како да прави микросервис. Ова вклучуваше пишување детални инструкции во Confluence. Но, шемите се променија и беа дополнети. Резултатот е дека на почетокот на патувањето се појави тесно грло: беше потребно многу повеќе време за лансирање на микросервисите, а сепак често се појавуваа проблеми при нивното создавање.

На крајот, изградивме едноставна алатка CLI која ги автоматизира основните чекори при креирање на микросервис. Всушност, тоа го заменува првото притискање на git. Еве што точно прави таа.

— Создава услуга според шаблон — чекор по чекор, во режим „волшебник“. Имаме шаблони за главните програмски јазици во задниот дел на Avito: PHP, Golang и Python.

- Една по една команда распоредува средина за локален развој на одредена машина - Minikube се стартува, дијаграмите на Helm автоматски се генерираат и стартуваат во локалните kubernetes.

— Ја поврзува потребната база на податоци. Програмерот не треба да ги знае IP, најавувањето и лозинката за да добие пристап до базата на податоци што му е потребна - било да е тоа локално, во Stage или во производство. Покрај тоа, базата на податоци се распоредува веднаш во конфигурација толерантна за грешки и со балансирање.

— Самиот прави склопување во живо. Да речеме дека некој развивач коригирал нешто во микросервис преку неговиот IDE. Алатката ги гледа промените во датотечниот систем и, врз основа на нив, ја обновува апликацијата (за Golang) и се рестартира. За PHP, ние едноставно го препраќаме директориумот внатре во коцката и таму „автоматски“ се добива повторно вчитување во живо.

— Генерира автоматски тестови. Во форма на празни места, но сосема погодни за употреба.

• Распоредување на микросервис.

Распоредувањето на микросервис порано ни беше малку скучна работа. Се бараше следново:

I. Dockerfile.

II. Конфигурација.
III. Табела на кормила, која сама по себе е гломазна и вклучува:

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

Ја отстранивме болката од преработката на манифестациите на Кубернет, па тие сега се генерираат автоматски. Но, што е најважно, тие го поедноставија распоредувањето до крај. Отсега па натаму имаме Dockerfile, а развивачот ја запишува целата конфигурација во една кратка датотека app.toml.

Да, и во самиот app.toml нема што да се прави ниту една минута. Назначуваме каде и колку копии од услугата да се подигнат (на серверот на dev, при поставување, во производство) и укажуваме на нејзините зависности. Забележете ја големината на линијата = "мала" во блокот [мотор]. Ова е лимитот што ќе биде доделен на услугата преку Kubernetes.

Потоа, врз основа на конфигурацијата, автоматски се генерираат сите потребни дијаграми на Helm и се креираат врски со базите на податоци.

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

• Подготовка на документација.
Сè уште проблематична област. Се чини дека е најочигледно, но во исто време е и рекорд „често заборавен“, а со тоа и ранлива алка во синџирот.
Неопходно е да има документација за секој микросервис. Ги вклучува следните блокови.

I. Краток опис на услугата. Буквално неколку реченици за тоа што прави и зошто е потребно.

II. Врска за архитектонски дијаграм. Важно е со брз поглед да може лесно да се разбере, на пример, дали користите Redis за кеширање или како главна продавница за податоци во постојан режим. Во Avito засега ова е врска до Confluence.

III. Runbook. Краток водич за започнување на услугата и сложеноста на ракување со неа.

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

V. Опис на крајните точки за API. Ако одеднаш не ги наведовте дестинациите, колегите чии микроуслуги се поврзани со вашите речиси сигурно ќе платат за тоа. Сега го користиме Swagger и нашето решение наречено кратко за ова.

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

VII. Сопственик или сопственици на услугата. Во повеќето случаи, тоа - или тие - може да се одредат автоматски со помош на PaaS, но за да бидеме на безбедна страна, бараме од развивачот рачно да ги специфицира.

Конечно, добра практика е да се прегледа документацијата, слично на прегледот на кодот.

Континуирана интеграција

• Подготовка на складишта.
• Креирање на гасовод во TeamCity.
• Поставување права.
• Пребарајте сопственици на услуги. Овде има хибридна шема - рачно обележување и минимална автоматизација од PaaS. Целосно автоматската шема не успева кога услугите се префрлаат за поддршка на друг тим за развој или, на пример, ако развивачот на услугата се откаже.
• Регистрирање услуга во Атлас (Види погоре). Со сите свои сопственици и зависности.
• Проверка на миграции. Проверуваме дали некој од нив е потенцијално опасен. На пример, во една од нив се појавува алтер табела или нешто друго што може да ја прекине компатибилноста на шемата за податоци помеѓу различни верзии на услугата. Тогаш миграцијата не се врши, туку се става во претплата - PaaS мора да му сигнализира на сопственикот на услугата кога е безбедно да ја користи.

Печете

Следната фаза се услугите за пакување пред распоредувањето.

• Градење на апликацијата. Според класиците - во слика на Докер.
• Генерирање на табели на Helm за самата услуга и сродни ресурси. Вклучувајќи и за бази на податоци и кеш. Тие се креираат автоматски во согласност со конфигурацијата app.toml што беше генерирана во фазата CLI-push.
• Креирање билети за администратори за отворање на пристаништа (кога е потребно).
• Извршување на тестови на единицата и пресметување на покриеноста на кодот. Ако покриеноста на кодот е под наведениот праг, тогаш најверојатно услугата нема да оди понатаму - до распоредување. Ако е на работ на прифатливо, тогаш на услугата ќе и биде доделен коефициент „песимизирачки“: тогаш, ако нема подобрување на индикаторот со текот на времето, развивачот ќе добие известување дека нема напредок во однос на тестовите ( и нешто треба да се преземе во врска со тоа).
• Сметководство за ограничувањата на меморијата и процесорот. Ние главно пишуваме микроуслуги во Голанг и ги извршуваме во Кубернетес. Оттука една суптилност поврзана со особеноста на јазикот Голанг: стандардно, при стартување, се користат сите јадра на машината, ако експлицитно не ја поставите променливата GOMAXPROCS и кога ќе се стартуваат неколку такви услуги на истата машина, тие започнуваат да се натпреваруваат за ресурси, мешајќи се едни со други. Графиконите подолу покажуваат како времето на извршување се менува ако ја стартувате апликацијата без спор и во режим на трка за ресурси. (Изворите на графиконите се тука).

Време на извршување, помалку е подобро. Максимална: 643 ms, минимум: 42 ms. Фотографијата може да се кликне.

Време е за операција, помалку е подобро. Максимум: 14091 ns, минимум: 151 ns. Фотографијата може да се кликне.

Во фазата на подготовка на склопување, можете експлицитно да ја поставите оваа променлива или можете да ја користите библиотеката automaxprocs од момците од Uber.

Распоредување

• Проверка на конвенциите. Пред да започнете со испорака на сервисни склопови до вашите наменети опкружувања, треба да го проверите следново:
- Крајни точки на API.
— Усогласеност на одговорите на крајните точки на API со шемата.
- Формат на дневник.
— Поставување заглавија за барања до услугата (во моментов тоа го прави нетрамеш)
— Поставување на сопственикот токен при испраќање пораки до автобусот на настани. Ова е потребно за да се следи поврзаноста на услугите низ автобусот. Можете да испратите и идемпотентни податоци во автобусот, што не ја зголемува поврзаноста на услугите (што е добро), и деловни податоци што ја зајакнуваат поврзаноста на услугите (што е многу лошо!). И во моментот кога ова поврзување станува проблем, разбирањето кој пишува и чита автобус помага правилно да се одделат услугите.

Сè уште нема многу конвенции во Авито, но нивниот базен се шири. Колку повеќе такви договори се достапни во форма што тимот може да ја разбере и разбере, толку полесно е да се одржи доследноста помеѓу микросервисите.

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

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

• Тестирање на стрес. Се трудиме да ги доведеме сите услуги до оптимални перформанси. И сите верзии на секоја услуга мора да бидат предмет на тестирање на оптоварување - на овој начин можеме да ги разбереме моменталните перформанси на услугата и разликата со претходните верзии на истата услуга. Ако, по ажурирањето на услугата, неговите перформанси се намалија за еден и пол пати, ова е јасен сигнал за неговите сопственици: треба да копате во кодот и да ја поправите ситуацијата.
Ние ги користиме собраните податоци, на пример, за правилно спроведување на автоматското скалирање и, на крајот, генерално да разбереме колку услугата е скалабилна.

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

а) Го гледаме вкупниот товар.
- Премалку - најверојатно нешто воопшто не функционира ако товарот наеднаш падне неколку пати.
- Премногу голем - потребна е оптимизација.

б) Го гледаме прекинот според RPS.
Овде ја гледаме разликата помеѓу тековната верзија и претходната и вкупната количина. На пример, ако услугата произведува 100 вртежи во секунда, тогаш таа е или лошо напишана, или ова е нејзината специфичност, но во секој случај, ова е причина да се погледне услугата многу внимателно.
Ако, напротив, има премногу RPS, тогаш можеби има некој вид грешка и некои од крајните точки престанале да го извршуваат товарот, а некои други едноставно се активираат return true;

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

Откако ќе ги поминеме синтетичките тестови, микросервисот го тестираме на мал број корисници. Почнуваме внимателно, со мал дел од наменетата публика на услугата - помалку од 0,1%. Во оваа фаза, многу е важно во мониторингот да бидат вклучени точните технички и производни метрики за да го покажат проблемот во сервисот што е можно побрзо. Минималното време за тест за канаринци е 5 минути, главниот е 2 часа. За сложени услуги, времето го поставуваме рачно.
Ајде да анализираме:
— метрика специфични за јазикот, особено работници php-fpm;
— грешки во Sentry;
— статуси на одговор;
— време на одговор, точно и просечно;
- латентност;
— исклучоци, обработени и неракувани;
- метрика на производот.

Тестирање со стискање

Тестирањето со стискање се нарекува и тестирање за „стискање“. Името на техниката беше воведено во Нетфликс. Нејзината суштина е дека прво пополнуваме еден пример со реален сообраќај до точка на неуспех и на тој начин ја поставуваме неговата граница. Потоа додаваме уште еден примерок и го вчитуваме овој пар - повторно до максимум; го гледаме нивниот таван и делта со првото „стискање“. И така, поврзуваме еден по еден пример и ја пресметуваме шемата на промени.
Податоците од тестот преку „стискање“ исто така се влеваат во заедничката база на податоци за метрика, каде што или ги збогатуваме резултатите од вештачкото оптоварување со нив, или дури и ги заменуваме „синтетичките“ со нив.

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

• Скалирање. Кога нудиме услуга за производство, следиме како таа се зголемува. Според нашето искуство, следењето само индикатори на процесорот е неефикасно. Автоматското скалирање со RPS бенчмаркинг во неговата чиста форма функционира, но само за одредени услуги, како што е онлајн стриминг. Значи, прво гледаме на метрика на производи специфични за апликацијата.

Како резултат на тоа, при скалирање анализираме:
- Индикатори на процесорот и RAM меморијата,
— бројот на барања во редот,
- време на одговор,
— прогноза врз основа на акумулирани историски податоци.

При скалирање на услугата, исто така е важно да се следат нејзините зависности за да не ја зголемиме првата услуга во синџирот, а оние до кои пристапува не успеваат под оптоварување. За да се воспостави прифатливо оптоварување за целиот збир на услуги, ги разгледуваме историските податоци на „најблиската“ зависна услуга (врз основа на комбинација на индикатори на процесорот и RAM меморијата, заедно со метрика специфични за апликација) и ги споредуваме со историските податоци на услугата за иницијализирање, и така натаму низ „синџирот на зависност“ “, од врвот до дното.

Услуга

Откако ќе се стави во функција микросервисот, можеме да прикачиме тригери на него.

Еве типични ситуации во кои се јавуваат предизвикувачи.
— Откриени потенцијално опасни миграции.
— Објавени се безбедносни ажурирања.
— Самата услуга не е ажурирана долго време.
— Оптоварувањето на услугата е значително намалено или некои од нејзините показатели за производи се надвор од нормалниот опсег.
— Услугата повеќе не ги исполнува барањата на новата платформа.

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

Контролна табла

Накратко, контролната табла е контролната табла на целиот наш PaaS.

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

Во вкупен

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

Дадов извештај на оваа тема за HighLoad++ 2018, можете да го погледнете видео и презентација.

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

Ние во Avito организираме интерна тридневна обука за програмери од Крис Ричардсон, експерт за микросервис архитектура. Би сакале да му дадеме можност да учествува во него на еден од читателите на овој пост. Тука Програмата за обука е објавена.

Обуката ќе се одржи од 5 до 7 август во Москва. Ова се работни денови кои ќе бидат целосно окупирани. Ручекот и обуката ќе бидат во нашата канцеларија, а избраниот учесник сам ќе си ги плати патувањето и сместувањето.

Можете да аплицирате за учество во оваа форма на Google. Од вас - одговор на прашањето зошто треба да присуствувате на обуката и информации како да ве контактираме. Одговорете на англиски, бидејќи Крис сам ќе го избере учесникот кој ќе присуствува на обуката.
Ќе го објавиме името на учесникот на обуката во ажурирање на оваа објава и на социјалните мрежи Avito за програмери (AvitoTech во Фејсбук, Vkontakte, Твитер) најдоцна до 19 јули.

Извор: www.habr.com