CAP
检测机制
连接方式
自我保护
Eureka和Nacos都是服务注册与发现的组件，都支持服务注册和服务拉取，都支持服务提供者心跳方式做健康检测，
Spring Cloud 封装了 Netflix 公司开发的 Eureka 模块来实现服务治理 ，在传统的rpc远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务于服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册
Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。Nacos就是注册中心 配置中心的组合Nacos = Eureka Config Bus。 Nacos的前四个字母分别为Naming和Configuration的前两个字母，最后的s为Service。 Nacos: Dynamic Naming and Configuration Service
CAP上的区别
C一致性,A高可用,P分区容错性
- eureka只支撑AP
只要集群中
任意一个实例不出现问题，Eureka服务就是可用的；即Eureka Client 在向某个 Eureka Server 注册时，如果发现连接失败，则会自动切换至其它节点。Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性
- 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支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
与Eureka类似，Nacos也使用心跳机制来维持与注册的服务的连接。服务提供者会定期发送心跳给Nacos服务器，告知自己的状态。Nacos服务器接收到心跳后，会更新服务的状态信息。如果一个服务连续几个心跳周期没有发送心跳，则Nacos服务器会将该服务标记为不可用。
动检测模式（Active Health Check）来主动检测注册的服务是否可用。在主动检测模式下，Nacos服务器会主动向服务实例发送健康检查请求，并根据返回的结果来判断服务的可用性。
临时实例心跳不正常会被剔除，非临时实例则不会被剔除
连接方式
- nacos使用的是netty和服务直接进行连接,属于长连接
- eureka是使用定时发送和服务进行联系,属于短连接
自我保护
Nacos也有自我保护机制（当前健康实例数/当前服务总实例数），值为0-1之间的浮点类型。正常情况下Nacos 只会健康的实例。单在高并发场景，如果只返回健康实例的话，流量洪峰到来可能直接打垮剩下的健康实例，产生雪崩效应。
保护阈值存在的意义在于当服务A健康实例数/总实例数 < 保护阈值时，Nacos会把该服务所有的实例信息（健康的 不健康的）全部提供给消费者，消费者可能访问到不健康的实例，请求失败，但这样远比造成雪崩要好。牺牲了请求，保证了整个系统的可用。
Eureka保护模式主要用与一组EurekaClient客户端和EurekaServer之间存在网络分区场景下的保护。一旦进入保护模式，EurekaServer将会保护其注册表中的服务，不再删除服务注册表中的数据，也就是不会注销任何微服务。
自我保护机制是一种针对网络异常波动的安全保护措施，可以使Eureka集群更加的健壮、稳定的运行。
