Реактивное программирование
Тема дорожной карты · Spring Boot
Реактивное программирование в Spring — это неблокирующая, событийно-управляемая парадигма программирования, построенная на спецификации Reactive Streams и Project Reactor, позволяющая Spring Boot-приложениям обрабатывать высокую конкурентность с небольшим фиксированным числом потоков. Модуль Spring WebFlux заменяет традиционный Servlet-стек Spring MVC событийным циклом Netty или Undertow, где методы-обработчики @RestController возвращают Mono<T> или Flux<T> вместо обычных объектов, а back-pressure естественно распространяется через весь пайплайн. Реактивное программирование в Spring интегрируется с R2DBC для неблокирующего доступа к реляционным базам данных, реактивным драйвером Spring Data MongoDB, реактивными операциями Spring Data Redis и реактивной поддержкой потребителей Spring AMQP, обеспечивая единую неблокирующую модель на уровнях персистентности, обмена сообщениями и HTTP. WebClient — реактивная альтернатива RestTemplate — объединяет операторы retrieve().bodyToMono() и onErrorResume() для составления устойчивых исходящих HTTP-вызовов без блокирования потоков, что критически важно в микросервисных архитектурах на Kubernetes, где исчерпание потоков каскадно распространяется. Командам, переходящим на реактивное программирование в Spring, следует вложить усилия в понимание Scheduler Project Reactor, StepVerifier для модульного тестирования пайплайнов Mono и Flux и интеграции с Micrometer для наблюдаемости реактивных Spring Boot-сервисов.
Как это работает
Реактивное программирование: Spring WebFlux — non-blocking reactive стек на Project Reactor (типы Mono + Flux). Вместо one thread per request (Servlet), маленький thread pool handle-ит много concurrent запросов через event loop. R2DBC — reactive DB driver, аналог JDBC. WebClient (non-blocking, reactive HTTP-клиент) заменяет RestTemplate. Reactive код читается иначе: цепочки операторов (map, flatMap, filter) вместо imperative. Big learning curve, реальная польза только на high concurrency.
Когда применять
WebFlux только когда (а) huge fan-out + нужен backpressure, (б) streaming, (в) downstream reactive end-to-end. Смешение blocking JDBC в reactive-флоу убивает суть (offloading осторожно). Для типичного CRUD MVC + Servlet проще, debuggable, достаточно быстро. Virtual threads (JDK 21+) закрывают gap для многих случаев — рассмотрите до WebFlux.
Типичные ошибки
Ловушки Реактивное программирование: blocking calls внутри reactive-цепочек (убивает модель + deadlocks); reactive везде "потому что быстрее" (медленнее для wrong shape работы); сложнее debugging (stack traces бесполезны; checkpoint() + reactor debug agent); over-use flatMap, когда map работает.