Что такое микросервисная архитектура и какие её преимущества?

Что такое микросервисная архитектура и какие её преимущества?

Микросервисная архитектура — это подход к разработке приложения, при котором оно состоит из множества небольших, независимых сервисов, каждый из которых отвечает за одну бизнес-функцию.

Определение

Монолитная архитектура (до): Одно приложение = Каталог + Покупки + Платежи + Доставка + Уведомления (всё в одной кодовой базе)

Микросервисная архитектура (после): Сервис Каталога, Покупок, Платежей, Доставки, Уведомлений (каждый независимо)

Преимущества для бизнеса

Скорость разработки

• Каждая команда работает на своём сервисе
• Не ждём, пока доделают другие части
• Деплой раз в неделю вместо раза в месяц

Масштабируемость (Scalability)

• Сервис Платежей нужен для 10 000 RPS? Масштабируем только его
• Сервис Каталога нужен слабее? Используем меньше ресурсов
• Экономия: платим только за то, что нужно

Надёжность (Reliability)

• Если упал Сервис Уведомлений, остальное работает
• В монолите падение одного модуля = падение всего
• Изоляция ошибок

Технологическая гибкость

• Сервис Платежей на Go (быстрый)
• Сервис Каталога на Python (удобный)
• Сервис Доставки на Node.js (асинхронный)
• Каждая команда выбирает свой стек

Итерирование

• Быстрая доставка новых фич
• A/B тестирование отдельного сервиса без риска

Преимущества для BA

Понимание сложности:

• Видим, какие сервисы взаимодействуют
• Когда требование возникает, видим все сервисы, которые нужны

Оценка рисков:

• Зависит ли требование от других сервисов?
• Если сервис упадёт, что произойдёт?

Планирование:

• Разные команды могут работать параллельно
• Видим, сколько команд нужно

Мониторинг:

• Видим, какой сервис упал
• Быстро находим проблему

Недостатки микросервисов

Сложность операций:

• Нужна хорошая инфраструктура (Kubernetes, Docker)
• 5 сервисов = 5 стеков, 5 БД, 5 логов

Консистентность данных

• В монолите: одна транзакция, всё или ничего
• В микросервисах: сервис А сохранил, сервис Б упал
• Нужна система компенсаций (saga pattern)

Сетевые задержки

• Монолит: вызов функции (нанопровод)
• Микросервисы: HTTP запрос (сотни мс)
• Медленнее, но приемлемо

Усложнённая разработка

• Монолит: правлю код в одном месте
• Микросервисы: обновляю 3 сервиса и синхронизирую версии

Когда использовать микросервисы?

ДА, если:

• Приложение большое (10+ разработчиков)
• Разные части имеют разные требования
• Хотите быстро деплоить отдельные части
• У вас хорошая DevOps команда

НЕТ, если:

• Приложение маленькое (1-3 разработчика)
• Нет явного разделения
• Нет опыта с микросервисами
• Нет хорошей инфраструктуры

Практический пример: интернет-магазин

Монолит (небольшой): Приложение на Rails/Django, Models, API, One database, One server

Микросервисы (большой, 50+ разработчиков):

API Gateway (единая точка входа) ├── Сервис Каталога (Python FastAPI, PostgreSQL) ├── Сервис Заказов (Node.js, PostgreSQL) ├── Сервис Платежей (Go, PostgreSQL) ├── Сервис Уведомлений (Python, Redis) └── Сервис Доставки (Go, PostgreSQL)

Взаимодействие через: ├── REST API или gRPC ├── Message Queues (RabbitMQ, Kafka) └── Service Discovery

Когда требование Пользователь создаёт заказ:

1. API Gateway получает запрос
2. Проверяет авторизацию
3. Вызывает Order Service → создаёт заказ в БД
4. Order Service отправляет событие (Order Created)
5. Payment Service обрабатывает платёж
6. Notification Service отправляет письмо

Архитектурные паттерны микросервисов

API Gateway — единая точка входа

Service Discovery — как сервис узнает адрес другого?

Load Balancing — распределение нагрузки

Circuit Breaker — если сервис упал, не бьём постоянно

Saga Pattern — транзакция через несколько сервисов

Event-Driven Architecture — сервисы общаются через события

Вывод

Микросервисная архитектура — это мощный подход для больших, сложных приложений, но это усложнение, которое имеет смысл только при определённом размере команды.

Для небольших проектов монолит лучше. Когда растёшь, постепенно выделяешь микросервисы.