SpringCloudAlibabaNacos作为注册中心，不仅提供了服务注册和服务发现功能，还提供了服务可用性监控的机制。通过这种机制，Nacos可以感知服务的健康状态，从而为服务调用者提供一个健康的服务实例，最终保证业务系统的正常执行。两种健康检查机制Nacos提供两种健康检查机制：客户端主动上报机制。服务器端反向检测机制。如何理解这两种机制？想象这样一个场景，你所在的地区突然发生地质灾害，你被掩埋在废墟之下。搜救队必须知道你在废墟中才能营救你。那么有什么办法可以让救援队知道你在废墟下呢？第一个，你喊救命！帮助！我在这里！在废墟中让搜救队知道你的位置和健康状况。第二种情况是，搜救队使用他们专门的检查设备检测到你被埋在废墟下。以上两种方式类似于Nacos的两种健康检查机制，即客户端主动上报机制，即客户端每隔一定时间主动向Nacos服务器上报自身的健康状态，而服务器端反向检测机制是Nacosserver检测客户端是否健康。如何建立健康检查机制？Nacos中的健康检查机制不能主动设置，但是健康检查机制与Nacos的服务实例类型强相关。也就是说Nacos中的两个服务实例对应两种健康检查机制：临时实例（也叫非持久实例）：对应客户端的主动上报机制。Permanentinstance（也叫persistentinstance）：服务端的逆向检测机制。为什么我们需要两个服务实例？以淘宝为例。双十一促销期间，客流量会比平时高很多。这时候服务就必须增加更多的实例来应对高并发。这些实例在双十一之后将不再需要使用。临时示例更合适。对于一些常备实例的服务，使用永久实例更为合适。客户端主动上报机制临时实例每5秒主动上报一次健康状态。发送的数据包称为心跳包，发送心跳包的机制称为心跳机制。如果心跳包间隔超过15秒，Nacos服务器会将服务实例标记为不健康实例，如果心跳包超过30秒，Nacos服务器会将服务实例从服务列表中删除丢失。运行Nacos项目时，可以看到客户端主动上报心跳包的日志，如下图：从上图可以看出，Nacos客户端每隔5秒就会上报一次自己的健康状态，请求信息如下：/nacos/v1/ns/instance/beat?app=unknown&namespaceId=public&port=8081&clusterName=DEFAULT&ip=192.168.3.72&serviceName=DEFAULT_GROUP@@spring-cloud-nacos-producer2服务端反向永久实例使用的检测机制健康检查是通过检测的方式实现的。它的检测周期是2000毫秒+随机数（5000毫秒以内）。如果检测到异常，服务实例将被标记为不健康实例，但不会将服务实例视为临时实例来删除。Nacos服务器反向检测目前内置了3种检测协议：HTTP检测、TCP检测和MySQL检测。一般来说，HTTP和TCP检测已经可以覆盖绝大部分的健康检查场景。MySQL主要用于特殊的业务场景。比如主备库需要通过服务名对外提供访问，需要判断当前访问的数据库是否为主库，那么此时我们的健康检查界面就是一条MySQL命令，检查数据库是否为主库。TCP检测永久实例默认使用TCP检测，可以在Nacos控制台观察，如下图：默认使用IP端口检测，如下图：的一般逻辑TCP检测是通过与注册实例建立通道，不断ping注册实例的端口来判断实例是否健康。HTTP检测HTTP检测需要在Nacos控制台手动配置，如下图：我们在服务实例中添加检测接口的实现代码：此时我们重启服务实例，在服务详情中，可以看到我们配置的HTTP检测已经完成生效后，可以检查实例是否健康，如下图：Nacos服务器通过检查HTTP是否正常来判断实例是否健康接口返回200状态码。集群下的健康检查机制集群下的健康检查机制可以用一句话来概括，那就是“各司其职”。每个服务对应一个主注册中心。当注册中心收到临时实例的心跳包后，会将健康状态同步给其他注册中心。永久实例类似。每个服务对应一个主注册表。当负责的注册中心检测到服务实例的健康状态发生变化时，会将该实例的健康状态同步到其他注册中心，从而实现集群化。健康检查机制。总结Nacos提供两种健康检查机制：临时实例的客户端主动上报机制和永久实例的服务端反向检测机制。临时实例每5s向Nacos服务器发送一个心跳包，服务器收到心跳包后将健康状态同步到其他注册中心。永久实例支持TCP、HTTP、MySQL3种检测协议。默认检测协议为TCP，即通过持续ping来判断实例是否健康。
