architecture - 在不同的端口上设置健康检查地址而不是使用不同的路径有什么好处?

标签 architecture microservices health-monitoring

当我搜索微服务架构的最佳实践时,有时会使用与应用程序不同的端口作为健康检查地址。这对微服务来说是一种好的做法吗?这种方法的优缺点是什么?

最佳答案

如果您为健康检查 API 使用不同的端口和隔离的连接池,将会受益。
重请求下 => 应用连接池已满 => 健康检查 API 无法获取进程 => k8s 无法健康检查应用 => 确定应用不可用 => k8s 杀死应用 => 这可能会给你一个更多降级性能。

关于architecture - 在不同的端口上设置健康检查地址而不是使用不同的路径有什么好处?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45374744/

相关文章:

C# MVC 和 Web API 应用程序架构

web-applications - 为移动和 Web 应用程序设计通用服务器端

java - 如何为 Dockerized SpringBoot REST jar 执行指定 JVM 参数列表

java - Spring Boot HealthIndicator 示例

elasticsearch - 部分查询结果归因于Elasticsearch集群运行状况为黄色

docker - 如何在 consul 容器中为同一主机上的服务定义 HTTP 健康检查?

architecture - 使用 Entity Framework 4 和存储库模式的多层架构

node.js - nodejs 代表的是 Reactor 还是 Proactor 设计模式?

python - 从 Golang 调用 Python 任务

spring-boot - 什么是微服务的资源服务器?