Как мыслить в режиме реактивного программирования и преобразовывать традиционное упс-приложение в реактивное приложение - PullRequest
0 голосов
/ 27 января 2020

Традиционным способом написания приложения я разделил приложение на набор задач и выполняю их последовательно.

  1. Получить список правил для данной группы правил от Redis
  2. Построить ввод фактов и запустить правила.
  3. вычислить ответ на запрос, нажав несколько правила (группа правил A может зависеть от результата группы правил B).
  4. отправить ответ обратно вызывающей стороне.

Если бы я должен был выполнить вышеупомянутые шаги, используя пружинную сеть Быстро реагирующим образом, как мне этого добиться?

  1. Я использовал ReactiveRedis для получения данных из redis. ReactiveRedisOperations.opsForValue (). Get (ruleGroupName) не возвращает ничего, пока мы не подпишемся на него (). Но ReactiveRedisOperations.opsForValue (). Get (ruleGroupName) .subscribe () делает поток обработки реактивным, и выполнение переходит на следующую строку в приложении, не ожидая выполнения подписчиком.

  2. Поскольку мои следующие шаги зависят от данных, возвращаемых Redis, я использовал опцию block (), чтобы заставить его ждать.

В реальном мире как справиться с такой ситуацией? Заранее благодарим.

PS: новинка в разработке веб-потоков и реактивного программирования.

1 Ответ

0 голосов
/ 28 января 2020

Вместо разделения логических шагов путем помещения их в новую строку, как в императивном программировании, реактивное программирование использует композицию методов и цепочку (операторы).

Так что, как только вы получите Flux<T> или Mono<T> (здесь ваши правила от Redis), вам нужно объединить операторы для создания ваших шагов обработки декларативным способом.

Шаг, который преобразует каждый элемент ввода <T> в один соответствующий элемент <R> в памяти и без задержки обычно выражается как map(Function<T, R>) и выдает Flux<R>. В свою очередь, цепочка дополнительных операторов на этом.

Шаг, который либо преобразует 1 элемент <T> в N элементов <R> и / или делает это асинхронно (ie преобразование возвращает Flux<R> для каждого T) обычно выражается как flatMap(Function<T, Publisher<R>>).

Кроме того, в Reactor имеется богатый словарь специализированных операторов, которые вы можете исследовать .

В конце Ваша цель состоит в том, чтобы связать всех этих операторов, чтобы описать ваш конвейер обработки, который будет Mono<RETURN_TYPE> или Flux<RETURN_TYPE>. RETURN_TYPE в webflux может быть бизнес-типом, который Spring может маршалировать, или одним из классов, ориентированных на ответ Spring.

...