关于Spring Cloud健康检查的陷阱 邮件检查，超时检查

关于Spring Cloud健康检查的陷阱 邮件检查，超时检查

1.排除不必要的健康检查项 有一天调用方突然反馈调不通我们的服务。查看Eureka控制台，发现服务状态是UP。查看服务进程一切正常。束手无策之际，忽然想到会不会是健康检查在作怪，因为Eureka Client判断服务可用与否的依据就是健康检查。而Spring Boot Actuator所有的监控项中的任何一个健康状态是DOWN，那个整体应用的健康状态也是DOWN，这时候调用方就把服务当作不可用。 再次查看http://ip:port/health，果然发现有一项邮件健康检查挂了。 最近项目引入了spring-boot-starter-mail，实现发送邮件的功能。 邮箱服务器挂了，造成整个服务的监控检查状态是DOWN。

由于邮件发送不是核心功能，可以把非核心组件从健康检查中排除，避免造成整个服务不可用。

通过如下配置关闭邮箱健康检查。 management.health.mail.enabled = false 1.使用spring组件发送邮件 需要加上这个配置management.health.mail.enabled = false 2.使用s1.email的服务直接重启服务即可 如果使用的邮件服务器是网易的企业邮件，存在有并发数之类的限制，或者偶尔不稳定。或者卡顿。容易造成health指标异常，引发内部nginx或者eureka下线该服务

2.springcloud-health检查超时引发的大坑 springcloud中默认使用springboot-actauctor的health-url作为健康检测，默认检查的超时时间为10s，如果生产环境遇到网络、db、redis慢或者挂了等问题，会导致health检查请求超时，springcloud注册中心会认为该server异常，从而将server状态变更为critial，服务调用方(feign)会将该异常server从负载中移除(HealthServiceServerListFilter)。 如果遇到某网段或更大规模的网络、db等问题，会导致某个service所有server都被注册中心移除，导致该service不可用。 但是实际上该server只是存在部分问题例如：仅仅是db或redis慢，不算不可用，但还是被注册中心强制摘除了。

通过如下配置关闭health健康检查。 management.health.defaults.enabled = false #关闭health检查后，如果需要某类health检查需求，则需要单独配置 management.health.db.enabled = true management.health.redis.enabled = true