Микросервисы
Архитектура, в которой система собирается из небольших независимых сервисов, каждый со своей задачей, данными и отдельным выпуском.
Микросервисная архитектура — способ строить систему из множества небольших сервисов. Каждый отвечает за одну область — заказы, платежи, уведомления, каталог, — имеет собственную базу данных и выпускается независимо от остальных. Сервисы общаются между собой через API или обмениваются сообщениями через брокер. Противоположный подход — монолит: одно большое приложение, которое собирается и выкатывается целиком.
Монолит и микросервисы
| Монолит | Микросервисы | |
|---|---|---|
| Выпуск | Всей системы сразу | Каждого сервиса отдельно |
| Масштабирование | Целиком | Только нагруженных частей |
| Данные | Общая база | У каждого сервиса своя |
| Сбой | Может уронить всё | Затрагивает часть функций |
| Сложность | Внутри кода | В сети, данных и эксплуатации |
Что дает подход
- Независимые команды. Каждая команда отвечает за свои сервисы и выпускает их в своем темпе, не согласовывая каждое изменение со всеми.
- Точечное масштабирование. Под нагрузкой добавляют копии только того сервиса, которому тяжело.
- Изоляция сбоев. Упали рекомендации — оплата продолжает работать.
- Свобода технологий. Сервисы можно писать на разных языках и переписывать по одному.
Чем приходится платить
- Сеть вместо вызова функции. Запросы между сервисами могут тормозить и теряться, поэтому нужны тайм-ауты, повторы и «предохранители».
- Согласованность данных. Операция, затрагивающая несколько сервисов, — уже не одна транзакция с гарантиями ACID. Используют саги — цепочки шагов с компенсирующими действиями при сбое.
- Эксплуатация. Десятки сервисов требуют контейнеров (Docker), оркестрации (Kubernetes), автоматической доставки (CI/CD) и мониторинга (Prometheus, Grafana, трассировка запросов).
Как общаются сервисы
Синхронно — через REST API или gRPC, когда ответ нужен сразу. Асинхронно — через брокер сообщений, например RabbitMQ или Kafka, когда достаточно сообщить о событии: «заказ оплачен». Асинхронный обмен снижает связанность: отправитель не зависит от того, работает ли получатель прямо сейчас. Снаружи вход обычно один — API-шлюз, который направляет запросы нужным сервисам.
Когда это оправдано
Микросервисы решают проблемы больших систем и больших команд. Для нового продукта небольшой команды они чаще замедляют работу. Распространенный путь — начать с хорошо разделенного на модули монолита и выделять сервисы тогда, когда появляется реальная причина: отдельная нагрузка, отдельная команда, разные требования к надежности. Так же постепенно переводят старые системы в рамках миграции: новые функции пишут отдельными сервисами вокруг монолита, а старые части выносят по одной.