Здравей, Хабр. В момента в OTUS е открит набор за нов поток на курса . Преди старта на курса искам да споделя с вас моя авторска статия.
Въведение
Изборът на архитектурен стил е едно от основополагающите технически решения при изграждането на информационна система. В тази серия статии предлагам да разгледаме най-популярните архитектурни стилове за изграждане на приложения и да отговорим на въпроса кога кой архитектурен стил е най-предпочитан. В процеса на изложението ще се опитам да проведа логическа връзка, която обяснява развитието на архитектурните стилове от монолитите до микросервисите.
Малко история
Ако се опитате да зададете на разработчиците въпроса: «Защо са нужни микросервизите?», ще получите най-различни отговори. Ще чуете, че микросервисите подобряват мащабирането, улесняват разбирането на кода, подобряват устойчивостта на отказ, понякога можете да чуете, че те позволяват „да се очисти кодът“. Нека се върнем в историята, за да разберем каква цел е имало появата на микросервизите.
Ако говорим накратко, микросервисите в нашето съвремие възникнаха по следния начин: през 2011 година Джеймс Люис, анализирайки работата на различни компании, обърна внимание на появата на новия патърн „micro-app“, който оптимизира SOA по отношение на ускоряване на развертыването на услугите. Няколко години по-късно, през 2012 година, на архитектурния саммит, патърнът беше преименуван на микросервиз. Така, първоначалната цел на внедряването на микросервизите беше подобряване на прословутия time to market.
На „вълната на хипа“ микросервисите бяха през 2015 година. Според някои изследвания, нито една конференция не минаваше без доклад по темата на микросервисите. Повече от това, някои конференции бяха посветени единствено на микросервисите. Сега много проекти започват с прилагането на този архитектурен стил, а ако проектът съдържа тонове наследствен код, със сигурност активно се осъществява миграция към микросервизи.
Въпреки всичко казано дотук, до момента все още сравнително малко разработчици могат да определят понятието „микросервиз“. Но за това ще поговорим малко по-късно...
Монолит
Архитектурният стил, противопоставян на микросервисния, е монолит (или „всичко в едно“). Какво е монолитът, вероятно няма смисъл да разказвам, затова веднага ще изредя недостатъците на този архитектурен стил, които иницираха по-нататъшното развитие на архитектурните стилове: размер, свързаност, развертыване, мащабируемост, надеждност и инерция. По-долу предлагам да се запознаем с всеки от недостатъците поотделно.
Размер
Монолитът е много голям. Той комуникира обикновено с много голяма база данни. Приложението става твърде голямо, за да може един разработчик да го разбере изцяло. Само тези, които са прекарали достатъчно време с този код, могат да работят добре с монолита, докато новаците ще похарчат много време в опити да разберат монолита и не е сигурно, че ще успеят. Обикновено, когато работите с монолит, винаги има някакъв „условен“ senior, който познава монолита повече или по-малко добре и
Свързаност
Монолитът представлява "голямо кълбо мръсотия" (big ball of mud), промените в който могат да доведат до непредсказуеми последици. Внедрявайки промени на едно място, можете да повредите монолита на друго (това е същото "почесал съм ухото и *@ се е откъснало"). Това е свързано с факта, че компонентите в монолита имат много сложни и, най-вече, неочевидни взаимовръзки.
Разгръщане
Разгръщането на монолита поради сложните взаимовръзки между неговите компоненти е дълъг процес с определен ритуал. Този ритуал обикновено не е окончателно стандартизиран и се предава "от уста на уста".
Мащабируемост
Модулите на монолита могат да имат конфликтни потребности от ресурси, поради което е необходимо да се търси компромис от гледна точка на хардуера. Представете си, че монолитът се състои от услуги A и B. Услуга A е взискателна към размера на твърдия диск, а услуга B — към оперативната памет. В такъв случай, или машината, на която се инсталира монолитът, трябва да поддържа изискванията на двете услуги, или ще трябва ръчно да се изключи една от услугите.
Още един пример (по-класически): услуга A е много по-популярна от услуга B, затова искате услугите A да са 100, а услугите B — 10. Отново, два варианта: или разгръщате 100 пълноценни монолита, или на някои от тях ръчно ще трябва да изключите услугите B.
Надеждност
Тъй като всичките услуги са събрани заедно, ако монолитът падне, всички услуги ще паднат едновременно. Наистина, може би това не е толкова лошо, поне няма да има частични откази в разпределената система, но от друга страна, поради грешка в функционалността, която използват 0.001% от потребителите, можете да загубите всички потребители на вашата система.
Стегнатост
Поради размера на монолита е трудно да се премине към нови технологии. В резултат, задача става задържането на същия условен senior. Избраният в началото на проекта технологичен стек може да стане бариера, препятстваща развитието на продукта.
Заключение
Следващия път ще говорим за това, как хората опитаха да решат обозначените проблеми, преминавайки към компоненти и SOA.
Прочетете още:
Източник: habr.com
