网站建设工作会议,互联网备案服务平台,要学做网站,wordpress最新版本下载二、注册中心选型 1. zk和eureka的区别 zk#xff1a;CP设计(强一致性)#xff0c;目标是一个分布式的协调系统#xff0c;用于进行资源的统一管理。 当主节点crash后#xff0c;需要进行leader的选举#xff0c;在这个期间内#xff0c;zk服务是不可用的#xff08;当然… 二、注册中心选型 1. zk和eureka的区别 zkCP设计(强一致性)目标是一个分布式的协调系统用于进行资源的统一管理。 当主节点crash后需要进行leader的选举在这个期间内zk服务是不可用的当然消费者可以缓存zk上注册的节点并且在写数据时同步到从节点阶段也是不可用的。 eurekaAP设计高可用目标是一个服务注册发现系统专门用于微服务的服务发现注册。Eureka各个节点都是平等的不是主从架构。几个节点挂掉不会影响正常节点的工作剩余的节点依然可以提供注册和查询服务。
而Eureka的客户端在向某个Eureka注册时如果发现连接失败会自动切换至其他节点只 要有一台Eureka还在就能保证注册服务可用保证可用性只不过查到的节点信息可能不是最新的不保证强一致性
同时当eureka的服务端发现85%以上的服务都没有心跳的话它就会认为自己的网络出了问题就不会从服务列表中删除这些失去心跳的服务同时eureka的客户端也会缓存服务信息。eureka对于服务注册发现来说是非常好的选择。 2.为何企业级项目弃用eruke
1.Eureka 2.0宣布闭源
在选型微服务注册中心时一定要长远考虑SpringCloud提供了Eureka作为服务注册中心我们可以开箱即用但是对于服务注册中心随着业务需求的不断变化对服务注册中心提出了更高要求如果不能同步跟上业务的脚步或者没有专业的维护团队将会是很糟糕的。
看到“Eureka 2.0 开源工作宣告停止继续使用风险自负”。
这意味着如果开发者继续使用作为 2.x 分支上现有工作 repo 一部分发布的代码库和工件则将自负风险对此专家建议开发者尽快将相关业务迁移到 Consul/ZooKeeper/Etcd 等工具上。
所以Eureka就不太适合了
2.已停止的微服务不注销或注销有延迟 在使用Eureka Client时可能会发现当微服务Eureka Client已经停止了而注册中心仍然显示该服务处于正常状态或者过段时间才会注销。然而这种情况在实际应用中是大家不太希望看见的希望一旦服务发生异常或宕机注册中心应该理解体现出来。 这是由于Eureka Server注销无效节点周期、自我保护模式的因素造成的因此会出现服务不注销或注销有延迟。解决办法如下
1.Eureka Server关闭自我保护模式机制 关闭自我保护模式并配置注销无效节点周期时间间隔。
# 默认值为true。设为false, 关闭自我保护 从而保证会注销微服务
eureka.server.enable-self-preservationfalse# 清理间隔单位毫秒默认是60 * 1000。根据需求将时间间隔设置短些例如设置1秒一旦down掉则会立即注销
eureka.server.eviction-interval-timer-in-ms1000
参考 https://github.com/spring-cloud/spring-cloud-netflix/issues/1322 2.Eureka Client主动注销 当Client端开启健康检查时可以适当的按需配置续约更新时间和到期时间。这样做只能在一定程度上缓解注销延迟的程度但不能真正解决立即注销可以在进行微服务(Eureka Client)异常或关机时主动调用 Eureka Rest API来注销该服务注销接口http://localhost:8761/eureka/apps的DELETE 请求方式。
# 默认值为false。设为true开启健康检查需要spring-boot-starter-actuator 依赖
eureka.client.healthcheck.enabledtrue# 续约更新时间间隔默认是30秒
eureka.instance.lease-renewal-interval-in-seconds?# 续约到期时间默认90秒
eureka.instance.lease-expiration-duration-in-seconds?
