EurekaServer启动,等待客户端前来注册. EurekaServer之间通过Replicat完成服务列表同步.每个Eureka节点,都会存储完整的服务列表. EurekaClient会通过配置中的defaultZone信息前往EurekaServer去进行注册. 心跳机制:微服务客户端每隔30s(默认值)回向Server发送一次"心跳".报告状态.如果超过90s(默认值) 没有接收到心跳,会标注该服务失效,并从服务列表删除. 自我保护机制:在单位时间内,如果没有收到超过85%的Client发送过来的心跳,那么会判断为服务器 自己网络出现异常.从而进入保护模式.不再删除服务列表中的微服务.直到心跳请求恢复之 后,Eureka会退出保护模式. EurekaClient会定时全量或者增量从EurekaServer拉取服务列表.并将完整的服务列表缓存到本地. 即使所有server都不能使用,客户端仍然能够使用缓存的服务列表完成远程调用. EurekaClient通过服务列表获取调用信息,完成服务调用. **Eureka设计** 分布式系统的CAP理论. C:一致性.从各个节点获得的数据一致. A:可用性.每一次请求都会得到一个(正确)响应. P:分区容忍.节点之间出现网络分区.系统仍然能够继续运行. 分布式系统在设计时,只能倾向于CAP中的两个,不可能3个同时兼顾. DUBBO的设计倾向于哪两个? dubbo的设计倾向于CP. dubbo更注重一致性.每次服务列表同步都是由leader发起,确保每个节点都写入 成功,才会确认写入.保证了每个节点的一致性. leader不可用时,会选举新的leader.而在选举期间.集群是不可用的.直到leader选举结束,并完成同步.才能 继续提供服务.所以DUBBO的设计更倾向于数据的一致性. Eureka的设计倾向于哪两个? eureka的设计倾向于AP.首先,Eureka服务器之间的同步属于异步的P2P方式.有可能在同一时间不同 Server节点,拉取到不同的服务列表的.但是放心,最终一致性还是可以保障的.Server节点都是平等的,没有 主从概念.任何一个Server挂掉.客户端会自动连接到其他存活Server提供服务.即使所有Server都挂掉.客 户端也会从本地缓存的服务列表继续获得信息.由此可以得出结论.Eureka是更倾向于可用性的设计