Comments 20
Описанное в статье может показаться преувеличением, но в реальности все именно так и есть! У нас архитекторы приняли решение все делать реактивным как раз "чтобы быть готовыми к большим нагрузкам"… Разгребаем до сих пор.
P.S. Ещё один момент не освещенный в статье: если метод возвращает Mono — то просто протестировать, что к этому методу было обращение уже не достаточно. Так как если на этом методе никто не сделал subscribe (явно или "встраивая" его в реактивный pipeline) то вызван он по сути в итоге и не будет. Для таких случаев просто проверять обращение к методу с помощью mockito уже бесполезно и нужно дополнительно добавлять в тесты PublisherProbe (о чем мы, конечно же, не знали и огребли ещё кучу проблем, когда мигрировали старый код, полностью покрытий тестами).
"если метод возвращает Mono" — должно было быть "если метод возвращает Mono<Void>"
Реактивщина отлично заходит на IO bounded задачах. И чего мелочиться с примерами — можно завернуть все в к8с с истио и считать все в хадупе. Чтобы показать какой великолепный и понятный подход плодить на каждый веб запрос по реквесту :)
Вы, и комментаторы выше, хором твердите про то, что мы бесплатно получаем back pressure. Я не очень понимаю, каким именно образом, если честно. Иными словами, что случится, если на восьмиядерной машине придет запрос инвертировать девять деревьев? Flux
разрулит?
Спору нет, это все гораздо разумнее, чем синхронно долбиться в стену, но чтобы сдерживать back pressure нужен, как минимум, отдельный поток/процесс, просто от переписывания все в реактивненьком стиле чуда не произойдет.
Или я чего-то не понимаю? (Я просто джаву/шарп в последний раз нюхал лет 15 назад и подотстал, но мне действительно интересно).
Отдельный поток/процесс нужен не для того, чтобы сдерживать back pressure, а чтобы проблема back pressure вообще появилась. В однопоточном синхронном коде back pressure работает просто по построению.
В однопоточном синхронном коде back pressure работает просто по построению.
Мы, наверное, разные вещи называем back pressure. Представьте себе сокет, синхронный, в который льется больше, чем приемник может обработать (не вычитать, а именно обработать). Рано или поздно передатчик захлебнется и отвалится. Чтобы этого не произошло, изобретают механизмы противодействия.
Это зависит от того как передатчик написан. Да, он может не суметь обработать back pressure и из-за этого отвалиться, но сам back pressure от этого же никуда не девается.
Передатчик обычно не наш, а если и наш — это вообще не его дело. «Я вот вам поставляю продукты бесперебойно, вы уж там сами как-нибудь со своим складом разберитесь.»
У нас очень много такого типа задач, и это всегда решается тем, что мы принимаем все, чтобы не возникало пробок вне нашего контроля, а потом разгребаем всеми доступными потоками. Иногда приходится даунскейлиться на менее тщательную обработку, и т. п. Просто «потоками» и «асинхронностью» bask pressure не решается чуть более, чем никак.
Ненормальное реактивное программирование