Лекція 162: Відмінності між монолітними та мікросервісними архітектурами

Якщо ви користувалися онлайн-кінотеатрами в 2010-х роках, то, найімовірніше, це був один великий застосунок, де система рекомендацій намертво прив'язана до плеєра, а той, у свою чергу, не може працювати без системи користувачів. Якщо база даних задумалася на пару секунд — і все зупиняється, включно навіть з адміністративною панеллю. Ось у чому суть моноліту — величезний клубок переплетеного коду, який можна лише цілком оновлювати, масштабувати та лагодити.

А тепер зазирніть у сучасний стримінговий сервіс — плеєр сам по собі, рекомендації окремо, профілі користувачів взагалі на іншому сервері. Впала система коментарів? Нічого, фільми все одно можна дивитися. Новорічний наплив глядачів? Просто збільшуємо потужність відеосерверів, не чіпаючи решту. Це і є мікросервісна архітектура — набір незалежних компонентів, які вміють спілкуватися, але можуть працювати самостійно.

А тепер розглянемо детальніше особливості цих двох підходів.

Моноліти

Основні характеристики монолітної архітектури:

1. Централізований єдиний код: весь застосунок збирається в один "кубик", будь то JAR або WAR.
2. Зв'язана структура: усі частини застосунку (контролери, сервіси, репозиторії) tightly coupled — тобто тісно пов'язані між собою.
3. Єдине розгортання: навіть якщо ви змінюєте один рядок у коді, потрібно пересобрати і перезапустити весь застосунок.

Переваги моноліту

• Просте розгортання: один файл = менше проблем з налаштуванням середовища.
• Налагоджування зручніше: легше запустити весь проєкт локально і відлагоджувати систему.
• Єдина кодова база: всі модулі знаходяться в одному місці, і зміни застосовуються централізовано.
• Режим для новачків: для новачків у команді простіше зрозуміти єдину систему, ніж зоопарк мікросервісів.

Недоліки моноліту

• Проблеми масштабування: моноліт можна масштабувати лише вертикально (додавши більше CPU, RAM і інших ресурсів на сервер), але що робити, якщо потрібно масштабувати лише невелику частину застосунку? Наприклад, ваш серверний API для обробки зображень користується більшою популярністю, ніж інші частини системи. На жаль, ви все одно маєте масштабувати весь моноліт цілком.
  • Складність оновлень: у моноліті складно викотити зміни. Навіть невелика доробка потребує пересборки всього застосунку. Якщо в процесі оновлення щось піде не так, весь ваш небоскріб (ага, пам'ятаєте про наш небоскріб?) може впасти.
  • Вразливість до збоїв: один збій може призвести до того, що весь застосунок перестане працювати. Наприклад, якщо у вашому сервісі оплати виникла помилка, то весь сайт може стати недоступним.

Мікросервіси

Ми вже приводили приклад сучасного мікросервісного застосунку — онлайн-кінотеатру — де модулі незалежні один від одного.

Мікросервіси — це незалежні модулі, які:

1. Виконують одну конкретну задачу.
2. Автономно розробляються і розгортаються.
3. Спілкуються один з одним через стандартні мережеві інтерфейси (наприклад, REST або повідомлення через Kafka).

Переваги мікросервісів

• Незалежне розгортання: ви можете оновлювати, виправляти або навіть міняти технологічний стек одного мікросервісу, не зачіпаючи інші. Це зменшує ризик внесення руйнівних змін (breaking changes).
• Масштабованість: легко масштабувати тільки ті мікросервіси, які відчувають навантаження. Ваш API для завантаження котиків користується шаленою популярністю? Просто запускаєте більше екземплярів сервісу обробки зображень.
• Стійкість до збоїв: падіння одного мікросервісу не тягне за собою всю систему. Наприклад, якщо зламається ваш поштовий сервіс, користувачі все ще зможуть оплачувати покупки, перевіряти статус замовлення і додавати товари в кошик.
• Різноманіття технологій: кожен мікросервіс може використовувати різні мови програмування і бази даних, підходящі для конкретної задачі.
• Незалежність команд: мікросервіси дозволяють різним командам працювати автономно, що особливо корисно у великих компаніях. Кожна команда може зосередитися на своїй ділянці і deploy'ить зміни самостійно.

Недоліки мікросервісів

• Ускладнення розробки: розробка розподіленої системи складніша. Потрібно передбачити обробку відмов, продумати стратегію взаємодії сервісів і часто балансувати між синхронною та асинхронною комунікацією.
• Складне розгортання: на відміну від моноліту, розгортання мікросервісів вимагає координації багатьох частин. Вам доведеться налагодити CI/CD, мати систему управління конфігураціями (наприклад, Spring Cloud Config) і моніторинг.
• Network Overhead: мікросервіси обмінюються даними через мережу. Це додає затримки і вимагає продуманої стратегії по серіалізації та десеріалізації даних.

Порівняння моноліту і мікросервісів

Коли вибрати моноліт, а коли мікросервіси?

Коли використовувати моноліт:

1. Ви тільки починаєте проєкт, і ваша команда невелика.
2. У вас немає потреби в високій масштабованості.
3. Ви хочете швидко розробляти і виводити продукт на ринок.

Коли вибрати мікросервіси:

1. Застосунок став великий і занадто важкий для додавання нових фіч.
2. Потрібно масштабувати окремі модулі.
3. У вас є великі команди розробників, що працюють над різними частинами системи.
4. Потрібна висока відмовостійкість.

Підводні камені та типові помилки

Перехід від моноліту до мікросервісів — це не магія, яка вирішить усі проблеми. Навпаки, можна отримати більше проблем, якщо неправильно підійти до архітектури.

1. Надмірне дроблення: якщо ваші мікросервіси занадто маленькі, ви отримаєте головний біль із мережею та складністю координації.
2. Антипатерн розподіленої монолітності: коли мікросервіси все ще залежать один від одного, злам одного блоку ламає весь застосунок.
3. Брак інструментів: без інструментів для моніторингу (наприклад, Spring Boot Actuator або Prometheus) ви ризикуєте втратити контроль над системою.
4. Складнощі з консистентністю даних: підтримка узгодженості між мікросервісами стає викликом, особливо при асинхронній комунікації.

Тепер ви на крок ближче до розуміння, що робити: будувати "небоскреб" чи "район з магазинчиками". Мікросервіси — чудовий вибір для складних і масштабованих систем, але лише якщо ви готові до викликів.