注册中心解析
AP注册中心:Eureka 注重服务的可用性，服务出现宕机，但是可以由这个节点的副本继续提供服务，但是抛弃了数据一致性 Eureka的自我保护机制保证了AP的可用性
CP注册中心:zookeeper 注重服务的数据一致性，但是当服务出现宕机时服务会出现，一直等待节点的恢复，会导致出现服务不可用的状态
AP CP注册中心：NACOS nacos可以提供AP和CP模式的选项，默认时AP模式的
在选择注册中心时，一般注重于服务的可用性，zookeeper在服务列表变更时会有通知，Eureka是通过长轮询去更新自己的服务列表的，定时去拉取服务提供者的服务列表信息 心跳机制
Eureka心跳机制
1.服务器启动成功，等待客户（服务）端注册，在启动过程中如果我们配置了集群，集群之间会同步注册表，每一个Eureka serve都会存在这个集群完整的服务注册表信息
2.Eureka client 启动时根据配置信息，去注册到指定的注册中心
3.Eureka client会每30秒向Eureka server 发送一次心跳请求，证明该客户端服务正常
4.当Eureka server90s内没有接受客户端服务正常，注册中心会认为该节点失效，会注销该实列 （从注册表中删除注册信息）
5.单位时间内如果服务端统计到大量客户端没有发送心跳，则认为网络异常，进去自我保护机制，不在剔除没有发送心跳的客户端
6.当客户端恢复正常之后，服务端就会退出自我保护模式
7.客户端定时全量或增量从注册中心获取服务注册表，并且会缓存到本地
8.服务调用时，客户端会先从本地缓存找到调用服务，如果调取不到 先从注册中心刷新注册表，在同步到本地
9.客户端获取不到目标服务器信息发起服务调用
10.客户端程序关闭时向服务端发送取消请求，服务器将实例从注册表中删除
NACOS
服务列表：
1.Nacos支持服务列表变更的消息推送模式，服务列表更新更及时，同时支持主动拉去服务列表
2.NACOS集群默认AP模式，当集群中存在非临时实例时，采用CP模式
消费和服务提供
1：在提供者和注册中心之间。
（1）Eureka中会定时向注册中心发送心跳，如果在短期内没有发送心跳，则就会直接剔除。
（2）Nacos也会向注册中心发送心跳，但是它的频率要比Eureka快。在Nacos中又分为临时实例和非临时实例。
如果是临时实例的话，短期内没有发送心跳，则会直接剔除。但是如果是非临时实例长时间宕机，不会直接剔除，并且注册中心会直接主动询问并且等待非临时实例。
2：在消费者和注册中心之间。
（1）Eureka会定时向注册中心定时拉去服务，如果不主动拉去服务，注册中心不会主动推送。
（2）Nacos中注册中心会定时向消费者主动推送信息 ，这样就会保持数据的准时性。
NACOS中什么是临时实例和非临时实例
在服务注册时有一个属性ephemeral用于描述当前实例在注册时是否以临时实例出现；
为true则为临时实例（默认值）；
为false则为持久实例；
区别
临时实例
默认情况，服务实例仅会注册在Nacos内存，不会持久化到Nacos磁盘，其健康检测机制为Client模式，即Client主动向Server上报其健康状态（类似于推模式）；
默认心跳间隔为5秒，在15秒内Server未收到Client心跳，则会将其标记为“不健康”状态；在30秒内若收到了Client心跳，则重新恢复“健康”状态，否则该实例将从Server端内存清除。即对于不健康的实例，Server会自动清除；
持久实例
服务实例不仅会注册到Nacos内存，同时也会被持久化到Nacos磁盘，其健康检测机制为Server模式，即Server会主动去检测Client的健康状态（类似于拉模式）；
默认每20秒检测一次，健康检测失败后服务实例会被标记为“不健康”状态，但不会被清除，因为其是持久化在磁盘的，其对不健康持久实例的清除，需要专门进行；
面试相关：
1.当eureka服务集群宕机后，消费者还能够实现服务请求调用吗？
消费者服务还是可以获取到服务的，在之前的调用过程中，消费者除了会将服务地址给到注册中心拉取服务外还会在消费者自己的服务中缓存一份服务地址，若注册中心宕机则使用本地服务地址直接调用，如果调取不到再去从注册中心刷新服务列表，同步到本地
2.EUreka的AP的保证
Eureka的心跳机制会在指定时间的，如果某个服务没有向注册中心发送心跳，Eureka注册中心会将这个节点从服务列表中剔除，当注册列表中超过85%的节点没有心跳，那么此时Eureka的自我保护机制就会开启，当客户端恢复正常时
退出保护机制，这样Eureka注册中心会保证注册中心服务列表一直有可调用节点，这样就保证了服务的可用性
