Spring boot Spring boot：用于在管理端口上服务请求的线程池

在Kubernetes集群中运行时，我们使用spring引导执行器来公开活动性和就绪性端点。默认情况下，spring引导执行器在默认的标准HTTP服务器端口上公开端点，请求由Tomcat/Jetty服务器接受器和工作线程池提供服务。我们最近在压力测试期间遇到了一个问题，工作池中的所有线程都很忙，新请求排队。这导致pod在Kubernetes集群中崩溃，因为liveness探测器开始出现故障

我正在考虑将致动器暴露在管理端口上。我想检查以下几点

a） 管理端口上的请求是否由单独的工作线程池（与标准服务器端口的工作线程池不同）提供服务

---

b） 如果a）的答案是否，是否有办法将spring boot配置为使用单独的线程池作为管理端口（我们在不同的微服务中使用tomcat/jetty和反应式netty服务器）

是，如果您指定不同的管理端口，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>..

... nio-8081-exec-<number from 1 to 10>..

。。。nio-8080-exec-。。

管理/运行状况检查线程将由来自不同线程池的线程提供服务，该线程池的总大小也将为10。您将在日志文件中看到如下线程：

... nio-8080-exec-<number from 1 to 10>..

... nio-8081-exec-<number from 1 to 10>..

。。。nio-8081-exec-。。

注意：这样做可能会解决运行状况检查失败导致POD重新启动的问题，但是它可能无法解决流量突发时所有工作线程被占用的根本原因。也许您需要研究一些类似于速率限制的方法来处理这种情况，这样您的服务就不会获得超出其处理能力的流量