精华内容
下载资源
问答
  • eureka的工作原理以及与zk区别

    千次阅读 2019-05-30 16:26:36
    一、CAP定理介绍 著名的CAP理论指出,一个分布式系统不可能同时满足C(数据一致性)、A(服务可用性)...eureka包含两个组件,eureka serve 和eureka client,eureka client是一个Java程序客户端,用于简化和eureka se...

    一、CAP定理介绍

    著名的CAP理论指出,一个分布式系统不可能同时满足C(数据一致性)、A(服务可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。

    一、eureka的工作原理

    eureka包含两个组件,eureka serve 和eureka client,eureka client是一个Java程序客户端,用于简化和eureka serve的交互。

    • Eureka Server提供服务发现的能力,各个微服务启动时,会通过Eureka Client向Eureka Server进行注册自己的信息(例如网络信息),Eureka Server会存储该服务的信息;
    • 微服务启动后,会周期性地向Eureka Server发送心跳(默认周期为30秒)以续约自己的信息。如果Eureka Server在一定时间内没有接收到某个微服务节点的心跳,Eureka Server将会注销该微服务节点(默认90秒);
    • 每个Eureka Server同时也是Eureka Client(),多个Eureka Server之间通过复制的方式完成服务注册表的同步;
    • Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉,服务消费者依然可以使用缓存中的信息找到服务提供者。

    三、区别

    从eureka工作原理可以看出,eureka client有缓存功能,即使eureka所有的serve都宕掉,仍然能给服务消费者发送服务信息,所以eureka保证了服务可用性,不能保证数据一致性,是一个AP。

    而zk,每当master宕机后,都会进行重新选举,重新选举这个过程(一般几十秒),是不能提供服务的,所以zk不能保证服务一直可用,是CP。

     

    而且,zk在多于一半服务挂掉时会停止提供服务,而 Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪(只要有一台在就可以提供服务)。

    展开全文
  • zkeureka区别

    2020-07-22 11:00:02
    但是zk会出现这样一种情况,当master节点因为网络故障其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致

    CAP原则

    CAP:C:数据一致性。A:服务可用性。P:分区容错性(服务对网络分区故障的容错性)。

    ZooKeeper保证CP

    当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。

    ZooKeeper工作原理

    zookeeper也可以作为注册中心,用于服务治理(zookeeper还有其他用途,例如:分布式事务锁等)  
    每启动一个微服务,就会去zk中注册一个临时子节点,
    例如:5台订单服务,4台商品服务
    (5台订单服务在zk中的订单目录下创建的5个临时节点)
    (4台商品服务在zk中的商品目录下创建的4个临时接点)
     
    每当有一个服务down机,由于是临时接点,此节点会立即被删除,并通知订阅该服务的微服务更新服务列表
    (zk上有watch,每当有节点更新,都会通知订阅该服务的微服务更新服务列表)
     
    每当有一个新的微服务注册进来,就会在对应的目录下创建临时子节点,并通知订阅该服务的微服务更新服务列表
    (zk上有watch,每当有节点更新,都会通知订阅该服务的微服务更新服务列表)
     
    每个微服务30s向zk获取新的服务列表
    

    eureka保证AP

    Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

    1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
    2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
    3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中

    因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。

    eureka工作原理

    每一个微服务中都有eureka client,用于服务的注册与发现
    (服务的注册:把自己注册到eureka server) (服务的发现:从eureka server获取自己需要的服务列表)
     
    每一个微服务启动的时候,都需要去eureka server注册 当A服务需要调用B服务时,
    需要从eureka服务端获取B服务的服务列表,然后把列表缓存到本地,然后根据ribbon的客户端负载均衡规则,
    从服务列表中取到一个B服务,然后去调用此B服务
    当A服务下次再此调用B服务时,如果发现本地已经存储了B的服务列表,就不需要再从eureka服务端获取B服务列表,
    直接根据ribbon的客户端负载均衡规则,从服务列表中取到一个B服务,然后去调用B服务 微服务,
    默认每30秒,就会从eureka服务端获取一次最新的服务列表
     
    如果某台微服务down机,或者添加了几台机器, 此时eureka server会通知订阅他的客户端,
    并让客户端更新服务列表, 而且还会通知其他eureka server更新此信息 心跳检测,
    微服务每30秒向eureka server发送心跳, eureka server若90s之内都没有收到某个客户端的心跳,
    则认为此服务出了问题, 会从注册的服务列表中将其删除,并通知订阅它的客户端更新服务列表,
    而且还会通知其他eureka server更新此信息
     
    eureka server保护机制,通过打卡开关,可以让eureka server处于保护状态,
    主要是用于某eureka server由于网络或其他原因,导致接收不到其他微服务的心跳,
    此时不能盲目的将其他微服务从服务列表中删除。
    具体规则:如果一段时间内,85%的服务都没有发送心跳,则此server进入保护状态,
    此状态下,可以正常接受注册,可以正常提供查询服务,但是不与其他server同步信息,
    也不会通知订阅它的客户端,这样就不会误杀其他微服务
    
    展开全文
  • 对于CAP不太熟悉的可以查看下面博客 分布式CAP原则BASE理论 接下来我们从ZKEureka 设计实现上一步步分析 ZK服务注册原理(CP) zookeeper可以作为注册中心,也可用于服务治理(zookeeper还有其他用途,例如:...

     

    著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。

    对于CAP不太熟悉的可以查看下面博客

    分布式CAP原则与BASE理论

    接下来我们从ZK和Eureka 设计实现上一步步分析

    ZK服务注册原理(CP)

    zookeeper可以作为注册中心,也可用于服务治理(zookeeper还有其他用途,例如:分布式事务锁等)   

    消费端启动时候会去zookeeper上订阅path(例如:/dubbo/com.test.demo.api/providers)下面的信息,也就是服务提供者列表信息,那么我们就可以基于这个原理来获取某一个服务提供者列表,然后对信息进行过滤加工,并且注册一个监听器,当服务提供者机器增减后,动态更新保存的地址列表。

     

    1.每启动一个微服务,就会去zk中注册一个临时子节点(ZK集群完成一致性确认,保存数据)

    2.服务订阅,拉取服务列表,并注册一个监听(zk的watch机制,不熟悉的可以简单去百度了解下)

    3.每当有一个服务down机或者新的微服务注册进来,由于是临时接点,此节点会立即被删除或者添加一个,并通知订阅该服务(2中注册了监听的服务)的微服务更新服务列表(zk的watch机制,每当有节点更新,都会通知订阅该服务的微服务更新服务列表)

    注:服务提供者全部宕掉后,服务消费者应用将无法使用,并无限次重连等待服务提供者恢复

    ZK为什么是CP?

    当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性(但是也会存在一点点延迟,毕竟需要网络传输和数据拉取处理,一般可能就几十毫秒,很短的时间)。但是zk会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的(这也就是ZK的缺点之一,牺牲部分的可用性)。

     

    Eureka服务注册原理(AP)

    Eureka看明白了这一点,因此在设计时就优先保证可用性。Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败,则会自动切换至其它节点,就算全部挂掉,服务还能通过读取本地缓存的服务列表信息来进行调用,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)(注:前提是服务提供者的ip:port信息没有发生变化)

    除此之外,Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况: 
    1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 
    2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用) 
    3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中

    因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像zookeeper那样使整个注册服务瘫痪。

     

    1.服务B进行服务注册,并定时发送心跳(根据配置的规则 进行不达标节点下线)

    2.Eureka接收注册信息后, 一是本地注册信息更新(同步);二是将消息广播给其它服务器(异步)

    由此也可以看出 Eureka 是 AP 模型的,优先保障了可用性,事实上大多数注册中心的实现方案都是 AP 模型,只有 ZK 是 CP 模型。事实上,ZK 是分布式协调服务,并不是专门用来进行服务治理的。

    3.服务A定时拉取最新的服务信息并缓存在本地

    基于eureka的实现原理,可以看出它优先保证了可用性,牺牲了数据一致性,但并不是说集群中的数据是不一致的,集群中每个节点的数据同步延迟时间比较长而已,如果使用Eureka默认的配置信息,数据服务A要获取到最新的服务列表信息 延迟可能是几十秒甚至几分钟,因此,线上生产环境往往会对Eureka 进行调优,使发送心跳,拉取服务,定时检查等定时服务间隔时间调短,来达到服务信息延迟降低的目的。 

    总结:

    基于CAP理论来说,很多人说  Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”,因为注册服务更重要的是可用性,我们可以接受短期内达不到一致性的状况。但其实呢,个人认为技术不分优劣,更多的在于适不适合你的项目技术架构,你的服务是需要保证AP还是需要保证CP,能否容忍技术带来的不便之处,综合比较,选取最合适的技术才是最关键的

    展开全文
  • Zookeeper与Eureka区别

    2018-11-07 22:06:00
    想要了解Zk与eureka区别首先要知道CAP定理 CAP定理 Mysql强一致性(数据唯一出处),设计数据库设计的三范式 (表必须有主键;表不能有重复的列;列不能是加工而成) 主流数据库表的设计方式:反三范式...

    Zookeeper与Eureka的区别

    想要了解Zkeureka的区别首先要知道CAP定理

     

    CAP定理

     

     

    Mysql强一致性(数据唯一出处),设计数据库设计的三范式

    (表必须有主键;表不能有重复的列;列不能是加工而成)

    主流数据库表的设计方式:反三范式,冗余设计(性能高,缺点:数据多处,同步数据时间差,短暂时间数据不一致。)

     

    最终一致性,允许短暂时间内数据可以不一致,但过了这个时间阀值必须数据是一致。

     

    可用性,zk主从设计,如果zk节点有一半节点宕机或者有节点正在选举,此时zk集群不可用!

    Eurekap2p点对点设计,每个点的信息都可以用户接入,每个点如果信息变化,它内部会自动同步所有的数据。Eureka即使所有的节点都宕机,

    仍然能提供服务。EurekaClient客户端,缓存所有的数据信息,也能找到服务提供者。

     

    为什么不用zookeeper做注册中心 在使用dubbo时,一般都结合zk(作为注册中心)来使用。那为什么SpringCloud中使用Eureka,而不是zk呢?

    我们来比较一下,在CAP理论中,zk更看重CP,即一致性和分区容错性。但Eureka更在意的是APA为高可用。zk中有masterfollower区别,

    当进入选举模式时,就无法正常对外提供服务。但Eureka中,集群是对等的,地位是相同的,虽不能保证一致性,但至少可以提供注册服务。

    根据不同的业务场景,各有取舍吧。ZooKeeper 基于CP设计,侧重一致性而Eureka基于AP设计,侧重可用性

     

    Eureka只有一个8761的注册中心,那么如何避免单点问题呢?

    我们可以采用集群的方式来解决。 比如现在有三台机器:Server1Server2Server3.在高可用方案中,三台机器要两两注册。

    比如S1要向S2S3分别进行注册,目前他无法实现注册的传递性。 这样一来,如果Server1宕机,我们还可以继续从Server23中获取服务。

     

    转载于:https://www.cnblogs.com/lmqblogs/p/9926083.html

    展开全文
  • Eureka与Zookeeper的区别

    2020-02-11 16:39:19
    Zookeeper保证CP ...但是zk会出现这样一种情况,当master节点因为网络故障其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可...
  • 1.本文作者通过ZooKeeper与Eureka作为 Service发现服务(注:WebServices 体系中的UDDI就是个发现服务)的优劣对比,分享了Knewton在云计算平台部署服务的经验。本文虽然略显偏激,但是看得出Knewton在云平台方 面是...
  • eureka,p2p点对点设计,每个点的信息都可以用户接入,每个点如果信息变化,它内部会自动同步所有数据,eureka即使所有节点都宕机,仍然能提供服务,所以,对于服务发现而言,可用性比数据一致性更加重要,AP胜过CP ...
  • 主要区别zookeeper的目标是一个分布式的协调系统,用于进行资源的统一管理,为了满足CP而进行设计。eureka的目标是一个服务注册发现系统,专门用于微服务的服务发现注册,按照满足AP而进行设计。ZookeeperZookeeper ...
  • 主要区别zookeeper的目标是一个分布式的协调系统,用于进行资源的统一管理,为了满足CP而进行设计。eureka的目标是一个服务注册发现系统,专门用于微服务的服务发现注册,按照满足AP而进行设计。ZookeeperZookeeper ...
  • ZK与Euraka的区别

    2018-11-07 22:33:31
    Zk与eureka区别首先要知道cap定理 CAP定理 Mysql强一致性(数据唯一出处),设计数据库设计的三范式 (表必须有主键;表不能有重复的列;列不能是加工而成) 主流数据库表的设计方式:反三范式,冗余设计(性能高...
  • java Quene区别与底层实现 zookeeper和springcloud eureka区别
  • eureka与zookeeper异同

    2020-08-05 11:34:03
    也就是说,服务注册功能对高可用要求比较高,但zk会出现这样一种情况,当master节点因为网络故障其他节点失去联系时,剩余节点会重新选leader。问题在于,选取leader时间过长,30~120s, 且选取期间
  • Eureka和zookeeper都可以提供服务注册发现的功能,请说说两个的区别? Zookeeper保证了CP(C:一致性,P:分区容错性),Eureka保证了AP(A:高可用) 1.当向注册中心查询服务列表时,我们可以容忍注册中心返回的...
  • Zookeeper 保证了CP(C:一致性,P:分区...也就是说,服务注册功能对高可用性要求比较高,但 zk 会出现这样一种情况,当 master 节点因为网络故障其他节点失去联系时,剩余节点会重新选 leader。问题在于,选取 ...
  • Eureka Zookeeper 都可以充当服务中心,它们的区别主要体现在对于 CAP 原则的支持的不同。 Eureka:AP zk:CP 1.创建 Eureka 服务中心 eurekaserver-8000 1.1 新建 Spring Initializr 工程,命名为 eureka...
  • zookeepereurka的区别

    千次阅读 2018-11-23 13:50:29
    当在ZooKeeper节点宕机个数超过一半时和zk集群在选举时,zk是不推荐使用。Zk有心跳机制。 2) Eureka侧重AP设计,强调可用性。Eureka结构peer to peer 点对点,每个节点互为主从,即主节点,又是从节点。每个节点...
  • Zookeeper和Eureka的比较

    2020-05-22 16:16:38
    前提:已经对Zookeeper和Eureka的架构特点有所了解 1、为什么将两者进行比较: ... 2、两者主要区别: ...但是zk会出现这样一种情况,当master节点因为网络故障其他节点失去联系时,剩余节点会重新进行leade...
  • SpringCloud2.0使用Zookeeper来替换EurekaZookeeper简介环境搭建1. 启动zk服务器端2.... 服务启动Zookeeper与Eureka区别1. Zookeeper是保证CP2. Eureka是保证AP Zookeeper简介 Zookeeper是一个分布式...
  • Eureka和Zookeeper的比较

    2020-09-29 16:10:00
    前提: 1、为什么将两者进行比较 ...但是zk会出现这样一种情况,当master节点因为网络故障其他节点失去联系时,剩余节点会重新进行leader选举。问题在于,选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集...
  • Springcloud学习

    2020-09-13 10:10:53
    微服务架构面向服务架构的区别: 面向服务架构(SOA)主要针对在银行xml格式、企业级ESB 服务,重量级。 微服务架构,会更加细分,HTTP+json+restful进行,轻量级,独立运行,更加解耦。 SpringCloud解决什么样的...
  • Zookeeper知识汇总

    2020-12-02 21:19:44
    dubbo+zookeeper eureka区别 zookeeper 安装 zookeeper 安装的三种模式 linux安装zookeeper及使用 Linux环境快速部署Zookeeper集群 zk链接 ZooKeeper客户端 zkCli.sh 节点的增删改查 zookeeper使用zkCli命令操作...
  • 项目架构相关问题

    2019-06-05 08:27:34
    Eureka比Zookeeper区别 Zookeeper保证CP 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对可用性的要求要高于一致性。...
  • 【基础系列】SpringBoot基础篇配置信息之自定义配置指定配置内引用 【基础系列】SpringBoot配置信息之配置刷新 【基础系列】SpringBoot配置信息之默认配置 【基础系列】实现一个自定义配置加载器(应用篇) 【基础...

空空如也

空空如也

1 2
收藏数 25
精华内容 10
关键字:

eureka与zk区别