микросервисная архитектура

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

Принципы микросервисной архитектуры

Единственная ответственность: каждый сервис делает одно дело и делает его хорошо. Граница сервиса определяется бизнес-доменом, а не технической функцией.

Независимое развёртывание: команда может выпустить новую версию сервиса, не координируясь с другими командами и не останавливая систему.

Децентрализованное управление данными: каждый сервис владеет своей базой данных. Прямой доступ к чужой БД запрещён. Это обеспечивает слабое зацепление и технологическую свободу.

Отказоустойчивость по умолчанию: сервисы проектируются с учётом того, что зависимые сервисы могут быть недоступны. Circuit breaker, retry, fallback — обязательные паттерны.

Монолит против микросервисов

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

Микросервисы дают преимущества при масштабировании: независимое масштабирование отдельных компонентов, технологическая гетерогенность (Python для ML, Go для высоконагруженного API), независимые команды по Конвею. Но вводят сложность: распределённые системы, сетевые сбои, eventual consistency, трассировка запросов через десятки сервисов.

Коммуникация между сервисами

Синхронная: REST/HTTP, gRPC. Прямой вызов — вызывающий сервис ждёт ответа. Прост в отладке, но создаёт связность по времени: если вызываемый сервис упал, операция провалится.

Асинхронная: через брокеры сообщений (Kafka, RabbitMQ, NATS). Сервис публикует событие и не ждёт ответа. Высокая устойчивость к отказам, но сложнее отлаживать и сложнее обеспечить согласованность.

Паттерн Saga решает проблему распределённых транзакций: длинная операция разбивается на серию локальных транзакций с компенсирующими действиями при откате.

Инфраструктура для микросервисов

Service Mesh (Istio, Linkerd) — инфраструктурный слой, добавляющий observability, mTLS, traffic management без изменения кода сервисов.

API Gateway — единая точка входа: маршрутизация, аутентификация, rate limiting, агрегация ответов.

Service Discovery (Consul, Kubernetes DNS) — сервисы находят друг друга по имени, а не по хардкоженным IP.

Distributed Tracing (Jaeger, Zipkin, Tempo) — трассировка запроса через цепочку сервисов для отладки и анализа производительности.

Observability в микросервисной архитектуре

Три столпа observability: метрики (Prometheus), логи (ELK, Loki) и трейсы (Jaeger). В монолите достаточно логов. В системе из 50 сервисов понять, почему конкретный запрос занял 5 секунд, без distributed tracing практически невозможно.

Когда не нужны микросервисы

Микросервисы — не серебряная пуля. Команда меньше 15–20 человек, скорее всего, не выиграет от микросервисов: операционная сложность превысит выгоды. Стартап без product-market fit рискует тратить 80% времени на инфраструктуру. Мартин Фаулер сформулировал «монолит-первый» паттерн: начните с модульного монолита, перейдите к микросервисам когда границы доменов станут ясны и команды вырастут.