Зачем микросервисы на Java — и когда они не нужны
Микросервисная архитектура оправдана, когда у команды есть независимые домены, разный цикл релизов и реальная потребность в горизонтальном масштабировании отдельных частей системы. Если продукт маленький, а команда одна, «разрезание» монолита чаще добавляет операционную сложность, чем скорость.
На практике зрелый подход выглядит так: сначала модульный монолит с чёткими границами пакетов и API, затем выделение сервисов по границам bounded context. Это совпадает с тем, что рекомендуют авторы Domain-Driven Design и большинство докладов на Habr / JPoint по эволюции архитектуры.
Границы сервисов и контракты
Хороший сервис владеет своими данными и публикует стабильный контракт. Для синхронного API удобны OpenAPI + версионирование (/api/v1). Для асинхронного взаимодействия — события с явной схемой (Avro/JSON Schema) и обратной совместимостью полей.
- Не шарьте БД между сервисами — это скрытая связность.
- Идемпотентность на записи критична при ретраях и outbox-паттерне.
- Saga / choreography — только там, где есть распределённая бизнес-транзакция; иначе достаточно локальной транзакции + eventual consistency.
Стек, который чаще всего встречается в проде
Типичный Java-стек 2024–2026: Java 21 LTS, Spring Boot 3.x (или Quarkus, если важны startup time и memory), PostgreSQL/MySQL, Redis для кэша, Kafka/RabbitMQ для событий, Docker + Kubernetes для поставки.
Spring Cloud Gateway или API Gateway на ingress-уровне закрывает маршрутизацию, rate limit и TLS termination. Service discovery в Kubernetes обычно не нужен «как в Netflix OSS» — достаточно Kubernetes Services и DNS.
// Пример: явный контракт REST через HttpExchange (Spring 6+)
@HttpExchange("/orders")
public interface OrderClient {
@GetExchange("/{id}")
OrderResponse getById(@PathVariable long id);
}
Наблюдаемость — не «потом»
Без метрик, логов и трейсов микросервисы превращаются в чёрный ящик. Минимум для продакшена:
- Micrometer + Prometheus / OpenTelemetry metrics;
- structured JSON-логи с
traceId/spanId; - распределённый трейсинг (OTel → Jaeger/Tempo);
- health endpoints для readiness/liveness (Actuator).
Вывод
Микросервисы на Java работают хорошо, когда границы доменов понятны, контракты версионируются, а платформа (K8s, CI/CD, observability) уже готова. Начинайте с простых правил: один сервис — одна БД, явные API, идемпотентность и измеряемые SLO. Остальное — эволюция, а не big bang rewrite.