Привіт, хабр. Прямо зараз у OTUS відкрито набір на новий потік курсу . Напередодні старту курсу хочу поділитись з вами своєю авторською статтею.
Запровадження
Вибір архітектурного стилю є одним із основних технічних рішень при побудові інформаційної системи. У цій серії статей я пропоную розібрати найпопулярніші архітектурні стилі побудови додатків і відповісти на питання коли який архітектурний стиль є найкращим. У процесі викладу я намагатимуся провести логічний ланцюжок, який пояснює розвиток архітектурних стилів від монолітів до мікросервісів.
Трохи історії
Якщо ви спробуєте поставити запитання розробникам: «Навіщо потрібні мікросервіси?», то ви отримаєте різні відповіді. Ви почуєте, що мікросервіси покращують масштабування, спрощують розуміння коду, покращують стійкість до відмов, іноді можна почути, що вони дозволяють «очистити код». Давайте звернемося до історії, щоб зрозуміти, яку мету наслідувала поява мікросервісів.
Якщо говорити коротко, то мікросервіси в нашому поточному розумінні виникли так: у 2011 році Джеймс Льюїс, аналізуючи роботи різних компаній, звернув увагу на появу нового патерну «micro-app», який оптимізував SOA з точки зору прискорення розгортання сервісів. Дещо пізніше, у 2012 році, на архітектурному саміті патерн був перейменований на мікросервіс. Таким чином, первинною метою впровадження мікросервісів було покращення горезвісного час на ринок.
На «хвилі хайпу» мікросервіси були у 2015 році. За деякими дослідженнями жодна конференція не обходилася без доповіді на тему мікросервісів. Більше того, деякі конференції були присвячені виключно мікросервісам. Зараз дуже багато проектів починаються із застосуванням даного архітектурного стилю, а якщо проект містить тонни legacy-коду, то напевно активно здійснюється міграція на мікросервіси.
Незважаючи на все сказане вище, досі досить невелика кількість розробників може визначити поняття «мікросервіс». Але про це ми поговоримо трохи пізніше.
Моноліт
Архітектурним стилем, що протиставляється мікросервісним, є моноліт (або «все в одному»). Що таке моноліт розповідати, напевно, не має сенсу, тому я одразу перерахую недоліки цього архітектурного стилю, які ініціювали подальший розвиток архітектурних стилів: розмір, зв'язаність, розгортання, масштабованість, надійність та відсталість. Нижче я пропоную ознайомитися з кожним недоліком окремо.
Розмір
Моноліт дуже великий. І спілкується він зазвичай із дуже великою базою даних. Програма стає занадто великою, щоб її міг зрозуміти один розробник у принципі. З монолітом добре працювати можуть ті, хто провів за цим кодом досить багато часу, тоді як новачки витратить дуже багато часу на спроби розібратися з монолітом і не факт, що розберуться. Зазвичай при роботі з монолітом завжди є деякий «умовний» senior, який знає моноліт більш-менш добре і б'є по руках протягом року-півтора інших нових розробників. Природно, що такий умовний senior є єдиною точкою відмови і його відхід може призвести до загибелі моноліту.
Пов'язаність
Моноліт є «великою грудкою бруду» (big ball of mud), зміни в якому можуть призвести до непередбачуваних наслідків. Вносячи зміни в одному місці, можна пошкодити моноліт в іншому (те саме "вухо почухав, * @ відвалилася"). Пов'язано це з тим, що компоненти у моноліті мають дуже складні та, головне, неочевидні взаємозв'язки.
розгортання
Розгортання моноліту через складні взаємозв'язки між його компонентами — це тривалий процес зі своїм ритуалом. Такий ритуал звичайно остаточно стандартизований і передається «з вуст в уста».
масштабованість
Модулі моноліту можуть мати потреби в ресурсах, що конфліктують, через що необхідно шукати компроміс з точки зору заліза. Уявіть собі, що моноліт складається з сервісів A і B. Сервіс A вимогливий до розміру жорсткого диска, а сервіс B — до оперативної пам'яті. У такому випадку або машина, на яку ставиться моноліт, повинна підтримувати вимоги обох сервісів, або доведеться руками, штучно один з сервісів відключати.
Ще один приклад (більш класичний): сервіс A набагато популярніший, ніж сервіс B, тому ви хочете, щоб сервісів A було 100, а сервісів B було 10. Знов-таки два варіанти: або розгортаємо 100 повноцінних монолітів, або на яких- то з них руками послуги B доведеться відключати.
Надійність
Оскільки всі послуги знаходяться разом, якщо моноліт падає, то падають всі послуги одночасно. Насправді, можливо це не так і погано, принаймні часткових відмов у розподіленій системі не буде, але з іншого боку, через помилку у функціональності, яку використовує 0.001% користувачів, ви можете втратити всіх користувачів вашої системи.
Відсталість
Через розмір моноліту важко перейти на нові технології. Як наслідок, окремим завданням вимальовує утримання того самого умовного senior'а. Вибраний на старті проекту технологічний стек може стати блоком, який перешкоджає розвитку продукту.
Висновок
Наступного разу ми поговоримо про те, як люди спробували вирішити зазначені проблеми, перейшовши до компонентів та SOA.
Читати ще:
Джерело: habr.com