А можно чуть подробнее про R2DBC? Вопрос для нас действительно актуальный. Насколько проседает производительность, есть ли бенчмарки по R2DBC?
И что с ним в плане стабильности? Недавно вышел spring boot 2.3 в него как раз вошел r2dbc, по всей видимости ребята из pivotal посчитали его готовым к использованию в продакшене.
Не впервые слышу про медлительность R2DBC, но пока не видел тому подтверждений, при все этом его использование много приятнее альтернатив учитывает интеграцию со spring data.
В общем случае null <> ошибка. Конечно, можно это обойти, но выглядеть это в модели данных будет не очень.
Основной набор данные фронт получает от одного бека, который в свою очередь при необходимости ходит к другим сервисам, поэтому с форматами ошибок проблем нет.
Подождать ответа на беке можно, но вы как-то забыли о клиенте в этой истории, а он будет все это время ждать отрисовки страницы, хотя ему возможно и не нужна та информация, которая предоставляется затупившим сервисом.
Вообще это конечно две крайности (1 эндпоит который тащит все vs 100500 эндпоинтов на каждый чих), а правда я считаю находится где-то посередине и это разумное разделение, при котором фронт может запросить ровно те данные, которые ему нужны в данный момент.
При нормальных условия все работает хорошо, но, к сожалению, мир не идеален и в любой момент что-то может пойти не так, например деградация одного или нескольких сервисов, к которым мы делаем запросы.
Конечно же можно залить это ресурсами, если таковых хватит, но эффективность использования ресурсов при этом упадет ниже плинтуса.
Если последовать вашему же совету и посмотреть информацию о потоках в момент проблемы, то можно увидеть кучу тредов которые просто ждут ответа от проблемного апстрима и, кроме этого, ничего полезного не делают.
Кстати, подобную, пусть и не такую драматическую картину с потоками можно увидеть и в нормальной ситуации, если у вас много внешних вызовов.
При использовании webflux и неблокирующих операций мы эффективнее используем потоки, они не висят в ожидании ответа от сервиса, но начинают обслуживать другие запросы и затуп одного апстрима не повлияет на скорость работы той части системы, которая с ним не связана.
Не понял, что же правильно в том, что рабочее приложение ложится по health check? Мы же тем самым только усугубляем ситуацию.
Что касается множества запросов, то этим мы:
Ускоряем загрузку фронта. Когда мы получаем всю информацию для страницы в одном запросе, то время ответа будет равно времени самого медленного ресурса, к которому мы сходили за данными, в нашем же случае фронт отрисовывается по мере получения порций данных.
Отказоустойчивость. Если один из ресурсов так и не ответил — не беда, мы отрисуем страницу с доступной информацией и покажем клиенту, что вот эти данные сейчас недоступны попробуйте позже.
При запуске java в докере имеет смысл посмотреть на такие параметры как -XX:MaxRAMPercentage=75 -XX:MinRAMPercentage=75. При правильном подборе этих параметров при необходимости изменить размер памяти достаточно будет поменять только лимиты докера, не меняя при этом Xmx
И что с ним в плане стабильности? Недавно вышел spring boot 2.3 в него как раз вошел r2dbc, по всей видимости ребята из pivotal посчитали его готовым к использованию в продакшене.
Не впервые слышу про медлительность R2DBC, но пока не видел тому подтверждений, при все этом его использование много приятнее альтернатив учитывает интеграцию со spring data.
Основной набор данные фронт получает от одного бека, который в свою очередь при необходимости ходит к другим сервисам, поэтому с форматами ошибок проблем нет.
Подождать ответа на беке можно, но вы как-то забыли о клиенте в этой истории, а он будет все это время ждать отрисовки страницы, хотя ему возможно и не нужна та информация, которая предоставляется затупившим сервисом.
Вообще это конечно две крайности (1 эндпоит который тащит все vs 100500 эндпоинтов на каждый чих), а правда я считаю находится где-то посередине и это разумное разделение, при котором фронт может запросить ровно те данные, которые ему нужны в данный момент.
Конечно же можно залить это ресурсами, если таковых хватит, но эффективность использования ресурсов при этом упадет ниже плинтуса.
Если последовать вашему же совету и посмотреть информацию о потоках в момент проблемы, то можно увидеть кучу тредов которые просто ждут ответа от проблемного апстрима и, кроме этого, ничего полезного не делают.
Кстати, подобную, пусть и не такую драматическую картину с потоками можно увидеть и в нормальной ситуации, если у вас много внешних вызовов.
При использовании webflux и неблокирующих операций мы эффективнее используем потоки, они не висят в ожидании ответа от сервиса, но начинают обслуживать другие запросы и затуп одного апстрима не повлияет на скорость работы той части системы, которая с ним не связана.
Не понял, что же правильно в том, что рабочее приложение ложится по health check? Мы же тем самым только усугубляем ситуацию.
Что касается множества запросов, то этим мы: