Как ответить
Микросервисная архитектура — это подход, при котором приложение разбивается на набор слабосвязанных сервисов. Каждый сервис отвечает за конкретную бизнес-функцию, имеет собственную базу данных и развертывается независимо от остальных. В отличие от монолита, где изменение одной строки кода требует пересборки всего проекта, здесь мы обновляем только нужный компонент.
На практике это работает так: вместо одного огромного приложения у нас есть десяток маленьких, которые общаются между собой по сети (обычно через REST, gRPC или брокеры сообщений вроде RabbitMQ/Kafka). Основные характеристики подхода:
- Децентрализация данных: У каждого сервиса своя БД (Database-per-Service). Это исключает ситуацию, когда изменение схемы таблицы в одном модуле «ломает» работу другого. Если сервису заказов нужны данные пользователя, он запрашивает их через API, а не лезет в чужую таблицу.
- Независимое развертывание: Мы можем катить новую версию сервиса оплаты, не трогая каталог товаров. Это позволяет использовать CI/CD на полную мощность и сокращает Time-to-Market.
- Технологическая свобода: Можно написать сервис обработки изображений на Python, потому что там лучше библиотеки, а высоконагруженное ядро оставить на Go или Java.
Однако микросервисы добавляют сложности, которых нет в монолите. Главная проблема — распределенные транзакции. Если нам нужно списать деньги и забронировать товар, мы не можем использовать обычный BEGIN TRANSACTION. Приходится внедрять паттерны вроде Saga (компенсирующие транзакции) или Two-Phase Commit, хотя последний в микросервисах используется редко из-за проблем с производительностью.
Пример взаимодействия через брокер сообщений на Node.js (упрощенно):
// Сервис заказов отправляет событие о создании заказа
const order = { id: 123, status: 'created' };
channel.publish('order_exchange', 'order.created', Buffer.from(JSON.stringify(order)));
// Сервис уведомлений слушает это событие
channel.consume(queue, (msg) => {
const data = JSON.parse(msg.content.toString());
sendEmail(data.userId, 'Ваш заказ создан');
});Важно понимать, что микросервисы — это не «серебряная пуля». Они оправданы, когда команда переваливает за 20-30 человек или когда части системы имеют радикально разную нагрузку. Для стартапа на 3 человека монолит почти всегда будет эффективнее.