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

(И на крају овог чланка, говорићу о прилици да присуствујем тродневном семинару стручњака за микросервисну архитектуру Цхриса Рицхардсона).

Како смо дошли до микросервиса

Авито је један од највећих сајтова за мале рекламе на свету дневно. Наш бацкенд прихвата више од 15 хиљада захтева у секунди. Тренутно имамо неколико стотина микросервиса.

Ми већ неколико година градимо микросервисну архитектуру. Како тачно - наше колеге детаљно рекао на нашој секцији на РИТ++ 2017. На ЦодеФест-у 2017 (види. видео), Сергеј Орлов и Михаил Прокопчук су детаљно објаснили зашто нам је био потребан прелазак на микросервисе и какву је улогу ту одиграо Кубернетес. Па, сада чинимо све да минимизирамо трошкове скалирања који су својствени таквој архитектури.

У почетку нисмо направили екосистем који би нам свеобухватно помогао да развијемо и покренемо микросервисе. Једноставно су прикупили разумна решења отвореног кода, покренули их код куће и позвали програмера да се бави њима. Као резултат тога, отишао је на десетак места (контролне табле, интерни сервиси), након чега је ојачао у жељи да исече код на стари начин, у монолит. Зелена боја на дијаграмима испод означава шта програмер на овај или онај начин ради својим рукама, а жута означава аутоматизацију.

Сада у ПааС ЦЛИ услужном програму, нова услуга се креира са једном командом, а нова база података се додаје са још две и примењује на Стаге.

Како превазићи еру "фрагментације микросервиса"

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

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

• сеча;
• праћење захтева (Јаегер);
• агрегирање грешака (Сентри);
• статуси, поруке, догађаји из Кубернетес-а (Евент Стреам Процессинг);
• граница трке / прекидач (можете користити Хистрик);
• контрола повезивања сервиса (користимо Нетрамесх);
• мониторинг (Графана);
• монтажа (ТеамЦити);
• комуникација и обавештења (Слацк, емаил);
• праћење задатака; (Јира)
• припрема документације.

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

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

Следеће помаже у имплементацији јединствене „политике странке“ међу многим Авито микросервисима:

• подела инфраструктуре на слојеве;
• Концепт платформе као услуге (ПааС);
• праћење свега што се дешава са микросервисима.

Инфраструктурни апстракцијски слојеви обухватају три слоја. Идемо од врха до дна.

А. Врх - сервисна мрежа. Прво смо испробали Истио, али се показало да користи превише ресурса, што је прескупо за наше количине. Стога је виши инжењер у архитектонском тиму Александар Лукјанченко развио сопствено решење - Нетрамесх (доступно у Опен Соурце-у), који тренутно користимо у производњи и који троши неколико пута мање ресурса од Истио-а (али не ради све чиме се Истио може похвалити).
Б. Средњи - Кубернетес. Ми постављамо и управљамо микросервисима на њему.
Ц. Дно - голи метал. Не користимо облаке или ствари попут ОпенСтацк-а, већ се у потпуности ослањамо на голи метал.

Сви слојеви су комбиновани помоћу ПааС-а. А ова платформа се, заузврат, састоји од три дела.

И. Генератори, контролисан преко ЦЛИ услужног програма. Она је та која помаже програмеру да креира микросервис на прави начин и уз минималан напор.

ИИ. Консолидовани колектор са контролом свих алата преко заједничке контролне табле.

ИИИ. Складиште. Повезује се са планерима који аутоматски постављају окидаче за значајне радње. Захваљујући таквом систему, ни један задатак се не пропушта само зато што је неко заборавио да подеси задатак у Јира. За ово користимо интерни алат под називом Атлас.

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

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

Генерално, ланац креирања микросервиса изгледа овако:

ЦЛИ-пусх → Континуирана интеграција → Баке → Деплои → Вештачки тестови → Цанари тестови → Тестирање стискања → Производња → Одржавање.

Хајде да то прођемо управо овим редоследом.

ЦЛИ-пусх

• Креирање микросервиса.
Дуго смо се борили да научимо сваког програмера како да ради микросервисе. Ово је укључивало писање детаљних упутстава у Цонфлуенце. Али шеме су се мењале и допуњавале. Резултат тога је да се на почетку пута појавило уско грло: било је потребно много више времена за покретање микросервиса, а ипак су се често јављали проблеми током њиховог креирања.

На крају смо направили једноставан ЦЛИ услужни програм који аутоматизује основне кораке приликом креирања микросервиса. У ствари, замењује први гит пусх. Ево шта она тачно ради.

— Креира услугу према шаблону — корак по корак, у режиму „чаробњака“. Имамо шаблоне за главне програмске језике у Авито бацкенд-у: ПХП, Голанг и Питхон.

- Једна по једна команда поставља окружење за локални развој на одређеној машини - Миникубе се покреће, Хелм графикони се аутоматски генеришу и покрећу у локалном кубернетесу.

— Повезује потребну базу података. Програмер не мора да зна ИП адресу, логин и лозинку да би добио приступ бази података која му је потребна – било да је то локално, у фази или у производњи. Штавише, база података се одмах примењује у конфигурацији отпорној на грешке и са балансирањем.

— Изводи саму монтажу уживо. Рецимо да је програмер исправио нешто у микросервису преко свог ИДЕ-а. Услужни програм види промене у систему датотека и, на основу њих, поново гради апликацију (за Голанг) и поново покреће. За ПХП, једноставно прослеђујемо директоријум унутар коцке и тамо се поновно учитавање уживо добија „аутоматски“.

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

• Примена микросервиса.

Намештање микросервиса нам је некада представљало тежак посао. Било је потребно следеће:

И. Доцкерфиле.

ИИ. Цонфиг.
ИИИ. Табела кормила, која је сама по себи гломазна и укључује:

— саме карте;
— шаблони;
— специфичне вредности узимајући у обзир различита окружења.

Уклонили смо бол од прераде Кубернетес манифеста тако да се сада аутоматски генеришу. Али што је најважније, поједноставили су распоређивање до крајњих граница. Од сада имамо Доцкерфиле, а програмер записује целу конфигурацију у једну кратку апп.томл датотеку.

Да, и у самом апп.томл нема шта да се ради на минут. Наводимо где и колико копија сервиса треба да подигнемо (на дев серверу, у фази производње, у продукцији) и указујемо на његове зависности. Обратите пажњу на величину линије = "мала" у блоку [енгине]. Ово је ограничење које ће бити додељено услузи преко Кубернетеса.

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

• Основна валидација. Такве провере су такође аутоматизоване.
Потребно је пратити:
— постоји ли Доцкерфиле;
— постоји ли апп.томл;
— да ли постоји документација?
— да ли је зависност у реду?
— да ли су постављена правила упозорења.
До последње тачке: власник услуге сам одређује које метрике производа ће пратити.

• Припрема документације.
Још увек проблематично подручје. Чини се да је то најочигледније, али је истовремено и рекорд „често заборављен“, па самим тим и рањива карика у ланцу.
Неопходно је да постоји документација за сваки микросервис. Укључује следеће блокове.

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

ИИ. Веза за дијаграм архитектуре. Важно је да је брзим погледом на њега лако разумети, на пример, да ли користите Редис за кеширање или као главно складиште података у трајном режиму. У Авиту за сада ово је веза са Цонфлуенце.

ИИИ. Рунбоок. Кратак водич за покретање услуге и замршености руковања њом.

ИВ. ФАК, где би било добро да предвидите проблеме са којима се ваше колеге могу сусрести у раду са сервисом.

В. Опис крајњих тачака за АПИ. Ако одједном нисте навели дестинације, скоро сигурно ће то платити колеге чије су микросервисе везане за ваше. Сада користимо Сваггер и наше решење које се зове бриеф за ово.

ВИ. Етикете. Или маркери који показују ком производу, функционалности или структурној подели компаније услуга припада. Они вам помажу да брзо схватите, на пример, да ли смањујете функционалност коју су ваше колеге увеле за исту пословну јединицу пре недељу дана.

ВИИ. Власник или власници услуге. У већини случајева, он – или они – могу се аутоматски одредити помоћу ПааС-а, али да бисмо били сигурни, захтевамо од програмера да их наведе ручно.

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

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

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

Пеците

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

• Изградња апликације. Према класицима - у Доцкер слици.
• Генерисање Хелм графикона за саму услугу и повезане ресурсе. Укључујући базе података и кеш меморије. Они се креирају аутоматски у складу са апп.томл конфигурацијом која је генерисана у ЦЛИ-пусх фази.
• Креирање тикета за администраторе за отварање портова (када је то потребно).
• Извођење јединичних тестова и израчунавање покривености кода. Ако је покривеност кода испод наведеног прага, онда највероватније услуга неће ићи даље - до имплементације. Ако је на граници прихватљивог, сервису ће бити додељен коефицијент „песимизирања“: тада, ако током времена не дође до побољшања индикатора, програмер ће добити обавештење да нема напретка у погледу тестова ( и ту треба нешто да се уради).
• Обрачунавање ограничења меморије и процесора. Ми углавном пишемо микросервисе у Голангу и покрећемо их у Кубернетесу. Отуда једна суптилност повезана са особеношћу Голанг језика: подразумевано, при покретању, користе се сва језгра на машини, ако експлицитно не подесите променљиву ГОМАКСПРОЦС, а када се неколико таквих сервиса покрене на истој машини, они почињу да се такмиче за ресурсе, ометајући једни друге. Графикони испод показују како се мења време извршења ако покренете апликацију без сукоба иу режиму трке за ресурсе. (Извори графикона су овде).

Време извршења, мање је боље. Максимално: 643 мс, минимално: 42 мс. На слику се може кликнути.

Време је за операцију, мање је боље. Максимум: 14091 нс, минимум: 151 нс. На слику се може кликнути.

У фази припреме склопа, можете експлицитно поставити ову променљиву или можете користити библиотеку аутомакпроцс од момака из Убера.

Развити

• Провера конвенција. Пре него што почнете да испоручујете сервисне склопове у предвиђена окружења, морате да проверите следеће:
- АПИ крајње тачке.
— Усклађеност одговора крајњих тачака АПИ-ја са шемом.
— Формат дневника.
— Подешавање заглавља за захтеве ка сервису (тренутно то ради нетрамесх)
— Подешавање токена власника приликом слања порука на сабирницу догађаја. Ово је потребно за праћење повезаности услуга у аутобусу. На магистралу можете слати и идемпотентне податке који не повећавају повезаност услуга (што је добро), и пословне податке који јачају повезаност сервиса (што је веома лоше!). А у тренутку када ова повезаност постане проблем, разумевање ко пише и чита аутобус помаже да се услуге правилно одвоје.

У Авиту још нема много конвенција, али њихов фонд се шири. Што је више таквих споразума доступно у облику који тим може да разуме и разуме, лакше је одржавати доследност између микросервиса.

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

• Тестирање затворене петље. За ово сада користимо отворени код Ховерфли.ио. Прво, бележи стварно оптерећење услуге, а затим - само у затвореној петљи - емулира га.

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

Током тестирања оптерећења проверавамо да ли потрошња ресурса задовољава постављене границе. И фокусирамо се првенствено на екстреме.

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

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

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

Након што прођемо синтетичке тестове, тестирамо микросервис на малом броју корисника. Почињемо пажљиво, са малим уделом намењене публике услуге - мање од 0,1%. У овој фази, веома је важно да исправне техничке и производне метрике буду укључене у праћење како би што брже показале проблем у сервису. Минимално време за тест канаринаца је 5 минута, главно 2 сата. За сложене услуге време постављамо ручно.
Анализирамо:
— метрике специфичне за језик, посебно, пхп-фпм радници;
— грешке у Сентрију;
— статуси одговора;
— време одговора, тачно и просечно;
- латентност;
— изузеци, обрађени и необрађени;
— метрике производа.

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

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

Производња

• Скалирање. Када уведемо услугу у производњу, пратимо како се она повећава. Према нашем искуству, праћење само ЦПУ индикатора је неефикасно. Аутоматско скалирање са РПС бенцхмаркингом у свом чистом облику ради, али само за одређене услуге, као што је онлајн стриминг. Дакле, прво гледамо метрике производа специфичне за апликацију.

Као резултат тога, приликом скалирања анализирамо:
- ЦПУ и РАМ индикатори,
— број захтева у реду,
- Време одзива,
— прогноза на основу акумулираних историјских података.

Приликом скалирања услуге, такође је важно пратити њене зависности како не бисмо скалирали прву услугу у ланцу, а они којима приступа не би успели под оптерећењем. Да бисмо успоставили прихватљиво оптерећење за цео скуп услуга, гледамо историјске податке „најближе“ зависне услуге (засноване на комбинацији ЦПУ и РАМ индикатора, заједно са метрикама специфичним за апликацију) и упоређујемо их са историјским подацима услуге иницијализације, и тако даље кроз „ланац зависности““, од врха до дна.

Сервис

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

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

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

Командна табла

Укратко, контролна табла је контролна табла целог нашег ПааС-а.

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

Укупно

Пре увођења ПааС-а, нови програмер би могао да проведе неколико недеља разумевајући све алате неопходне за покретање микросервиса у производњи: Кубернетес, Хелм, наше интерне ТеамЦити функције, подешавање конекција са базама података и кеш меморија на начин отпоран на грешке, итд. потребно је неколико сати да прочитате брзи почетак и креирате саму услугу.

Дао сам извештај на ову тему за ХигхЛоад++ 2018, можете га погледати видео и презентација.

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

Ми у Авито-у организујемо интерну тродневну обуку за програмере из Цхрис Рицхардсон, стручњак за микросервисну архитектуру. Желимо да пружимо прилику да учествујемо у њему неком од читалаца овог поста. Овде Програм обуке је објављен.

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

Можете се пријавити за учешће у овом Гоогле облику. Од вас – одговор на питање зашто је потребно да похађате обуку и информације како да вас контактирамо. Одговорите на енглеском, јер ће Крис сам изабрати учесника који ће похађати обуку.
Име учесника обуке ћемо објавити у ажурирању ове објаве и на друштвеним мрежама Авито за програмере (АвитоТецх у Фацебоок, Вконтакте, Твиттер) најкасније до 19. јула.

Извор: ввв.хабр.цом