一、背景介绍

一些应用进程由于负载比较高，导致服务能力降低，如服务的接口响应高，错误率高等。我们希望能够从系统层面自动规避这种故障，达到自愈的效果。

目前我们的服务是基于Springcloud生态进行开发，主要部署在K8S上，经过调研分析，最终确定通过K8S的探针机制与Ribbon的超时重试机制解决。下面详细描述。

二、利用K8S自身健康检查机制

结论：可行

原因：提供了接口超时的重启或移除endpoint策略，是符合我的预期的

参考：

Kubernetes重启策略+健康检查详解 - 杰宏唯一 - 博客园

Pod 两种探针介绍

1、LivenessProbe（存活探针）： 存活探针主要作用是，用指定的方式进入容器检测容器中的应用是否正常运行，如果检测失败，则认为容器不健康，那么 Kubelet 将根据 Pod 中设置的 restartPolicy （重启策略）来判断，Pod 是否要进行重启操作，如果容器配置中没有配置 livenessProbe 存活探针，Kubelet 将认为存活探针探测一直为成功状态。

2、ReadinessProbe（就绪探针）： 用于判断容器中应用是否启动完成，当探测成功后才使 Pod 对外提供网络访问，设置容器 Ready 状态为 true，如果探测失败，则设置容器的 Ready 状态为 false。对于被 Service 管理的 Pod，Service 与 Pod、EndPoint 的关联关系也将基于 Pod 是否为 Ready 状态进行设置，如果 Pod 运行过程中 Ready 状态变为 false，则系统自动从 Service 关联的 EndPoint 列表中移除，如果 Pod 恢复为 Ready 状态。将再会被加回 Endpoint 列表。通过这种机制就能防止将流量转发到不可用的 Pod 上。

由以上探针得知：

1、存活探针会将探测不存活的容器Kill再启动

• 这样会导致一种情况：pod只是暂时由于某种原因而压力大，如CPU负载突增导致服务能力差，但是可能一会就好了，这样如果重启或导致正在处理的数据失效，从而可能导致数据不一致

2、就绪探针会将异常的容器从Service列表中移除

• 缺点是：当某个容器就是异常了，且无法恢复，处于一种假死状态，容器就废了

结论：

两者可以同时结合使用，使用方式如下：

1、存活探针可设置检测间隔长一些，检测次数多一些，确定容器长时间异常则重启

2、就绪探针可设置检测间隔短一些，检测次数少一些，发现服务有异常就暂时下线，以免持续访问造成更严重的后果，如导致亚健康应用处理异常状态

三、SpringCloud内部的健康检测机制

以上的K8S探针机制，解决了外部访问应用的问题，那么基于eureka内部直接访问如何处理？这是不经过Service的！

解决方案可以是利用ribbon超时重试和eureka心跳检测

eureka心跳检测：剔除异常下线的应用。当客户端没有定期上报心跳，则会被剔除

ribbon超时重试：客户端超时，进行本实例重试或者跨实例重试