目录
Eureka和Nacos都是服务注册与发现的组件，都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测，
CAP上的区别
C一致性,A高可用,P分区容错性
-
eureka只支撑AP
-
nacos支撑CP跟AP两种 nacos是依据设置辨认CP或AP形式,假如注册Nacos的client节点注册时是ephemeral=true即为临时节点,那么Naocs集群对这个client节点后果就是AP,反之则是CP,即不是临时节点。
#false为永久实例，true表示临时实例开启，注册为临时实例
spring.cloud.nacos.discovery.ephemeral=true
检测机制
Eureka通过定期发送HTTP请求来检查注册的服务是否正常运行。服务提供者会在启动时向Eureka注册自己，并定期发送心跳信息告知Eureka服务依然存活。Eureka服务器也会定期向已注册的服务发送健康检查请求，如果服务没有及时响应或返回异常状态码，Eureka将视为该服务不可用。
Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
临时实例心跳不正常会被剔除，非临时实例则不会被剔除
连接方式
- nacos使用的是netty和服务直接进行连接,属于长连接
- eureka是使用定时发送和服务进行联系,属于短连接
自我保护
Nacos也有自我保护机制（当前健康实例数/当前服务总实例数），值为0-1之间的浮点类型。正常情况下Nacos 只会健康的实例。单在高并发场景，如果只返回健康实例的话，流量洪峰到来可能直接打垮剩下的健康实例，产生雪崩效应。
保护阈值存在的意义在于当服务A健康实例数/总实例数 < 保护阈值时，Nacos会把该服务所有的实例信息（健康的+不健康的）全部提供给消费者，消费者可能访问到不健康的实例，请求失败，但这样远比造成雪崩要好。牺牲了请求，保证了整个系统的可用。
Eureka保护模式主要用与一组EurekaClient客户端和EurekaServer之间存在网络分区场景下的保护。一旦进入保护模式，EurekaServer将会保护其注册表中的服务，不再删除服务注册表中的数据，也就是不会注销任何微服务。
