Лучшая практика при использовании подписки и публикации

Question

Я использую Project Reactor для нового сервиса, который пишу.Я использую Spring 5 с Netty.Я взаимодействую с кучей разных сервисов и реляционной базой данных.У всех этих служб есть клиент, который блокирует, и JDBC также блокирует.Поэтому, по сути, ни один из этих сетевых вызовов не возвращает издателя.

Мой вопрос заключается в том, что должно быть наилучшей практикой при работе со всеми блокирующими API.В настоящее время все, что я сделал, обернуло весь код блокировки API в Mono.callable и использовал subscribeOn(Scheduler.elastic()).Таким образом, по существу вся работа по блокировке выполняется на пуле эластичных нитей.

Вопрос 1. Должен ли я создавать выделенного исполнителя пула потоков, а не использовать эластичный?Если да, то почему?Или я должен создать выделенный эластичный пул для каждого отдельного сервиса?

Вопрос 2. Когда метод блокировки возвращает результат, я должен использовать publishOn, чтобы основной поток возобновил обработку снова?Если да, то как мне вернуть ссылку на основной поток (поток цикла событий netty?)?

Вопрос 3. Если я вызываю несколько блокирующих вызовов для нескольких разных операторов (некоторые во время цепочки, некоторые при использовании zip() call), затем при использовании subscribe publish и снова subscribe publish не приведет к значительному переключению контекста?

Большинство этих вопросов связаны с тем, что должно быть наилучшей практикой.

Answer 1

Я не совсем уверен в преимуществах, которые вы можете получить, используя WebFlux в вашем конкретном случае, поскольку все ваши конечные сервисы блокируются.

1: В основном вам следуетпринять решение на основе вашего конкретного оборудования и целевого поведения.Как следует из официальных документов, Java Reactor не зависит от параллелизма.Это означает, что вы можете свободно использовать любой параллелизм или вообще не использовать его.Насколько я знаю, elastic pool использует простой ExecutorService под капотом.Я полагаю, вам следует принять решение на основе вашего конкретного оборудования, слишком много переключений контекста и потоков не очень хорошо с точки зрения производительности, особенно если у вас недостаточно процессоров

2: В основном нет, зависит от того, какое поведение вам нужно.

3: Вы должны прояснить себя, я не понимаю, почему вы называете такую ​​цепочку publish - subscribe.