为什么需要注册中心？是用Eeka还是Nacos？

//DiscoveryManager.getInstance().shutdownComponent()

1.3自我保护机制

默认情况下，Eeka服务端在90s没有收到某个服务实例的心跳，就会注销该实例，将实例下线。如果出现大量实例心跳检测失败，Eeka就会认为是注册中心出现问题了，启动自我保护机制，<>不再剔除这些失败实例</>。触发条件阈值为：

<>注册表中超过15%的实例心跳检测失败</>

1.4小结

Eeka属于AP模型，即牺牲一致性，来换取高可用。在部分阶段失效时，仍然能正常运作。但是服务节点间的数据可能不一致Eeka客户端具备良好的弹性能力，即使与所有Eeka服务端的连接断开，它们依然能通过本地缓存机制正常工作适合跨多机房，对注册中心可用性要求高的场景

2.Nacos工作原理

Nacos文档：Nacos架构2.3版本，注册中心设计原理文档：Nacos注册中心

上面的图较复杂，这里贴下人的关于注册中心这部分的架构图

整体流程也就是服务发现那套流程：

服务提供者轮询注册中心集群节点，把自己的协议注册到Nacosserver服务消费者需要从Nacos上去查询服务提供者的（根据服务名称）Nacos需要感知到服务提供者的上下线的变化服务消费者需要动态感知到Nacos端服务的变化

Nacos采用了<>Pull和Push同时运作</>的方式来保证本地服务实例列表的动态感知。服务消费者通过定时任务的方式每10sPull一次数据，Nacos在服务提供者出现变化时，基于UDP协议PUSH更新

2.1数据模型

Zookeeper使用的是抽象的树形K-V组织结构，没有专门的数据模型。Eeka或者Consul都是做到了实例级别的数据扩展。Nacos使用的是<>服务-集群-实例</>的三层数据模型。

从上图的分级数据模型可以看到：

服务级别：保存了健康检查开关、元数据、路由机制、保护阈值等设置集群保存了健康检查模式、元数据、同步机制等数据实例保存了该实例的ip、端口、权重、健康检查状态、下线状态、元数据、响应时间。

2.2数据一致性协议选择（CPorAP）

Nacos因为要支持多种服务类型的注册，并能够具有机房容灾、集群扩展等必不可少的能力，是支持AP和CP两种一致性协议的，默认是AP模式

如果注册Nacos的client节点注册时ephemeral=true，那么Nacos集群对这个client节点的效果就是AP，采用distro协议实现；而注册Nacos的client节点注册时ephemeral=false，那么Nacos集群对这个节点的效果就是CP的，采用raft协议实现。

根据client注册时的属性，AP，CP同时混合存在，只是对不同的client节点效果不同。

Distro协议则是参考了内部Config和开源Eeka，在不借助第三方存储的情况下，实现基本大同小异。Distro重点是做了一些逻辑的优化和性能的调优。

3.注册中心较