Комментарии 21
Понять, что именно происходит в процессе исполнения программы, даже опытному разработчику, достаточно сложно.
А вот так можно увидеть ваш код в IntelliJ IDEA и всё-таки понять, что происходит
https://www.jetbrains.com/help/idea/reactor.html#reactor-debug
Виртуальные потоки не пробовали? Я понимаю что они когда-то потом, а надо сейчас, но всё же.
Про Project Loom? Сыроват пока, но у нас много кода на kotlin coroutines, бизнес логика на корутинах значительно приятнее, чем на реакторе. В библиотеках всё равно больше reactor, никуда от него со спрингом не денешься
Виртуальные потоки - это не альтернатива реактивным стримам, уровень абстракции другой.
Я про решение изначальной задачи, а не про инструмент.
Наличие или отсутствие виртуальных потоков в используемой JVM по большому счёту безразличны прикладному программисту, мы просто продолжим так же писать реактивные стримы, а Spring Ractor или Akka у себя под капотом сами решат использовать системный поток или легковесный для выполнения наших стримов. Поэтому вопрос про виртуальные потоки лучше задавать системщикам, вроде Олега Докука или Йонаса Бонэра.
переписанный на Реактив тот же самый код уже требует значительно больше знаний. Обрастает «служебными» методами типа .blockLast. И вдобавок плохо читается.
Это спорно. В большой кодовой базе декларативные стримы читаются намного проще императивной лапши. Особенно в случае многопоточного кода.
Я пробовал реактивное программирование - бизнес логика уходит в сторону и ты постоянно пытаешься понять как оно работает. У меня до сих пор сомнение такого рода: разве не проще добавить еще пару инстансов сервиса, чем мучить разработчиков реактивщиной.
Не делали расчетов что дешевле: добавить железа или переработка сервиса? Мне кажется в альфабанке не такие большие нагрузки, относительно))
бизнес логика уходит в сторону и ты постоянно пытаешься понять как оно работает
Советую котлин с корутинами попробовать. Профит тот же, но выглядит более читаемо. У нас сейчас бизнес логика в основном пишется на корутинах. А служебные вещи все равно на реакторе, потому что comment_25449698.
разве не проще добавить еще пару инстансов сервиса, чем мучить разработчиков реактивщиной
У нас достаточно большая разработка, чтобы написать много реактивных библиотек, которые решают стандартные проблемы, а разработчики в командах уже собирают из этих "кубиков" свои сервисы, то есть не с нуля. Соотношение затрат на реактив к количеству микросервисов окупается. На самом деле с реактивом "было непонятно, потом привыкли", но порог вхождения высокий, согласна.
Не делали расчетов что дешевле
Не делали :)) было бы интересно, да. В целом конечно, можно залить апишку ресурсами "на все случаи жизни", но тут непонятно, когда останавливаться. Обычно это не + 2 инстанса, а штук 16. Случилась маркетинговая акция и опять микросервис захлебнулся. Реактивные сервисы в этом смысле значительно лучше справляются. Когда в кубернетис окончательно переедем, он нам автоскейл будет делать по нагрузке, чтобы не отапливать дата центры своей бизнес логикой, в ожидании гипотетической пиковой нагрузки.
Мне кажется в альфабанке не такие большие нагрузки
относительно, да. Есть на 7к RPS сервисы
Спасибо за ответ. Расскажите подробнее что значит реактивные библиотеки? Вернее как они используются? Потому что вызов реактивной библиотеки на мой взгляд ничем не отличается от вызова другой блокирующей функции. Не очень понятно, что можно вынести туда (в библиотеки) и как это облегчит прикладную разработку
Бизнес-логика уходит в сторону от непривычки описывать её в форме потоков данных. В былые времена такой же эффект наблюдался у опытных программистов переходивших на ООП. Что касается простоты добавления инстансов, у нас реактивная версия одного из микросервисов способна одним инстансом прожёвывать без ошибок 400 RPS, потребляя при этом 512 Mb хипа, а обычная жрала 7-ю инстансами 21 Gb, обрабатывала до 20 RPS и при этом ещё периодически падала по OOM. Как тяжело было рассмотреть бизнес-логику в императивной версии высококонкурентного кода, обрабатывающего огромное число возможных проблем взаимодействия с десятком интеграций, не стоит даже заикаться.
и как только для какого-то ранее приостановленного реактивного стрима приходит событие о том, что ввод или вывод окончен (то есть мы дождались или отправили данные)...
…поток продолжает выполнять логику этого стрима.
@Taruf Может я ошибаюсь, но в данной части статьи, описывающей отличие реактивного подхода от блокирующего, отсутствует фраза вроде "реактивные стримы, ожидающие длительного ввода-вывода, приостанавливаются и управление передаётся другому стриму". Можно как-то поподробнее раскрыть суть вопроса?
Вы хотите сказать
Что
HandleTest::withoutHandle
Менее читаем и не понятен чем
HandleTest::withHandle???
В описании метода subscribeOn:
Для первых четырех сообщений метка “after” соответствует потоку Test worker, а метка “before” — потоку пула parallel.
Как такое возможно, когда, судя по логу, потоку Test worker соответствуют первые два сообщения?
Зачем нам Reactive и как его готовить