Что такое микросервисы?
Микросервисы — архитектурный подход, при котором приложение состоит из нескольких небольших самостоятельных сервисов. Каждый отвечает за свою область — оплату, каталог, уведомления, — разворачивается отдельно и общается с остальными через API.
Главное преимущество — независимость. Команды выпускают свои сервисы, не дожидаясь друг друга, каждый сервис масштабируется отдельно под свою нагрузку, а отказ одного не обязательно роняет всю систему.
Цена — сложность эксплуатации. Появляются сетевые задержки, распределённые ошибки, необходимость сквозного логирования и согласованности данных между сервисами. Поэтому большинство продуктов разумно начинать с монолита и выделять сервисы тогда, когда для этого есть конкретная причина.
Где применяется
К микросервисам приходят крупные системы с большими командами: маркетплейсы, банки, сервисы доставки, телеком. Каталог, оплата, уведомления и поиск живут отдельно, разворачиваются независимо и могут быть написаны на разных языках — команда выбирает то, что лучше подходит её задаче.
Платой за гибкость становится инфраструктура. Нужны контейнеры и оркестрация, сквозная трассировка запросов, централизованные логи, обработка отказов и продуманные контракты между сервисами. Именно поэтому новые продукты чаще стартуют одним приложением и разделяются позже, когда боль от общего кода становится реальной.
Пример
В чёрную пятницу нагрузка растёт только на каталог и оплату. В микросервисной архитектуре масштабируют именно эти два сервиса, оставив остальные в прежнем виде. В едином приложении пришлось бы увеличивать мощность для всей системы целиком.
Частые вопросы
Чем микросервисы отличаются от монолита?
Монолит — одно приложение, которое собирается и разворачивается целиком. Микросервисы — набор отдельных сервисов, каждый со своей базой и релизным циклом. Монолит проще в разработке и эксплуатации, микросервисы выигрывают в независимости команд и точечном масштабировании.
С чего лучше начинать новый проект?
В подавляющем большинстве случаев — с монолита, но с аккуратно разделёнными модулями. Пока продукт ищет свою форму, границы между сервисами меняются, и зафиксировать их слишком рано — значит получить всю сложность распределённой системы без её преимуществ.
Какие сложности появляются с микросервисами?
Сетевые вызовы могут падать и подтормаживать, транзакция теперь охватывает несколько сервисов, логи разбросаны по разным системам, а воспроизвести проблему на своей машине заметно сложнее. Добавляется и эксплуатация: сквозной мониторинг, версионирование контрактов, согласованные развёртывания.
Как микросервисы общаются между собой?
Чаще всего синхронно через REST или gRPC, когда ответ нужен немедленно, и асинхронно через очереди сообщений вроде Kafka или RabbitMQ, когда важна устойчивость к временной недоступности. Зрелые системы обычно используют оба способа в разных сценариях.