实现原理
- 采用C-S的架构设计
  - 分为Eureka Server 和 Eureka Client两个组件
- Eureka Server
  - 作为服务注册功能的服务器，是服务注册中心
  - 各个节点启动后，要在 Eureka Server 中进行注册，这样Eureka Server中的服务注册表中将会存储所有服务节点的信息，服务节点的信息可以在界面中直观的看到
- Eureka Client
  - 是一个Java客户端，用于简化Eureka Server的交互，同时也具备一个内置的，使用轮询负载算法的负载均衡器
  - 在应用启动后，将会向Eureka Server发送心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除掉（默认周期为90s）
自我保护机制
- 定义
  - 某时刻某一微服务不可用，Eureka不会立即清理，依旧会对该微服务的信息进行保存
  - Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
  - Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 (即保证当前节点依然可用)
  - 当网络稳定时，当前实例新的注册信息会被同步到其他节点中
- 目的
  - 该保护机制的目的是避免网络连接故障，在发生网络故障时，微服务和注册中心之间无法正常通信，但服务本身是健康的，不应该注销该服务，如果Eureka因网络故障而把微服务误删了，那即使网络恢复了，该微服务也不会重新注册到Eureka Server了，因为只有在微服务启动的时候才会发起注册请求，后面只会发送心跳和服务列表请求，这样的话，该实例虽然是运行着，但永远不会被其它服务所感知
- 触发条件
  - Eureka Server在短时间内丢失过多的客户端心跳时（在15分钟内超过85%的节点都没有正常的心跳），会进入自我保护模式，该模式下，Eureka会保护注册表中的信息，不再注销任何微服务，当网络故障恢复后，Eureka会自动退出保护模式。
和Zookeeper的区别
- CAP原则
- Zookeeper 保证的是CP
  - 注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接收服务直接down掉不可用，服务注册功能对一致性的要求要高于可用性。
  - 当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader投票选举。选举leader的时间太长（30-120s），且选举期间整个zookeeper集群是不可用的，导致选举期间注册服务瘫痪。
  - 在云部署的环境下，因为网络问题使得zookeeper集群失去master节点是较大概率发生的事件，虽然服务最终能够恢复，但是，漫长的选举时间导致注册长期不可用，是不可容忍的。
- Eureka 保证的是AP
  - Eureka在设计时就优先保证可用性。
  - Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的。
  - Eureka有自我保护机制。
  - 故Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

Reference
spring官方文档

https://spring.io/projects/s pring-cloud-netflix

【狂神说Java】SpringCloud最新教程IDEA版

https://www.bilibili.com/video/BV1jJ411S7xr

SpringCloud学习笔记（四）（狂神视频笔记）

https://blog.csdn.net/hexinqiong/article/details/116349989

标签：网络故障,服务,入门,Eureka,注册,组件,Server,节点
来源： https://blog.csdn.net/kinpoker/article/details/119414627