Eureka&Zookeeper&Consul

Eureka (尤里卡)(参考

功能:用于定位服务,以实现中间层服务器的负载平衡和故障转移。中间层负载均衡不会对外暴露服务路由信息(更安全)

内置两个角色:

Eureka Server: 维护服务路由信息

Eureka Client:从Eureka Server获取服务路由信息,通过内置的负载均衡向应用程序服务发出请求(在SpringCloud中服务的提供方与服务的消费方度是Eureka Client)

更新

Eureka Client需要每30秒发送一次心跳来续订租约。续订通知Eureka Server该实例仍然存在。如果Eureka Server没有看到续订90秒,它会将实例从其注册表中删除。

获取注册表

Eureka Client从Eureka Server获取注册表信息并在本地缓存它。之后,Eureka Client使用该信息来查找其他服务。通过获取最后一个获取周期和当前获取周期之间的增量更新,定期(每30秒)更新此信息。增量信息在服务器中保持更长时间(约3分钟),因此增量提取可能会再次返回相同的实例。Eureka Client自动处理重复信息。

获得增量后,Eureka Client通过比较Eureka Server返回的实例计数来协调与Eureka Server的信息,如果信息由于某种原因不匹配,则再次获取整个注册表信息。

取消

Eureka Client在关机时向Eureka Server发送取消请求。这将从Eureka Server的实例注册表中删除实例,从而有效地将实例从流量中删除。

时滞

来自Eureka Client的所有操作可能需要一些时间才能反映在Eureka Server中以及其他Eureka Client中。这是因为Eureka Server上的有效负载缓存会定期刷新以反映新信息。Eureka Client还定期获取增量。因此,更改传播到所有Eureka Client可能需要2分钟。

沟通机制

默认情况下,Eureka Client使用Jersey和Jackson以及JSON有效负载与Eureka Server进行通信。您可以通过覆盖默认机制来使用您选择的机制。

负载均衡

Eureka的负载平衡发生在实例/中间层服务器/主机级别。客户端(Eureka Client)知道他们需要与哪些服务器通信的所有信息。

案例:

案例说明:

Application Server 通过内置的Eureka client将服务注册在Eureka Server上,然后发送心跳每30秒更新一次租约。如果内置的Eureka Client无法续订租约3次以上(90秒),Eureka Server将其从注册表中删除。注册信息和续订将复制到群集中的所有Eureka server节点。来自任何区域的Eureka Client(其中包含服务消费端)都可以查找注册表信息(每30秒发生一次)以查找其服务(可能位于任何区域中)并进行远程调用。

 

Zookeeper:(参考

1、领导者:负责接受来自客户的所有传入状态更改,即所有写入操作度先转发给领导者,由领导者发起提案(只能领导者能提案)。

提案将发送到所有ZooKeeper服务器,并在法定人数确认提案时提交及向所有粉丝发出COMMIT,达不到法定人数确认将会丢失提案。如果提案包含消息,则在提交提案时将传递消息。确认意味着服务器已将提议记录到持久存储。我们的法定人数要求任何一对仲裁必须至少有一个共同的服务器(leader)。我们通过要求所有法定人数的大小(n / 2 + 1)来确保这一点)其中n是组成ZooKeeper服务的服务器数量。

数据保存在内存中,因此ZooKeeper能够获得非常高的吞吐量和低延迟数

只要大多数服务器可用,ZooKeeper服务就可用

ZooKeeper客户端发送的读取请求在客户端连接的ZooKeeper服务器本地处理。如果是写入请求将转发到其他ZooKeeper服务器,并在生成响应之前达成共识。同步请求也会转发到另一台服务器,但实际上并未达成共识。因此,读取请求的吞吐量随着服务器的数量而变化,并且写入请求的吞吐量随着服务器的数量而减少。

ZooKeeper网站上发布的博客中所说:在ZooKeeper中,如果在同一个网络分区(partition)的节点数(nodes)数达不到ZooKeeper选取Leader节点的“法定人数”时,它们就会从ZooKeeper中断开,当然同时也就不能提供Service发现服务了

 

为什么不使用Zookeeper作为服务注册表?

1、zookeeper在写入操作必须得到法定人数确认才能成功提交。

2、zookeeper在选举期间会停止对外服务

选Eureka理由:(参考

1、Eureka客户试图与Eureka Server交互。如果与服务器通信时出现问题或者同一区域中不存在服务器,则客户端将故障转移到其他区域中的服务器。

2、一旦服务器开始接收流量,服务器上执行的所有操作都将复制到服务器知道的所有对等节点。如果某个操作由于某种原因而失败,则会在下一个也会在服务器之间复制的心跳上协调该信息。

 

Consul(参考

案例解说:

上图有两个consul数据中心:DATACENTER1和DATACENTER2。在每个数据中心内,我们都有客户端和服务器的混合体。预计有三到五台服务器。这在失败和性能的可用性之间取得平衡,因为随着更多机器的添加,共识逐渐变慢。但是,客户端数量没有限制,可以轻松扩展到数千或数万。

服务器都在此池中运行,因此它还支持跨数据中心请求。当服务器收到对不同数据中心的请求时,它会将其转发到正确数据中心的随机服务器。然后该服务器可以转发给本地领导者。因为不会在不同的Consul数据中心之间复制数据。

 

Eureka作为服务治理中心缺点:

1、当客户端向服务器注册时,该服务器将尝试复制到其他服务器但不提供保证——导致提供过时或丢失的数据。服务注册的生存时间很短,要求客户端对服务器进行心跳检测。

Consul优势:

1、Consul提供了一系列超级功能,包括更丰富的健康检查,键/值存储和多数据中心感知。

2、Consul提供强大的一致性保证,因为服务器使用Raft协议复制状态

 

 

©️2020 CSDN 皮肤主题: 创作都市 设计师:CSDN官方博客 返回首页