бизнес логика уходит в сторону и ты постоянно пытаешься понять как оно работает
Советую котлин с корутинами попробовать. Профит тот же, но выглядит более читаемо. У нас сейчас бизнес логика в основном пишется на корутинах. А служебные вещи все равно на реакторе, потому что comment_25449698.
разве не проще добавить еще пару инстансов сервиса, чем мучить разработчиков реактивщиной
У нас достаточно большая разработка, чтобы написать много реактивных библиотек, которые решают стандартные проблемы, а разработчики в командах уже собирают из этих "кубиков" свои сервисы, то есть не с нуля. Соотношение затрат на реактив к количеству микросервисов окупается. На самом деле с реактивом "было непонятно, потом привыкли", но порог вхождения высокий, согласна.
Не делали расчетов что дешевле
Не делали :)) было бы интересно, да. В целом конечно, можно залить апишку ресурсами "на все случаи жизни", но тут непонятно, когда останавливаться. Обычно это не + 2 инстанса, а штук 16. Случилась маркетинговая акция и опять микросервис захлебнулся. Реактивные сервисы в этом смысле значительно лучше справляются. Когда в кубернетис окончательно переедем, он нам автоскейл будет делать по нагрузке, чтобы не отапливать дата центры своей бизнес логикой, в ожидании гипотетической пиковой нагрузки.
Мне кажется в альфабанке не такие большие нагрузки
Да, верно. Суть в том, что один поток обрабатывает множество реактивных стримов и один реактивный стрим может "прыгать" между разными потоками. Один кусочек задачи на одном потоке, другой на другом
По поводу многопоточного кода согласна, реактор более читаемый, чем коллбэки и синхронизация. Я скорее предлагаю задумываться, зачем реактивщина в моменте, а не гнаться за модным решением. Не забивать гвозди микроскопом
Про Project Loom? Сыроват пока, но у нас много кода на kotlin coroutines, бизнес логика на корутинах значительно приятнее, чем на реакторе. В библиотеках всё равно больше reactor, никуда от него со спрингом не денешься
Советую котлин с корутинами попробовать. Профит тот же, но выглядит более читаемо. У нас сейчас бизнес логика в основном пишется на корутинах. А служебные вещи все равно на реакторе, потому что comment_25449698.
У нас достаточно большая разработка, чтобы написать много реактивных библиотек, которые решают стандартные проблемы, а разработчики в командах уже собирают из этих "кубиков" свои сервисы, то есть не с нуля. Соотношение затрат на реактив к количеству микросервисов окупается. На самом деле с реактивом "было непонятно, потом привыкли", но порог вхождения высокий, согласна.
Не делали :)) было бы интересно, да. В целом конечно, можно залить апишку ресурсами "на все случаи жизни", но тут непонятно, когда останавливаться. Обычно это не + 2 инстанса, а штук 16. Случилась маркетинговая акция и опять микросервис захлебнулся. Реактивные сервисы в этом смысле значительно лучше справляются. Когда в кубернетис окончательно переедем, он нам автоскейл будет делать по нагрузке, чтобы не отапливать дата центры своей бизнес логикой, в ожидании гипотетической пиковой нагрузки.
относительно, да. Есть на 7к RPS сервисы
Да, верно. Суть в том, что один поток обрабатывает множество реактивных стримов и один реактивный стрим может "прыгать" между разными потоками. Один кусочек задачи на одном потоке, другой на другом
По поводу многопоточного кода согласна, реактор более читаемый, чем коллбэки и синхронизация. Я скорее предлагаю задумываться, зачем реактивщина в моменте, а не гнаться за модным решением. Не забивать гвозди микроскопом
Можно, конечно. Но иногда нужно что-то к вебфлаксу доделать вроде фильтра для логирования, например
Про Project Loom? Сыроват пока, но у нас много кода на kotlin coroutines, бизнес логика на корутинах значительно приятнее, чем на реакторе. В библиотеках всё равно больше reactor, никуда от него со спрингом не денешься