Приложение 1 отправляет запрос в приложение 2. Приложение 2 выполняет следующие шаги и возвращает ответ приложению 1. Мне интересно, может ли приложение 2 извлечь выгоду из использования реактивных библиотек, таких как RxJava, Reactor и т. д. Если да, объясните, как?
Это самый классический вариант использования реактивных библиотек, какой только можно найти! :)
Ключевой частью «реактивных» архитектур является то, что они могут реагировать на события, а не ждать результатов. RxJava упрощает это с помощью Observable, а Reactor делает это с помощью нескольких различных механизмов. В Reactor вы можете использовать простой Reactor и установить replyTo на Event, вы можете использовать Stream или Promise для составления цепочки обработки значений, очень похожей на Observable в RxJava, вы можете использовать Processor для высокоскоростной обработки RingBuffer. , или вы можете использовать ForkJoinPool для выполнения простой обработки в стиле fork/join. Конечно, вариантов много, но каждый из них предназначен для работы в конкретном случае без ущерба для других вариантов использования. Рамка Reactor — это не один разводной ключ. Это набор ключей, размер которых точно соответствует вашим потребностям.
В этом конкретном случае важной частью является параллелизм, достигаемый за счет выполнения большого количества работы одновременно, поскольку ваш источник данных IO предположительно блокирует поток. RxJava имеет подключаемую модель выполнения, но она довольно грубая. Одной из сильных сторон Reactor является эффективная, детализированная поддержка диспетчеризации задач и легкость, с которой вы можете реагировать на результаты.
Поскольку ваш вариант использования довольно прост и намного ближе к стандартной ситуации ThreadPoolExecutor, у меня может возникнуть соблазн использовать ForkJoinPool в Reactor 1.1 (совершенно новый). ForkJoinPool предоставляет вам единый Promise<ImmutableList<T>>, который объединяет результаты всех задач, которые вы отправляете в пул, поддерживаемый стандартным ThreadPoolExecutor. По сути, это «реактивная» оболочка для стандартного пула потоков, поэтому требует очень мало накладных расходов, но обеспечивает гибкость реагирования на выполнение всех отправленных задач. Это похоже на Observable.merge() RxJava.
join вам может понадобиться метод fork, который дает вам Stream, на котором вы можете установить обработчик when() для ошибок и обычный Consumer для результатов. Вы должны были бы сами следить за бухгалтерией, чтобы знать, сколько результатов вы получили по сравнению с тем, сколько вы ожидали. Поддержка Reactor Spring также имеет реализацию AsyncListenableTaskExecutor, в которой используется настроенный вами Reactor Dispatcher. Это, вероятно, лучший вариант для больших объемов, поскольку обычный пул потоков довольно неэффективен при высокой нагрузке.
- person Jon Brisbin; 29.05.2014
reactive, но я хочу добавить немного шума. В EIP он вызываетsplit-aggregate, а Spring Integration предоставляет это готовое решение. В этом случае сплиттер может отправлять элементы вThreadPoolExecutorили, если хотите, в Reactor или просто в RingBuffer. Каждыйdata source serviceдолжен отправить свой результатaggregator, а последний просто отправляет объединенный ответ. - person Artem Bilan schedule 28.05.2014