junior
Чем микросервисная архитектура отличается от монолитной?
Монолит — это единое приложение, в котором все компоненты (UI, бизнес-логика, доступ к данным) развёртываются как один артефакт. Микросервисы — набор отдельных приложений, каждое со своей кодовой базой и хранилищем.
| Критерий | Монолит | Микросервисы |
|---|---|---|
| Структура | Единое приложение, один деплой | Набор независимых сервисов |
| База данных | Одна общая БД | Отдельная БД у каждого сервиса |
| Развёртывание | Всё приложение целиком | Каждый сервис независимо |
| Масштабирование | Только целиком (vertical/horizontal) | Каждый сервис отдельно |
| Технологический стек | Единый для всего приложения | Может различаться |
| Отказоустойчивость | Ошибка может положить всё | Ошибка изолирована в одном сервисе |
| Размер команды | Вся команда работает с одной кодовой базой | Маленькие команды владеют отдельными сервисами |
| Сложность | Простая начальная разработка | Сложная инфраструктура с самого начала |
| Транзакции | Локальные ACID-транзакции | Распределённые (Saga, eventual consistency) |
| Тестирование | Простое интеграционное | Требует contract testing, E2E |
Пример кода: монолит vs микросервисы
// Монолит: всё в одном приложении
@SpringBootApplication
public class BankingMonolithApplication {
// Модуль платежей, модуль клиентов, модуль отчётов —
// всё в одном JAR/WAR
}
// Микросервисы: набор отдельных приложений
@SpringBootApplication
public class PaymentServiceApplication { }
@SpringBootApplication
public class CustomerServiceApplication { }
Микросервисы — это не «серебряная пуля». Монолит прекрасно работает для многих задач, и переход на микросервисы оправдан только при наличии реальных проблем масштабирования команды или системы.
На собеседовании: покажите, что понимаете trade-offs обоих подходов. Частая ошибка — представлять монолит как устаревший антипаттерн. Хороший ответ: «монолит подходит для старта, микросервисы — когда появляется боль масштабирования».