Разработка микросервисов на Java и Spring Boot

Начало: тот самый холодный пот на презентации архитектуры
Помню, как наш клиент, владелец маркетплейса handmade-товаров, сидел напротив меня и смотрел на схему монолита. Его глаза выдавали усталость. «Одна правка в корзине — и падает весь каталог. Я боюсь дышать на код», — сказал он. Это не просто баг — это потерянные сделки, нервы команды и чувство, что ты заложник собственной платформы.
Мы перешли на микросервисы с Java и Spring Boot. Первые две недели было страшно: новые репозитории, отдельные базы данных, настройка Feign-клиентов. Но уже на третьем спринте команда выдохнула. Один из разработчиков признался: «Я впервые за год не боюсь залить фичу в пятницу вечером». Это не про технологию — это про чувство безопасности и контроля.
Хотите такую же свободу? Тогда давайте разберем, что именно меняется на уровне эмоций и логики, когда вы переходите на микросервисы.
«Мы не готовили риса на всех» — как Spring Boot решил проблему перегруза
Однажды у нас был проект — сеть кофеен с программой лояльности. Старый монолит на Java 8 запускался 12 минут. Каждый раз, когда бариста заказывал новый сорт зерен, приходилось пересобирать всё приложение. Команда шутила, что «запуск сервера — время для второго эспрессо», но улыбки были нервными.
Мы разбили систему на 6 микросервисов: заказы, инвентарь, баллы, уведомления, пользователи и аутентификация. Использовали Spring Boot 2.x с Embedded Tomcat. Первый же запуск — 25 секунд вместо 12 минут. Разработчик Антон сказал: «Я почувствовал ритм. Как будто раньше мы гребли вёслами, а теперь подняли парус». Эмоция продуктивности — это не про скорость кода, а про скорость мышления.
Вот что мы сделали конкретно:
- Разделили по доменам (DDD): сервис лояльности не знает, как хранятся зерна. Только ID заказа и бонусные баллы.
- Настроили Service Discovery через Eureka: сервисы нашли друг друга за вечер, без ручного прописывания IP.
- Добавили Circuit Breaker (Resilience4j): когда сервис склада упал, касса не «легла» — клиент просто не увидел остаток, но заказ сделал.
- Сделали Health Check для каждого микросервиса: Actuator + метрики в Prometheus. Теперь понедельник начинается не с «git blame», а с дашборда.
Что вы почувствуете после такого рефакторинга? Тишину. Перестанут звонить коллеги с вопросом «почему упало всё».
Инсайт №1: Ошибка «святого грааля» — зачем мы чуть не убили проект тестами
Был у нас стартап по доставке фермерских продуктов. Команда была заряжена: они написали 2000 юнит-тестов для каждого микросервиса. Но на нагрузочном тестировании (5000 RPS) система упала с OutOfMemoryError на 3-м запросе. Разработчики сидели бледные. «Мы так старались», — прошептал тимлид.
Проблема была не в тестах, а в отсутствии интеграционных тестов и неправильном тюнинге Spring Boot. Мы добавили настроек под JVM: -Xms512m -Xmx1g, отключили ненужные автоконфигурации и добавили кэш второго уровня для Hibernate. Система ожила. Главный урок: микросервисы — это не про количество кода, а про настройки и границы ответственности.
- Не гонитесь за 100% покрытия юнитов: 70% кода + 30% интеграционных тестов с Testcontainers дают больше уверенности.
- Используйте @SpringBootTest только для ключевых сценариев: каждый тест — это сборка контекста, что тормозит пайплайн.
- Ставьте Rate Limiting на уровне Gateway: один сервис клиентов может случайно «заспамить» другой.
- Пишите тесты на бизнес-кейсы, а не на геттеры-сеттеры: «клиент платит — баланс уменьшается» — вот что реально важно.
Когда мы переписали тесты, чувство было такое, будто сняли рюкзак с камнями. Команда снова начала кайфовать от код-ревью.
Инсайт №2: «Тихий час» для данных — как мы подружили ACID и микросервисы
Финтех-проект по переводам между картами. У клиентов глаза дергались, когда мы говорили, что в микросервисах нет транзакций на несколько таблиц. Один CEO сказал: «Вы что, хотите, чтобы деньги пропадали?» Мы предложили паттерн Saga (Orchestration-based). Через месяц он написал мне: «Я не понимаю, как это работает, но деньги не пропадают. Спасибо за сон».
Мы использовали Axon Framework + Spring Boot. Каждая операция перевода — это цепочка событий: создать запрос, заблокировать сумму, списать, зачислить, подтвердить. Если падает один шаг — летит компенсирующее событие. Никаких блокировок.
- Choreography vs Orchestration: выбрали оркестратор (отдельный сервис), чтобы не запутаться в событиях. Проще дебажить.
- Idempotency: каждый запрос имеет ID. Повторная отправка не создаст дубль.
- Outbox pattern: записали событие в локальную таблицу, потом отдельный поток читает и отправляет в Kafka. Гарантия доставки 99,99%.
Что чувствуешь, когда Saga работает корректно под 1000 RPS? Спокойствие. Как будто смотришь на часы — они тикают ровно, без рывков.
Инсайт №3: Боль от «золотого молотка» — почему Docker не спас вас на проде
Однажды мы пришли в компанию, где микросервисы работали в Docker, но каждое утро devops просыпался от алерта «Disk space 99%». Логи писались внутрь контейнеров. Никто не знал, сколько места занимает Spring Boot без Deferred Logging. Мы решили: сломать стереотипы.
Мы внедрили JSON-логирование через Logback + агрегацию в ELK. Настроили ротацию логов по размеру и времени. Отдали метрики в Grafana. Разработчик Петя, который отвечал за мониторинг, сказал: «Раньше я заходил на сервер и чувствовал запах гари. Теперь я просто смотрю на экран».
- Ставьте лимиты CPU/Memory в docker-compose:
deploy.resources.limits.cpus: '1.5'. Иначе один микросервис сожрет все ресурсы. - Используйте Profile-Specific конфигурации: application-dev.yaml и application-prod.yaml. Не смешивайте в одном файле.
- Добавьте метрики бизнес-логики: не только CPU, но и «время выполнения перевода» или «количество созданных заказов».
- Включите Spring Boot Graceful Shutdown:
server.shutdown=graceful. Тогда при рестарте контейнер не оборвет запрос клиента.
Эмоция, которую вы получите — гордость за систему. Вы перестанете бояться релизных ночей.
Бонус-кейс: «Танцы с бубном» вокруг версионирования API
Был проект с мобильным приложением. Версия 1.0. Клиент — огромная сеть фитнес-клубов. Мы обновили API микросервиса «абонементы», изменив формат даты. Приложение упало на iOS. Пользователи в комментариях писали: «Вы сломали мою карту». Мы чувствовали себя хуже некуда.
Теперь мы используем URL-версионирование: /api/v1/abonements и /api/v2/abonements. Spring Boot позволяет обслуживать обе версии через один контроллер с разными маппингами. Старое приложение работает с v1, новое — с v2. Через полгода мы мягко отключаем v1.
Совет: не удаляйте старый эндпоинт, пока не убедитесь, что 0% клиентов на него не ходят. И добавляйте заголовок Sunset: ... для вежливого уведомления. Спокойствие клиента дороже чистоты кода.
Итоги: что вы почувствуете, когда микросервисы станут частью жизни
Микросервисы на Java и Spring Boot — это не панацея. Это про уважение. Уважение к своей нервной системе, к времени команды и к клиентам. Когда каждый сервис делает одно дело, но хорошо, вы перестаете чинить «велосипеды» и начинаете строить машины.
Мы прошли через десятки проектов: от стартапов до enterprise. И каждый раз эмоции одни и те же: сначала — страх, потом — восторг от контроля. Наш главный клиент (сеть кофеен) через год сказал: «Я не понимаю, как у вас это получается, но я просто пью кофе и смотрю на прибыль». Это лучший комплимент.
Добавлено: 07.05.2026
