Реактивный Webflux для переключения сервера - это выгодно?

Question

Нам необходимо реализовать простой сервер переключения (приложение для отдыха), который бы взял имя переключателя и возвращал его, если он включен или отключен. Мы ожидаем загрузку 10 тысяч запросов в день.

Имеет ли смысл Spring (реактивный) webflux здесь?

Насколько я понимаю, реактивный отдых apis будет полезен, если есть вероятность простоя http-потока, то есть потока, ожидающего выполнения какой-либо работы, и он не может продолжаться, пока не получит ответ, как от дБ читает или отдыхает звонки на другие сервисы.

Наш вариант использования - просто вернуть значение переключателя (возможно, из некоторого кэша), которое запрашивается. Будет ли полезен сервис реактивного отдыха в нашем случае? Это дает какие-то преимущества перед простым приложением с весенней загрузкой?

Answer 1

Я исходил из опыта «традиционной» весны / весны- mvc разработки приложений, и в эти дни я также начинаю изучать весенний вебфлюкс и на основании данных, приведенных в этом вопросе, мои наблюдения (отказ от ответственности: поскольку я новичок в этой области, как я уже сказал, примите этот ответ с недоверием):

1. Реализация WebFlux менее "прямолинейна" по сравнению с традиционное применение: затраты на обслуживание выше, отладка сложнее, и т. д. c.

2. WebFlux будет работать, если ваши операции связаны с вводом / выводом. Если вы собираетесь читать данные из кэша в памяти - это не операция ввода-вывода. Я также понимаю, что природа «переключаемых» данных заключается в том, что они не так сильно меняются, но к ним часто обращаются (читают), поэтому сохранение их в некотором кеше памяти действительно имеет смысл, если только вы не создадите что-то огромное, что не будет вписывается в память вообще, но это другая история.

3. WebFlux + netty позволит вам обслуживать одновременно тысяч запросов, tomcat, имеющих традиционные " модель «поток на запрос», по-прежнему допускает 200 потоков + 100 в очереди по умолчанию, если вы превысите эти значения, это не удастся, но netty «выживет». Основываясь на данных, представленных в вопросе, я не вижу, что вы выиграете от netty здесь. 10 тысяч запросов в день кажутся чем-то, что любой сервер может легко обработать, tomcat, jetty, что угодно - здесь вам не нужна такая «высокая нагрузка».

4. Как Я упомянул в пункте "3" WebFlux хорош в одновременной обработке запросов, но вы, вероятно, не получите никакого улучшения производительности по сравнению с традиционным подходом, дело не в скорости, о лучшем использовании ресурсов.

5. Если вы собираетесь читать данные из базы данных и хотите go с webflux, убедитесь, что у вас есть реактивные драйверы для вашей базы данных - при запуске поток, вы должны быть "реактивными" на всем пути, блокировка доступа к БД не имеет смысла.

Итак, суть в том, что на вашем месте, я бы начал с обычного сервера и рассмотрите возможность перехода к реактивному стеку позже (вероятно, это «позже» никогда не наступит, пока ожидания, указанные в вопросах, не изменятся).

Answer 2

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

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