心跳续约存在的问题：
1，如果服务存在网络发生几秒内网络抖动，恰好设置心跳为5s上传，注册中心会错误以为服务已下线。
2，如果服务发生大量fullgc,导致心跳包不能及时上传，注册中心也会错误以为服务以下线。
3，如果10万或者更多服务需要续约，很容易导致注册中心奔溃。
改进方式：
1，不使用tcp活性心跳续约，注册中心主动探活服务，调用healcheck方法。
2，自研健康检查中间件，或者使用更有解决方案。
3，服务的健康检测自定义，健康逻辑服务自定义。
nacos官方解决方案：
健康保护阈值
为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ，继而造成流量压力把健康 健康实例 (Instance) 压垮并形成雪崩效应，应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例 (Instance) 占总服务实例 (Instance) 的比例小于该值时，无论实例 (Instance) 是否健康，都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例 (Instance) 能正常工作。
压测结果分析：
1. 注册实例
Nacos服务发现注册实例接口的性能，调用HTTP接口测试。 实测3节点集群不同压力下的性能表现：
2. 查询实例
Nacos服务发现注册实例接口的性能，调用HTTP接口测试。 实测3节点集群不同压力下的性能表现：
3.注销实例
Nacos服务发现注册实例接口的性能，调用HTTP接口测试。 实测3节点集群不同压力下的性能表现：
测试结论
Nacos服务发现性能测试都是针对重点功能，通过对3节点规模集群进行压测，可以看到接口性能负载和容量。
- 压测容量服务数可达60W，实例注册数达110W，集群运行持续稳定，达到预期；(注: 由于本次注册实例使用的是HTTP接口, 并没有将心跳上报的TPS包括在内, 如果要支持百万实例的心跳上报, 需要集群水平扩容, 并调优tomcat和内核参数)
- 注册/查询实例TPS达到 13000 以上，接口达到预期；
注：通过以上方式，官方出解决方案为，在面对海量心跳时，水平扩容，自研的话可以考虑自己设计健康检查中间件。
nacos服务续约源码解析
1，处理心跳请求
2，更新心跳时间
3，心跳5s检查未上来下线服务
4，nacos心跳构建
NamingService naming = NamingFactory.createNamingService(properties);
新建beatreactor
创建BeatProcessor
心跳请求
