是什么
遵守的是API原则,只需要使用服务的标识符,可以访问到服务,而不需要修改服务调用的配置文件了.功能类似dubbo的注册中心,如zk
原理讲解
Eureka Server服务注册功能的服务器,是服务注册中心,采用c/s结构
基本架构
从上图可知: 共两大组件Eureka Server和Eureka Client
Eureka Server提供服务注册服务
各个节点启动后,会在EurekaServer中进行注册,这样EurekaServer中服务注册表中将会存储所有可用服务节点信息,服务节点的信息可以在界面中直观的看到
Eureka Client :java客户端,简化Eureka Server交互,客户端同时内具备一个内置的使用轮询(round-robin)负载算法的负载均衡器,应用启动后,会向Eureka Server发送心跳(默认周期30秒),若Eureka Server在多个心跳周期内没有接受到某个节点心跳,EurekaServer将会从服务注册表中把这个服务节点移除(默认90s)
自我保护机制
好死不如赖活着, EurekaServer保护服务注册表中的信息,不再注销任何服务实例,收到心跳数重新恢复到阈值以上时,该EurekaServer节点会自动退出自我保护模式.
是一种应对网络异常的安全保护措施,让Eureka集群更加健壮,稳定
使用eureka.server.enable-self-preservation=false禁用自我保护模式
与zk区别
从CAP理论来讲, eureka是AP, zk是CP
但是前面我们有学过zk的master选举机制, 当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader.这个选举时间长,注册服务瘫痪.且云部署,zk失去master节点是较大概率发生的事
但是对于eureka来说, 各个节点平等.节点挂掉不会影响正常节点工作.eureka客户端向某个eureka注册时如果发现连接失败,自动切换其他节点,只要有一台eureka存在,保证可用性.
保护机制,15分钟内85%节点没有正常心跳,eureka认为客户端与注册中心出现网络故障:
1.eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2.eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点上(保证当前节点依然可用)
3.网络稳定时,当前实例新的注册信息会被同步到其他节点
eureka可以很好应对因网络故障导致部分节点失去联系的情况,不会像zk那样使整个注册服务瘫痪
搭建过程
太多了,不想写…我会把所有的demo上传到github上