На Ваши замечания могу сказать, что целью статьи было показать пример решения задачи асинхронного взаимодействия с web-сервисом с использованием Spring Boot/Reactor/WebClient. Оптимизация и оценка производительности - это отдельная интересная тема.
Но есть какие-то кейсы, где этого стоит. Почему у вас такой кейс?
Типичная задача в системах, использующих ElasticSearch, где есть существенная задержка ответа сервиса.
Насколько вы снизили потребность в ресурсах? За счет чего?
Event loop WebClient'а снижает количество потоков ожидающих ответ. Здесь этим занимается 1 поток (.subscribeOn(Schedulers.single()). Подготовка данных многопоточная, отправка запросов - асинхронная однопоточная.
Может быть Вы правы. В своё оправдание могу лишь сказать только то, что реактивное программирование я осваивал на Scala, по книге Akka in Action by Rob Williams, Raymond Roestenburg, Robertus Bakker, и на Java - Практика реактивного программирования в Spring 5 Oлег Докука Игорь Лозинский. Да, функциональный стиль предполагает инкапсуляцию кода непосредственно в операции. Потоки в этом примере запускают: 1001 запрос к базе данных; из базы данных выбираются 2000 документов; все выбранные документы обрабатываются, сериализуются; группируются, отправляются серверу ElasticSearch, обрабатываются ответы - каждый из этапов выполняется асинхронно, данные обрабатываются параллельно. В этом примере время выполнения < 1 сек. (можно посмотреть в последней строке лога). Не думаю, что я бы смог это сделать (организовать параллельное выполнение как между этапами конвейера, так и внутри блоков конвейера) в 2-х строках кода с использованием notify(All), wait, start, lock, tryLock, synchronized, CompletableFuture, Timer. Reactor, в том числе, и позиционируется его создателями как фреймворк избавляющий от вложенности callback'ов. Да и Spring анонсировал завершение поддержки RestTemplate и рекомендует переходить на WebClient и WebFlux, основывающихся на Reactor.
Согласен, реактивное(событийное) программирование не упрощает процесс кодирования, по сравнению с привычным многопоточным, но при правильном использовании позволяет снизить потребность в ресурсах, а фреймворки Reactor, Akka, Akka Stream, ... избавляют нас от рутины управления процессами обработки данных, позволяя сосредоточится на самой обработке.
Управление пулом, запуск на выполнение, ожидание завершения - этого всего нет в коде, всё делает reactor. Я думаю, что можно сравнить с управлением транзакциями JDBC vs JPA.
Пока нет
На Ваши замечания могу сказать, что целью статьи было показать пример решения задачи асинхронного взаимодействия с web-сервисом с использованием Spring Boot/Reactor/WebClient. Оптимизация и оценка производительности - это отдельная интересная тема.
Типичная задача в системах, использующих ElasticSearch, где есть существенная задержка ответа сервиса.
Event loop WebClient'а снижает количество потоков ожидающих ответ. Здесь этим занимается 1 поток (
.subscribeOn(Schedulers.single()). Подготовка данных многопоточная, отправка запросов - асинхронная однопоточная.Согласен. Не дошли руки.
Может быть Вы правы. В своё оправдание могу лишь сказать только то, что реактивное программирование я осваивал на Scala, по книге Akka in Action by Rob Williams, Raymond Roestenburg, Robertus Bakker, и на Java - Практика реактивного программирования в Spring 5 Oлег Докука Игорь Лозинский. Да, функциональный стиль предполагает инкапсуляцию кода непосредственно в операции. Потоки в этом примере запускают: 1001 запрос к базе данных; из базы данных выбираются 2000 документов; все выбранные документы обрабатываются, сериализуются; группируются, отправляются серверу ElasticSearch, обрабатываются ответы - каждый из этапов выполняется асинхронно, данные обрабатываются параллельно. В этом примере время выполнения < 1 сек. (можно посмотреть в последней строке лога). Не думаю, что я бы смог это сделать (организовать параллельное выполнение как между этапами конвейера, так и внутри блоков конвейера) в 2-х строках кода с использованием notify(All), wait, start, lock, tryLock, synchronized, CompletableFuture, Timer. Reactor, в том числе, и позиционируется его создателями как фреймворк избавляющий от вложенности callback'ов. Да и Spring анонсировал завершение поддержки RestTemplate и рекомендует переходить на WebClient и WebFlux, основывающихся на Reactor.
Согласен, реактивное(событийное) программирование не упрощает процесс кодирования, по сравнению с привычным многопоточным, но при правильном использовании позволяет снизить потребность в ресурсах, а фреймворки Reactor, Akka, Akka Stream, ... избавляют нас от рутины управления процессами обработки данных, позволяя сосредоточится на самой обработке.
Управление пулом, запуск на выполнение, ожидание завершения - этого всего нет в коде, всё делает reactor. Я думаю, что можно сравнить с управлением транзакциями JDBC vs JPA.
Под капотом всё равно пул потоков, только работу по управлению ими берёт на себя Reactor.