🥇Микросервизи: размерът има значение, дори и да имате Kubernetes

19 септември в Москва се състоя първият тематичен митап HUG (Highload++ User Group), посветен на микросервисите. На него беше представен докладът «Експлоатация на микросервизите: размерът има значение, дори да имате Kubernetes», в който споделихме обширния опит на компания «Флант» в областта на експлоатацията на проекти с микросервисна архитектура. Той ще бъде особено полезен за всички разработчици, които обмислят прилагането на този подход в настоящия или бъдещия си проект.

Представяме видео с доклада (50 минути, много по-информативно от статията), както и основната му същност в текстов вид.

NB: Видео и презентация са достъпни също и в края на тази публикация.

Въведение

Обикновено една добра история има завръзка, основен сюжет и развръзка. Този доклад по-скоро наподобява завръзка, и то трагична. Също така е важно да се отбележи, че представя поглед върху микросервизите от страна на експлоатацията.

Започвам с такава графика, чийто автор е (през 2015 година) стана Martin Fowler:

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

Ще допълня този график за случая с използване на Kubernetes:

Защо приложението с микросервизите стана по-добро? Защото такава архитектура поставя сериозни изисквания за архитектурата, които отлично се покриват от възможностите на Kubernetes. От друга страна, част от тази функционалност ще бъде полезна и за монолита, особено поради факта, че типичният днешен монолит не е напълно монолитен (подробности ще има по-долу в доклада).

Както личи, крайният график (когато и монолитните, и микросервисните приложения в инфраструктура с Kubernetes) не се различава много от първоначалния. По-нататък ще говорим за приложения, експлоатирани с помощта на Kubernetes.

Полезността и вредата от микросервисите

И тук главната мисъл:

Какво представлява нормалната микросервисна архитектура? Тя трябва да ви носи реална полза, увеличавайки ефективността на работата. Ако се върнем към графика, то ето я:

Ако я наречем полезна, но на другата страна на графиката ще бъде вредна микросервизност (пречи на работата):

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

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

На въпроса за ползата от микросервисите има много конкретен отговор от вече споменатия Martin Fowler:

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

Разговарях много с архитекти и разработчици на софтуер и питах защо им трябват микросервизи. Съставих свой списък с техните очаквания. Ето какво получих:

Ако опиша „в усещанията“ някои от точките, то:

ясни граници на модулите: ето имаме страшен монолит, а сега всичко ще бъде акуратно разпределено по Git-репозиториите, в които всичко е „по рафтове“, не смесваме топло с меко;
независимост на внедряването: можем да внедряваме услугите независимо, за да се ускорят разработките (паралелно да публикуваме нови функции);
независимост на разработката: можем да дадем този микросервис на едно екип/разработчик, а онзи — на друг, благодарение на което можем да разработваме по-бързо;
бпо-по-голяма надеждност: ако се случи частична деградация (единичен микросервис да падне от 20), то само един бутон ще спре да работи, а системата като цяло ще продължи да функционира.

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

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

Пример за това ще бъде абстрактен интернет-магазин, който се опитва да конкурира с Amazon или поне с OZON. Микросервисната му архитектура изглежда така:

По съвкупност причини, тези микросервизи са написани на различни платформи:

Тъй като всеки микросервис трябва да бъде автономен, много от тях се нуждаят от свои собствени бази данни и кеш. Финалната архитектура изглежда по следния начин:

Какви са последиците?

При Fowler по този въпрос има статия — за "плащането" за използването на микросервизи:

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

Ясни граници на модулите…

Но колко микросервиза всъщност трябва да поправим, за да внедрим промяната? Можем ли изобщо да разберем как всичко работи без разпределен трасер (в крайна сметка всяка заявка се обработва от половината микросервизи)?

Съществува шаблон "голямо кълбо мръсотия", а тук всъщност се получи разпределено кълбо мръсотия. В потвърждение на това — ето приблизителна илюстрация на начина, по който минават заявките:

Независимост при внедряването…

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

Свобода на избора на технология…

Тя съществува. Но е важно да помним, че често свободата граничи с беззаконие. Много е важно да не избираме технологии само за да "играем" с тях.

Независимост при разработката…

Как да изградим тестов контур за цялото приложение (от толкова много компоненти)? Освен това, трябва да го поддържаме актуален. Всичко това води до факта, че реалното количество тестови контури, което можем да поддържаме, се оказва минимално..

А как да развием всичко това локално?.. Оказва се, че често разработчикът извършва работата си независимо, но "на сляпо", защото е принуден да чака, докато се освободи контур за тестване.

Разделно мащабиране…

Да, но то е ограничено в областта на използваните СУБД. В посочения пример архитектурата няма да има проблеми с Cassandra, но проблеми ще има с MySQL и PostgreSQL.

Бпо-ляща надеждност…

Не само, че на практика неизправността на един микросервис често нарушава правилното функциониране на цялата система, но има и нов проблем: да се направи отказоустойчив всеки микросервис е много трудно.Понеже в микроуслугите се използват различни технологии (memcache, Redis и т.н.), за всяка от тях трябва да се помисли и реализира, което, разбира се, е възможно, но изисква огромни ресурси.

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

С това наистина всичко е наред.

„Лекотата“ на микроуслугите...

У нас не само че се появиха огромни мрежови разходи (удвояват се заявките към DNS и т.н.), но и заради множеството подзаявки започнахме да репликираме данни (да съхраняваме кешове), което доведе до значителен обем на хранилищата.

И ето какъв е резултатът от съответствието с нашите очаквания:

Но това все още не е всичко!

Защото:

Вероятно ще ни е необходима шина съобщения.
Как да направим последователно резервно копие в нужния момент? Единственият реален вариант е да спрем трафика за това. Но как да го направим в продукция?
Ако става въпрос за поддръжка на няколко региона, организирането на устойчивост във всеки от тях е много трудоемка задача.
Появява се проблемът с въвеждането на централизирани промени. Например, ако трябва да обновим версията на PHP, ще се наложи да направим комит във всеки репозиторий (а те са десетки).
Ръстът на оперативната сложност изглежда експоненциален.

Какво да правим с всичко това?

Започнете с монолитно приложение. Опитът на Фаулър казва показва, че практически всички успешни микроуслуги са започнали с монолит, който е станал твърде голям, след което е бил разделен. В същото време почти всички системи, изградените като микроуслуги от самото начало, в рано или късно имат сериозни проблеми.

Още една ценна мисъл — за да бъде проект с микроуслужна архитектура успешен, нужно е да познавате много добре как темата, така и как да правите микроуслуги.Най-добрият начин да научите темата е да направите монолит.

Но какво да правим, ако вече сме в такава ситуация?

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

Ако в случая с разширяваща се монолитна структура (когато вече сме изчерпали възможността да добавяме ресурси за нея), ние я разделяме, то в този случай ситуацията е обратна: когато прекомерната микроуслужност вече не помага, а пречи — отрежете излишното и увеличете!

Например, за разгледания по-горе събирателен образ...

Отървете се от най-съмнителните микросервизи:

Обединете всички микросервизи, отговорни за генерирането на фронтенда:

… в един микросервиз, написан на един (съвременен и нормален, каквото смятате, че е) език/фреймворк:

Той ще има един ORM (една СУБД) и първоначално няколко приложения:

… всъщност там могат да се прехвърлят много повече, получавайки следния резултат:

Освен това в Kubernetes стартираме всичко това с отделни екземпляри, което означава, че все още можем да измерваме натоварването и отделно да ги мащабируем.

В обобщение

Погледнете на картината в по-широк контекст. Много често всички тези проблеми с микросервизите произлизат от това, че някой е взел задачата си, но е искал "да играе с микросервизи".

В думата "микросервизи" частта "микро" е излишна. Те са "микро" само защото са по-малки от огромния монолит. Но не трябва да се мисли за тях като за нещо малко.

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

Записаната бележка към нея (вдясно горе) се свежда до това, че уменията на екипа, който работи по вашия проект, винаги са на първо място — именно те ще играят ключова роля във вашия избор между микросервизи и монолит. Ако на екипа му липсват умения, но той започне да прави микросервизи, историята със сигурност ще бъде фатална.

Видео и слайдове

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