Микроуслуги: Размерът има значение, дори ако имате Kubernetes

19 септември в Москва се състоя първата тематична среща HUG (Highload++ User Group), която беше посветена на микроуслугите. Имаше презентация „Опериране на микроуслуги: размерът има значение, дори ако имате Kubernetes“, в която споделихме богатия опит на Flant в управлението на проекти с микроуслугна архитектура. На първо място, ще бъде полезно за всички разработчици, които обмислят да използват този подход в техния настоящ или бъдещ проект.

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

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

въведение

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

Ще започна с тази графика, чийто автор (през 2015 г.) е Мартин Фаулър:

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

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

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

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

Полезни и вредни микроуслуги

А ето и основната идея:

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

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

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

Защо микроуслуги?

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

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

Говорих много със софтуерни архитекти и разработчици и ги питах защо се нуждаят от микроуслуги. И направих списък с техните очаквания. Ето какво се случи:

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

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

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

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

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

Поради комбинация от причини тези микроуслуги са написани на различни платформи:

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

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

Фаулър също има това има статия — относно „заплащането“ за използване на микроуслуги:

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

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

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

Има модел "голяма буца мръсотия“, а тук се оказа разпределена буца пръст. За да потвърдите това, ето приблизителна илюстрация на това как вървят заявките:

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

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

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

Тя е. Само не забравяйте, че свободата често граничи с беззаконие. Тук е много важно да не избираме технологии само за да си „играем“ с тях.

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

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

Какво ще кажете за разполагането на всичко това локално?.. Оказва се, че често разработчикът върши работата си независимо, но „на случаен принцип“, защото е принуден да чака, докато веригата е свободна за тестване.

Отделно мащабиране...

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

Бопо-голяма надеждност...

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

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

Това е наистина добро.

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

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

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

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

Защото:

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

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

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

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

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

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

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

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

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

Комбинирайте всички микроуслуги, отговорни за генерирането на интерфейса:

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

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

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

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

Обобщавайки

Вижте по-голямата картина. Много често всички тези проблеми с микроуслугите възникват, защото някой е поел задачата им, но иска да „играе с микроуслуги“.

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

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

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

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

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

Представяне на доклада:

PS

Други доклади в нашия блог:

• «Мониторинг и Kubernetes» (Дмитрий Столяров; 28 май 2018 г. в RootConf);
• «Най-добри практики за CI/CD с Kubernetes и GitLab» (Дмитрий Столяров; 7 ноември 2017 г. в HighLoad++);
• «Нашият опит с Kubernetes в малки проекти» (Дмитрий Столяров; 6 юни 2017 г. в RootConf);
• «Създаваме Docker изображения за CI/CD бързо и удобно с dapp» (Дмитрий Столяров; 8 ноември 2016 г. в HighLoad++);
• «Практики за непрекъсната доставка с Docker» (Дмитрий Столяров; 31 май 2016 г. в RootConf).

Може да се интересувате и от следните публикации:

• «Смъртта на лудостта на микросервизите през 2018 г»;
• «7-те най-добри практики за контейнери на Google»;
• «Статистика от The New Stack за предизвикателствата при прилагането на Kubernetes".

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