?? 东北东北四人单机麻将:Spring Cloud Netflix之Eureka 相关概念 - 东北麻将玩法

Spring Cloud Netflix之Eureka 相关概念

为什么不应该使用ZooKeeper做服务发现

英文链接:

Eureka! Why You Shouldn’t Use ZooKeeper for Service Discovery:

http://www.knewton.com/tech/blog/2014/12/eureka-shouldnt-use-zookeeper-service-discovery/

中文链接:

http://blog.csdn.net/jenny8080/article/details/52448403

Eureka vs. Zookeeper:

https://groups.google.com/forum/#%21topic/eureka_netflix/LXKWoD14RFY

Netflix Shares Cloud Load Balancing And Failover Tool: Eureka!

https://techblog.netflix.com/2012/09/eureka.html

在分布式系统领域有个著名的 CAP定理(C- 数据一致性;A-服务可用性;P-服务对网络分区故障的容错性,这三个特性在任何分布式系统中不能同时满足,最多同时满足两个);

ZooKeeper是个 CP的,即任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;

在Eureka平台中,如果某台服务器宕机,Eureka不会有类似于ZooKeeper的选举leader的过程;客户端请求会自动切换 到新的Eureka节点;当宕机的服务器重新恢复后,Eureka会再次将其纳入到服务器集群管理之中,

所以,再也不用担心有“掉队”的服务器恢复以后,会从Eureka服务器集群中剔除出去的风险了。Eureka甚至被设计用来应付范围更广 的网络分割故障,并实现“0”宕机维护需求。当网络分割故障发生时,每个Eureka节点,会持续的对外提供服务(注:ZooKeeper不会):接收新 的服务注册同时将它们提供给下游的服务发现请求。这样一来,就可以实现在同一个子网中(same side of partition),新发布的服务仍然可以被发现与访问。

注: 高延迟与网络分割问题 原文为network partitions。意思是当网络交换机出故障会导致不同子网间通讯中断;

正常配置下,Eureka内置了心跳服务,用于淘汰一些“濒死”的服务器;如果在Eureka中注册的服务, 它的“心跳”变得迟缓时,Eureka会将其整个剔除出管理范围(这点有点像ZooKeeper的做法)。这是个很好的功能,但是当网络分割故障发生时, 这也是非常危险的;因为,那些因为网络问题(注:心跳慢被剔除了)而被剔除出去的服务器本身是很”健康“的,只是因为网络分割故障把Eureka集群分割 成了独立的子网而不能互访而已。

如果Eureka服务节点在短时间里丢失了大量的心跳连接(注:可能发生了网络故障),那么这个 Eureka节点会进入”自我?;つJ健?,同时保留那些“心跳死亡“的服务注册信息不过期。此时,这个Eureka节点对于新的服务还能提供注册服务,对 于”死亡“的仍然保留,以防还有客户端向其发起请求。当网络故障恢复后,这个Eureka节点会退出”自我?;つJ健?。所以Eureka的哲学是,同时保 留”好数据“与”坏数据“总比丢掉任何”好数据“要更好,所以这种模式在实践中非常有效。

Eureka还有客户端缓存功能(注:Eureka分为客户端程序与服务器端程序两个部分,客户端程序负责向外提供注册与发现服务接口)。 所以即便Eureka集群中所有节点都失效,或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器;Eureka服务的消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下,所有正常的Eureka节点都不对请求产生相应,也没有更好的服务器解决方案来解 决这种问题时;得益于Eureka的客户端缓存技术,消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息,这点很重要;  由于Eureka客户端具有注册表缓存信息,所以即使所有的Eureka服务器都?;?,它们也可以运行得很好;

进一步了解 Eureka

Eureka基本架构图

architecture-overview

上图简要描述了Eureka的基本架构,由3个角色组成:

Eureka Server

提供服务注册和发现

Service Provider

服务提供者,服务启动的时候会将自己的服务信息注册到Eureka

Service Consumer

服务消费者,从Eureka中获取已注的服务信息,用于调用服务生产者

需要注意一点是:一个Service Provider既可以是Service Consumer,也可以是Service Provider。

集群模式下的Eureka

上图更进一步的展示了3个角色之间的交互。

Service Provider会向Eureka Server做Register(服务注册)、Renew(服务续约)、Cancel(服务下线)等操作。

Eureka Server之间会做注册服务的同步,从而保证状态一致

Service Consumer会向Eureka Server获取注册服务列表,并消费服务

Eureka的工作原理

Eureka 组件分为两部分:Eureka server和 Eureka client。而客户端又分为 Application Service 客户端和 Application Client 客户端两种。

Eureka 的工作机制每个 region 都有自己的 Eureka 服务器集群,每个 zone 至少要有一个 Eureka 服务器以应对 zone

名词解释

Renew:续约

Renew(服务续约)操作由Service Provider定期调用,类似于heartbeat。目的是隔一段时间Service Provider调用接口,告诉Eureka Server它还活着没挂,不要把它踢掉。通俗的说就是它们两之间的心跳检测,

避免服务提供者被剔除掉

Cancel(服务下线)

一般在Service Provider挂了或shut down的时候调用,用来把自身的服务从Eureka Server中删除,以防客户端调用到不存在的服务。

Fetch Registries(获取注册信息),

Fetch Registries由Service Consumer(服务消费者)调用,用来获取Eureka Server上注册的服务info。

Eviction(剔除)

Eviction(失效服务剔除)用来定期在Eureka Server检测失效的服务,检测标准就是超过一定时间没有Renew的服务。

Eureka架构图

Eureka架构图如下图所示,github地址:https://github.com/netflix/eureka

document地址:https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

Application Service 在启动时注册到 Eureka 服务器,之后每 30 秒钟发送心跳以更新自身状态,即Renew(续约)。如果该客户端没能发送心跳更新,它将在 90 秒之后被其注册的 Eureka 服务器剔除,即Eviction(剔除)。

来自任意 zone 的 Application Client 可以获取这些注册信息(每隔 30 秒查看一次)并依此定位到在任何区域可以给自己提供服务的提供者(即Fetch Registries),进而进行远程调用。

服务提供者本身携带的Eureka Client既能服务注册,服务续约,也能通过client定位服务和调用其它的服务。

Renew(服务续约)

服务续约 Renew操作会在Service Provider端定期发起,用来通知Eureka Server自己还活着

eureka.instance.leaseRenewalIntervalInSeconds

Renew频率。默认是30秒,也就是每30秒会向Eureka Server发起Renew操作。

eureka.instance.leaseExpirationDurationInSeconds

服务失效时间。默认是90秒,也就是如果Eureka Server在90秒内没有接收到来自Service Provider的Renew操作,就会把Service Provider剔除。

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。

http://www.wquz.com.cn/style/images/nopic.gif
?
分享
评论
东北麻将玩法