问题描述
您知道(如果可能)如何在Spring Boot微服务中为特定端点保留线程/内存吗?
Do you know (if it is possible) how to reserve threads/memory for a specific endpoint in a spring boot microservice?
我有一个微服务，它通过Spring MVC接受 HTTP请求，这些请求触发了对第三系统的http调用.部分降级，并且响应速度非常慢.我无法减少超时时间，因为有些电话本来就很慢.
I've one microservice that accepts HTTP Requests via Spring MVC, and those requests trigger http calls to 3rd system, which sometimes is partially degraded, and it responds very slow. I can't reduce the timeout time because there are some calls that are very slow by nature.
我已启用spring-boot-actuator /health 端点，并且像 kubernetes集群中的容器 livenessProbe 一样使用它强>.有时，当第三个系统降级时，微服务不会响应/health端点，而kubernetes会重新启动我的服务.
I've the spring-boot-actuator /health endpoint enabled and I use it like a container livenessProbe in a kubernetes cluster. Sometimes, when the 3rd system is degraded, the microservice doesn't respond to /health endpoint and kubernetes restarts my service.
这是因为我正在使用 RestTemplate进行HTTP调用，所以我不断创建新线程，并且JVM开始出现内存问题.
This is because I'm using a RestTemplate to make HTTP calls, so I'm continuously creating new threads, and JVM starts to have problems with the memory.
我已经考虑过一些解决方案:
I have thought about some solutions:
-
实现高可用性"/health"端点，保留线程或类似的东西.
Implement a high availability "/health" endpoint, reserve threads, or something like that.
使用异步http客户端.
Use an async http client.
安装断路器.
为我正在使用的每个第3个端点配置自定义超时.
Configure custom timeouts per 3rd endpoint that I'm using.
创建其他小型服务(golang)并将其部署在同一吊舱中.该服务将处理活动性探查.
Create other small service (golang) and deploy it in the same pod. This service is going to process the liveness probe.
将服务迁移/重构为小型服务，并可能与其他框架/语言(如Vert.x，go等)一起迁移/重构.
Migrate/Refactor services to small services, and maybe with other framework/languages like Vert.x, go, etc.
您怎么看?
非常感谢.
推荐答案
执行器运行状况终结点使用Spring Boot非常方便-在这种情况下，它实在太方便了，因为它执行了比活动性探针所必需的更深入的运行状况检查.为了准备就绪，您想做更深入的检查，而不是活泼性.这个想法是，如果Pod有点不知所措并且无法就绪，那么它将从负载平衡中退出并喘口气.但是，如果失败，它将重新启动.因此，您只需要进行最少的活动检查(应该进行的健康检查是否会调用其他App Health检查).通过同时使用执行器健康状况，繁忙的Pod无法在他们首先被杀死时获得喘息的机会. kubernetes在执行这两个探测时会定期调用http端点，这进一步加剧了您的线程使用问题(请考虑探测上的periodSeconds).
The actuator health endpoint is very convenient with Spring boot - almost too convenient in this context as it does deeper health checks than you necessarily want in a liveness probe. For readiness you want to do deeper checks but not liveness. The idea is that if the Pod is overwhelmed for a bit and fails readiness then it will be withdrawn from the load balancing and get a breather. But if it fails liveness it will be restarted. So you want only minimal checks in liveness (Should Health Checks call other App Health Checks). By using actuator health for both there is no way for your busy Pods to get a breather as they get killed first. And kubernetes is periodically calling the http endpoint in performing both probes, which contributes further to your thread usage problem (do consider the periodSeconds on the probes).
对于您的情况，您可以定义活动命令而不是http探针- https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command .该命令仅可以检查Java进程是否正在运行(有点类似于基于go的探测建议).
For your case you could define a liveness command and not an http probe - https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#define-a-liveness-command. The command could just check that the Java process is running (so kinda similar to your go-based probe suggestion).
在许多情况下，使用执行器来保持活动状态会很好(请考虑在线程之前遇到不同约束的应用程序，如果您使用反应堆进行异步/非阻塞操作，情况就是这样).您所在的位置可能会引起问题-执行器对诸如消息代理之类的依赖项进行可用性的探查可能是您重新启动过多(在这种情况下是首次部署)的另一个原因.
For many cases using the actuator for liveness would be fine (think apps that hit a different constraint before threads, which would be your case if you went async/non-blocking with the reactive stack). Yours is one where it can cause problems - the actuator's probing of availability for dependencies like message brokers can be another where you get excessive restarts (in that case on first deploy).
这篇关于Kubernetes活动-使用Spring Boot为特定端点保留线程/内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！