#spring-boot #spring-boot-actuator
#весенняя загрузка #spring-boot-actuator
Вопрос:
Мы используем привод spring boot для отображения конечных точек работоспособности и готовности при запуске в кластере Kubernetes. По умолчанию привод spring-boot предоставляет конечную точку на стандартном порту HTTP-сервера по умолчанию, где запрос обслуживается пулами-приемщиками Tomcat / Jetty server и пулами рабочих потоков. Недавно мы столкнулись с проблемой во время нашего стресс-тестирования, когда все потоки в рабочем пуле были заняты, а новые запросы ставились в очередь. Это привело к сбою модуля в кластере Kubernetes, поскольку проверки работоспособности начали давать сбой.
Я рассматриваю возможность использования привода на порту управления. Я хотел проверить следующее
a) Обслуживаются ли запросы на порту управления отдельным пулом рабочих потоков (из пула стандартных серверных портов)?
б) Если ответ на а) отрицательный, есть ли способ настроить spring boot на использование отдельного пула потоков для порта управления (мы используем серверы tomcat / jetty и reactive netty в наших различных микросервисах)
Ответ №1:
Да, если вы укажете другой порт управления, Spring / Tomcat будет использовать отдельный пул потоков для обслуживания запросов на этом порту.
Например, если вы укажете что-то подобное, это ваша конфигурация:
server.port=8080
management.server.port=8081
server.tomcat.threads.max=10
Обычные запросы на порт 8080 будут обслуживаться потоками из стандартного пула потоков, который будет иметь в общей сложности 10 потоков ( server.tomcat.threads.max ). Вы увидите имена потоков в своем журнале следующим образом:
... nio-8080-exec-<number from 1 to 10>..
Потоки управления / проверки работоспособности будут обслуживаться потоками из другого пула потоков, общий размер которого также будет равен 10. Вы увидите эти потоки в своем файле журнала следующим образом:
... nio-8081-exec-<number from 1 to 10>..
ПРИМЕЧАНИЕ: выполнение этого, возможно, решит вашу проблему с неудачными проверками работоспособности, которые приводят к перезапуску модулей, однако это может не решить вашу основную причину занятости всех рабочих потоков при всплеске трафика. Возможно, вам нужно изучить что-то вроде ограничения скорости, чтобы справиться с таким сценарием, чтобы ваша служба не получала больше трафика, чем она может обработать.