Перехід від моноліту до микросервисам


Кожен більш-менш успішний продукт приходить до стану, коли додавати нові можливості в існуючу кодову базу стає настільки важко, що вартість нової функціональності перевершує всі можливі вигоди від її використання. Звичайно ж, добрий і уважний архітектор подбає про програму заздалегідь і направить розробку в правильне русло. Найпопулярніший на даний момент підхід передбачає розпилювання одного великого шматка коду на багато дрібних проектиков, кожен з яких відповідає за свої певні можливості. При проектуванні такої системи нависає величезна відповідальність. Потрібно продумати і розробити такий тип взаємодії між цими окремо лежать шматочками, щоб майбутні внесення змін не вимагали переписати все до біса.
Ясна річ, в мережі існує величезна кількість експертних статей, які показують нам важливість такої архітектури і розповідають про те, яку архітектуру можна назвати хорошою, а яку не дуже. Існує величезна кількість методів взаємодії між окремими програмками великої програми зі своїми протоколами, версионированием протоколу і документації, написання документації на програмні інтерфейси, способу розгортання і синхронізації всього цього добра разом. Безумовно, кожна така стаття або метод логічний і послідовний і особливо, якщо описаний метод підтверджено на практиці. Але біда не в тому, що проектувальники не знають яку систему вони хочуть в результаті отримати. Біда в тому, як перейти до такої ось правильної архітектурі і коли ж можна припинити писати монолітне додаток і почати вже писати дорослі микросервисы, щоб перед пацанами не було соромно.
Спочатку моноліт
По-перше, поширений підхід "спочатку моноліт" повністю виправданий і бачиться розумним компромісом між вартістю розробки і швидкістю розробки. Невелика монолітне додаток має кілька цілком очевидних переваг, одне з головних — швидкість додавання нової функціональності. У нашому монолітному проекті простіше подивитися зв'язність кодової бази і переконається, що нова, тільки що додана, функціональність працює. Безсумнівно, досвідчений читач помітить, що микросервисы дозволяють домогтися слабкою зв'язності різних частин програми, але не варто забувати, що у більшості випадків активно розвиваються монолітні проекти мають кодову базу не найвищої якості.
Від микросервисов не піти
Друге твердження полягає в тому, що нескінченно величезна додаток з нескінченною функціональністю монолітним бути не може. Рано чи пізно з'являються частини програми, які запускаються на різних серверах або хоча б просто різними процесами.
Головне почати
Третє висновок виводиться з двох перших і в ньому говориться, що будь-монолітне додаток рано чи пізно змінює архітектуру на микросервисную. Відповідно, існує момент часу в розробці програми, коли необхідно змінювати стратегію розробки і почати вводити микросервисы.
Вищезгадані три твердження ставлять перед нами два питання: коли і як. Давайте по порядку.
Як зрозуміти, що настав той самий момент, що пора вже пиляти микросервисы?
Давайте підійдемо до цього питання суто практично, і обмежимо шукану тимчасову точку зверху і знизу. Однозначно, рано займатися розпилом моноліту, якщо всі члени команди все ще орієнтується в будь-якій частині програми. Також ознакою своєчасності монолітної архітектури є те, що новачок у команді може легко і невимушено почати розробляти новий функціонал відразу після ознайомлення.
Виділяти микросервисы вже стає запізно, якщо виникає бажання кешувати html-сторінки цілком, тому що гальмують, а щоб прискорити, потрібно переписати половину програми, замінити ORM або взагалі переписати все на іншій мові, де все добре і додатки не гальмують.
Переходити на архітектуру з микросервисами ще рано, якщо будь-який з видів фаулеровских рефакторингов може бути легко застосований в монолітному додатку. А от замінити монолітну архітектуру потрібно було б вже давно, якщо простого рефакторінгу не передбачається, або взагалі важко такого місця знайти, що чисто по-фаулеровски можна було б отрефакторить.
І самий головний критерій необхідності почати переходити на микросервисную архітектуру — коли вартість додавання нової фічі починає перевершувати вигоду від цієї фічі.
З чого почати міграцію архітектури на користь микросервисов?
Стратегій зміни парадигми кілька. Найпростіша з них і стратегічно неправильна — розробити микросервисную архітектуру з нуля, використовуючи монолітне додаток, як приклад для наслідування. Напевно, поширеність такого підходу і є головним аргументом прихильників писати програми відразу на микросервисах. Але це серйозно додає вартості до початкової розробці програми.
Більш адекватним підходом переходу від моноліту до микросервисам є поступове отпочковиваніе микросервисов та написання нової функціональності вже окремо від основного додатка. Підхід хороший і робочий, але має один істотний недолік — основне монолітне додаток в осяжному майбутньому не зникне. В результаті у нас буде моноліт і купа допоміжних сервісів, замість набору незалежних микросервисов.
В кінцевому рахунку, адекватним способом перейти до микросервисной архітектурі можна назвати спосіб, при якому основна монолітне додаток розбивається на кілька великокаліберних додатків з сильною міжусобної зв'язністю. Після чого піддодатки розглядаються і рефакторятся окремо, попутно зачіпаючи сусідів і змушуючи їх пристосовуватися і змінюватися разом. Поступово такий підхід призведе до зменшення зв'язності і появи усталеного інтерфейсу кожного піддодатки. При досягненні такої ось усталеної тимчасової точки, представляється можливим вносити зміни в піддодатки, не зачіпаючи при цьому сусідні. І це подприложение розглядається, як моноліт простіше і рівнем нижче. І з ним робляться аналогічні процедури. Поступово додаток б'ється на більш-менш рівні частини. Деякі частини в процесі стають непотрібними, деякі дублюють вже існуючі інші частини або взагалі зливаються в один загальний сервіс для усунення дублювання. В результаті рано, чи радше пізно, виходить усталене додаток на микросервисной архітектурі.
Замість висновків.
Микросервисы — добре. Моноліт — добре. Хороший код — добре. Робочий код — добре. Стаття не закликає терміново міняти принцип розробки в додатках, які гальмують, криво написані або написані не так, як хотілося б. Так само микросервисная архітектура не є панацеєю від усіх бід розробників. У статті описуються точки і способи переходу від монолітної до микросервисной архітектурі.
"Відмовостійкість", "розгалуженість", "масштабованість" це безумовно добре, але не це головне перевага микросервисной архітектури. Найважливіше, що дає такий підхід — здешевлення вартості внесення змін.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.