🥇Микроуслуге: величина је битна, чак и ако имате Кубернетес

19. септембра у Москви одржан први тематски састанак ХУГ (Хигхлоад++ Усер Гроуп), који је био посвећен микросервисима. Одржана је презентација „Управљање микросервисима: величина је битна, чак и ако имате Кубернетес“, у којој смо поделили Флантово велико искуство у управљању пројектима са микросервисном архитектуром. Пре свега, биће корисно за све програмере који размишљају о употреби овог приступа у свом садашњем или будућем пројекту.

Представљамо видео извештаја (50 минута, много информативније од чланка), као и главни извод из њега у текстуалном облику.

Напомена: Видео и презентација су такође доступни на крају овог поста.

Увод

Обично добра прича има почетак, главни заплет и решење. Овај извештај више личи на увод, и то трагичан. Такође је важно напоменути да пружа поглед са стране на микроуслуге. eksploatacije.

Почећу са овим графиконом, чији је аутор (2015.) постало Мартин Фаулер:

Показује како, у случају монолитне апликације која достиже одређену вредност, продуктивност почиње да опада. Микросервисе се разликују по томе што је почетна продуктивност код њих нижа, али како се комплексност повећава, деградација ефикасности за њих није толико приметна.

Додаћу овом графикону за случај коришћења Кубернетес-а:

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

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

Корисни и штетни микросервис

А ево главне идеје:

šta је нормално микросервисна архитектура? Требало би да вам донесе стварне користи, повећавајући вашу радну ефикасност. Ако се вратимо на графикон, ево га:

Ако је позовеш корисним, онда ће на другој страни графикона бити штетно микросервис (омета рад):

Да се вратим на „главну идеју“: да ли уопште треба да верујем свом искуству? Од почетка ове године сам погледао 85 пројеката. Нису сви били микросервис (отприлике трећина до половина њих је имала такву архитектуру), али то је ипак велики број. Ми (компанија Флант) као аутсорци успевамо да видимо широк спектар апликација развијених како у малим компанијама (са 5 програмера), тако иу великим (~500 програмера). Додатна предност је што ове апликације видимо како живе и еволуирају током година.

Зашто микросервис?

На питање о предностима микросервиса постоји врло конкретан одговор од већ поменутог Мартина Фаулера:

јасне границе модуларности;
независно распоређивање;
слобода избора технологија.

Много сам разговарао са софтверским архитектама и програмерима и питао зашто су им потребне микросервисе. И направио сам своју листу њихових очекивања. Ево шта се десило:

Ако неке од тачака опишемо „у сензацијама“, онда:

јасне границе модула: овде имамо ужасан монолит, а сада ће све бити уредно распоређено у Гит репозиторијумима, у којима је све „на полицама“, топло и меко се не мешају;
независност примене: моћи ћемо да уведемо услуге независно како би развој ишао брже (упоредо објављивати нове функције);
развојна независност: овај микросервис можемо дати једном тиму/програмеру, а један другом, захваљујући чему можемо брже да се развијамо;
бовећа поузданост: ако дође до делимичне деградације (један микросервис од 20 падне), онда ће само једно дугме престати да ради, а систем као целина ће наставити да функционише.

Типична (штетна) архитектура микросервиса

Да објасним зашто стварност није оно што очекујемо, представићу колективне слика микросервисне архитектуре заснована на искуству из многих различитих пројеката.

Пример би била апстрактна онлајн продавница која ће се такмичити са Амазоном или барем ОЗОН-ом. Његова микросервисна архитектура изгледа овако:

Из комбинације разлога, ове микросервисе су написане на различитим платформама:

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

Које су његове последице?

Фовлер има и ово постоји чланак — о „плаћању“ за коришћење микроуслуга:

А видећемо да ли су наша очекивања испуњена.

Јасне границе модула...

Али колико микросервиса заправо треба да поправимо?да уведемо промену? Можемо ли уопште да схватимо како све функционише без дистрибуираног трагача (на крају крајева, сваки захтев обрађује половина микросервиса)?

Постоји образац "велика груда прљавштине“, а овде се испоставило да је то распрострањена груда прљавштине. Да бисте то потврдили, ево приближне илустрације како се захтеви одвијају:

Независност примене...

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

Слобода избора технологије...

Она је. Само запамтите да се слобода често граничи са безакоњем. Овде је веома важно да не бирате технологије само да бисте се „играли“ са њима.

Независност развоја...

Како направити пробну петљу за целу апликацију (са толико компоненти)? Али и даље морате да га ажурирате. Све ово доводи до тога да стварни број испитних кола, које у принципу можемо садржати, испоставља се минималним.

Шта кажете на то да све ово примените локално?.. Испоставило се да често програмер ради свој посао независно, али „насумично“, јер је приморан да чека док се коло не ослободи за тестирање.

Одвојено скалирање...

Да, али је ограничен у области ДБМС-а који се користи. У датом примеру архитектуре, Цассандра неће имати проблема, али ће МиСКЛ и ПостгреСКЛ.

Бовећа поузданост...

Не само да квар једног микросервиса у стварности често нарушава исправно функционисање целог система, већ постоји и нови проблем: учинити сваку микросервис толерантном на грешке је веома тешко. Пошто микросервис користе различите технологије (мемцацхе, Редис, итд.), за сваку морате све размислити и имплементирати, што је, наравно, могуће, али захтева огромне ресурсе.

Мерљивост оптерећења...

Ово је стварно добро.

"Лакоћа" микросервиса...

Не само да имамо огромне мрежни трошкови (захтеви за ДНС се множе итд.), али и због многих подупита које смо започели реплицирати податке (кеш меморије продавнице), што је довело до значајне количине складиштења.

А ево и резултата испуњавања наших очекивања:

Али то није све!

Јер:

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

Шта са свим овим?

Почните са монолитном апликацијом. Фаулерово искуство govori да су скоро све успешне микросервисне апликације почеле као монолит који је постао превелик и потом покварен. Истовремено, скоро сви системи изграђени као микросервис од самог почетка су пре или касније наишли на озбиљне проблеме.

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

Али шта ако смо већ у овој ситуацији?

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

Ако, у случају зараслог монолита (када смо остали без могућности да за њега набавимо додатне ресурсе), исечемо га, онда се у овом случају испоставља супротна прича: када прекомерни микросервис више не помаже, већ омета – одрежите вишак и увећајте!

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

Ослободите се најсумњивијих микроуслуга:

Комбинујте све микросервисе одговорне за генерисање фронтенда:

... у један микросервис, написан на једном (савременом и нормалном, како и сами мислите) језику/оквиру:

Имаће један ОРМ (један ДБМС) и прво неколико апликација:

... али генерално тамо можете пренети много више, добијајући следећи резултат:

Штавише, у Кубернетес-у све ово покрећемо у одвојеним инстанцама, што значи да и даље можемо да меримо оптерећење и да их скалирамо засебно.

Резимирајући

Погледајте ширу слику. Врло често, сви ови проблеми са микросервисима настају зато што је неко преузео њихов задатак, али је желео да се „игра са микросервисима“.

У речи „микроуслуге“ део „микро“ је сувишан.. Они су „микро“ само зато што су мањи од огромног монолита. Али немојте их сматрати нечим малим.

И за крајњу мисао, вратимо се оригиналном графикону:

На њему исписана белешка (Горе десно) своди на то да вештине тима који прави ваш пројекат су увек примарне — они ће играти кључну улогу у вашем избору између микросервиса и монолита. Ако тим нема довољно вештина, али крене да прави микросервисе, прича ће свакако бити фатална.

Видео снимци и слајдови

Видео са говора (~50 минута; нажалост, не преноси бројне емоције посетилаца, које су у великој мери одредиле расположење извештаја, али тако је):

Презентација извештаја:

ПС

Остали извештаји на нашем блогу:

«Мониторинг и Кубернетес» (Дмитриј Стољаров; 28. мај 2018. на РоотЦонф-у);
«Најбоље праксе за ЦИ/ЦД са Кубернетес-ом и ГитЛабом» (Дмитриј Стољаров; 7. новембар 2017. на ХигхЛоад++);
«Наше искуство са Кубернетес-ом у малим пројектима» (Дмитриј Стољаров; 6. јун 2017. на РоотЦонф-у);
«Ми правимо Доцкер слике за ЦИ/ЦД брзо и практично помоћу дапп-а» (Дмитриј Стољаров; 8. новембар 2016. на ХигхЛоад++);
«Праксе континуиране испоруке са Доцкер-ом» (Дмитриј Стољаров; 31. мај 2016. на РоотЦонф-у).

Можда ће вас занимати и следеће публикације:

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

Микроуслуге: Величина је важна, чак и ако имате Кубернетес