tgoop.com/import_hello/45
Last Update:
Моноліт, мікросервіси, поліліт?
У сучасному світі розробки поширена думка, що моноліт застарів, а мікросервіси — єдиний правильний шлях побудови систем. Звісно, я трохи перебільшую, тим паче що час, коли кожна поважаюча себе компанія, мала у своєму блозі статтю про перехід від моноліту до 300 і більше мікросервісів, минув. Проте й досі часто розробники при старті нового проєкту одразу починають з мікросервісної архітектури. Але скоріш за все то не дуже гарна ідея і почати варто б було з побудови моноліту.
Бо починаючи новий проєкт, ви ще не знаєте, як правильно вибудувати bounded context і не розумієте меж доменних областей. Тому, у процесі розробки, вони будуть змінюватися: деякі сутності переходитимуть з одного контексту в інший, контексти дробитимуться та об'єднуватимуться, бізнес вимоги будуть постійно змінюватись. Таким чином, ваша система буде інтенсивно еволюціонувати, поки ви шляхом проб та помилок не визначите правильні межі. Такі великі зміни робити коли у тебе все побудовано на мікросервісах досить боляче. Більш доцільно почати з моноліту, а в процесі розробки та експлуатації, коли будете впевнені в правильності визначених bounded contexts, поступово "від'єднувати" частини системи в мікросервіси. Звичайно, не варто створювати мікросервіси лише тому, що так роблять усі. Це має бути обгрунтовано: можливо, частина вашої системи має вище навантаження і, виносячи її в окремий сервіс, ви зможете ефективніше масштабуватись; або в різних частинах системи можуть бути різні SLA та вимоги до безпеки; чи ви хочете передати частину системи в управління окремій команді, тощо. Гарний допис про те чому не варто стартувати з мікросервісів є у Мартіна Фаулера
Проте, ті, хто хоч раз спробував розділити вже існуючий, можливо застарілий, моноліт, скажуть, що це не просто. Сильна сторона моноліта "легкість змін" має зворотній бік — дуже легко побудувати систему із високою зв'язністю (high coupling), через що розбиття моноліту на окремі мікросервіси може бути настільки складним, що простіше переписати систему з нуля. Тому, щоб вирішити цю проблему, розумні люди придумали таку штуку як "модульний моноліт".
Модульний моноліт — це архітектурний прийом, що поєднує елементи монолітної архітектури з модульним підходом. Код розділений на модулі з чіткими межами в рамках одного додатку. Кожен модуль відповідає за певну функціональність і характеризується високою когезією та слабкою зв'язністю з іншими модулями. Слабка зв'язаність досягається завдяки комунікації між модулями через добре пропрацьований публічний API. Модулі можуть взаємодіяти як через прямі виклики методів, так і асинхронно через черги повідомлень, що ускладнює проектування, але спрощує перехід до мікросервісів (у разі необхідності). Кожен модуль представляє окремий bounded context, тож, якщо потрібно розділити моноліт на мікросервіси, це буде легко зробити. Ще один плюс такого підходу - ви можете ділити модулі між командами, тобто одна команда може ексклюзивно овнити один чи декілька модулів.
Більш детальний приклад модульного моноліту можно подивитись тут
Можливо, наступного разу розповім про наявні інструменти для Python, що сприяють побудові модульних монолітів.
Лінки:
- Дуже багато матеріалів по темі
- Monolith First
- Microservices Killer: Modular Monolithic Architecture
- microservices.io
BY import __hello__
Share with your friend now:
tgoop.com/import_hello/45