Да, действительно, есть проблема с логированием тела запроса к другому ресурсу, но в нашем случаем мы вполне обходимся логированием входного DTO на уровне клиента (передаваемый как аргумент). Заголовки можно достать через фильтр.
Для входящих запросов мы обходимся логами на UI. Приходится идти на компромиссы.
Только вот это уже не Kotlin, а не пойми что
Например, нет exception-ов.
Тут я вас не понял, это все тот же Kotlin. Exception-ы есть, но также и дополнительный механизм работы с ним. Если вы, к примеру, используете Java Streams — это тоже не Java?
Тоесть вы запускали многопоточное приложение на 1 процессоре и, удивительно, оно работало не очень.
Тут вопрос не в том сколько процессоров, а в том что его утилизация была в районе плинтуса. Мы можем налить туда процессоров, памяти, поднять стоимость эксплуатации, но зачем если можно гораздо эффективнее утилизировать ресурсы.
Отдача кэшированных данных для нас огромная проблема ибо каналов информирования клиента об изменении ключевых данных очень много и клиент, что логично, пытается зайти и увидеть эти данные. Если мы начнем после уведомления показывать старые данные — это проблема.
По circuit breaker.
Это все отлично работает при параллельных запросах, а не последовательных, логика формирования ответа, который зависит от нескольких источников очень сильно усложняется в ситуациях, когда вам нужно поддерживать более 1 версии API с разной логикой и форматом.
Насколько мне известно, это пока единственный вариант поддержки MDC, его мы и используем.
Для варианта с корутинами есть kotlinx-coroutines-slf4j. Пока мы его не пробовали, но что-то мне подсказывает, что там не все так гладко с интеграцией между CoroutineContext и ReactorContext.
Спасибо за отзыв по R2DBC, у нас есть мотивация его протестировать, вероятно будет материал для статьи по этому поводу.
С приходом спецификации Servlet 3.1 мы получили NIO при обработки запросов, но проблема в том, что в WebMVC API до сих пор много блокирующего кода, стандартные модули Spring'а и драйвера в них также блокирующие. По своей сути перехода на контейнеры Servlet 3.1 вообще ничего не меняют, у нас также куча блокировок, но зато теперь мы можем возвращать CompletableFuture в контроллерах…
Конечно можно, но если внешние ресурсы деградируют, то это как снежный ком (старые запросы в ожидании, новые порождают еще большую нагрузку на внешние системы). Очередь будет разрастаться и коннекты начнут отпадать по таймауту на уровне клиента/nginx так и не попав в обработку.
Проблема еще кроется в том, что очередь общая и есть запросы, которые не требуют обращения к внешним ресурсам и быстро обрабатываются. Они также начнут падать. Особенно остро это касается health-чеков k8s, которые отваливались находясь в очереди и прибивали поду.
Да, действительно, есть проблема с логированием тела запроса к другому ресурсу, но в нашем случаем мы вполне обходимся логированием входного DTO на уровне клиента (передаваемый как аргумент). Заголовки можно достать через фильтр.
Для входящих запросов мы обходимся логами на UI. Приходится идти на компромиссы.
Тут я вас не понял, это все тот же Kotlin. Exception-ы есть, но также и дополнительный механизм работы с ним. Если вы, к примеру, используете Java Streams — это тоже не Java?
Тут вопрос не в том сколько процессоров, а в том что его утилизация была в районе плинтуса. Мы можем налить туда процессоров, памяти, поднять стоимость эксплуатации, но зачем если можно гораздо эффективнее утилизировать ресурсы.
По circuit breaker.
Это все отлично работает при параллельных запросах, а не последовательных, логика формирования ответа, который зависит от нескольких источников очень сильно усложняется в ситуациях, когда вам нужно поддерживать более 1 версии API с разной логикой и форматом.
Для варианта с корутинами есть kotlinx-coroutines-slf4j. Пока мы его не пробовали, но что-то мне подсказывает, что там не все так гладко с интеграцией между CoroutineContext и ReactorContext.
Спасибо за отзыв по R2DBC, у нас есть мотивация его протестировать, вероятно будет материал для статьи по этому поводу.
Проблема еще кроется в том, что очередь общая и есть запросы, которые не требуют обращения к внешним ресурсам и быстро обрабатываются. Они также начнут падать. Особенно остро это касается health-чеков k8s, которые отваливались находясь в очереди и прибивали поду.