dubbo 版本 3.2.4
实验过程：服务端关闭网络，节点在15min内不会从nacos平台消失。导致consumer仍然能够拿到invoder，此时客户端如果能判断服务端invoker不能连接，就会从全局的invoker列表中剔除该invoker，执行故障转移。但是dubbo consumer 在服务端突然断网后，判断连接仍然存在，导致无法剔除invoker，无法进行故障转移。
问题：针对服务端突然断电、断网，是否是应为tcp链接无法正常断开，导致consumer判断连接失效？
目前Dubbo基于心跳模式测试与Provider的连通性。默认值为每分钟一次心跳。如果失败3次，连接将被删除。如果需要缩短移除时间，可以配置dubbo.protocol.heartbeat=10000，将心跳缩短到10s，预计30s恢复
如果心跳检测的时间是10s，那么我理解在服务端A突然断电10s后，invoker.isAvailable = false，从而将服务A的invoker移除，但是经过测试，从断网到节点从nacos上彻底消失，期间持续15min，经过debug发现，在这15min内，invoker.isAvailable = true，导致客户端无法移除invoker，不清楚这是什么情况？ 强调下，这个测试是突然断网和断电下测试的，nacos上服务居然停留了15min
麻烦问下这个nacos的配置是哪个配置？ 目前我们用的是nacos临时节点，也就是通过grpc保持的长连接。断网断电后节点还在注册中心，是不是tcp连接没有正常中断？
dubbo我们用的协议是triple 协议，不是dubbo协议。默认也有心跳吗？
2018年8月博客提出的dubbo协议心跳改进点，在2023年8月的triple协议上实现了https://cn.dubbo.apache.org/zh-cn/blog/2018/08/19/dubbo-%e7%8e%b0%e6%9c%89%e5%bf%83%e8%b7%b3%e6%96%b9%e6%a1%88%e6%80%bb%e7%bb%93%e4%bb%a5%e5%8f%8a%e6%94%b9%e8%bf%9b%e5%bb%ba%e8%ae%ae/