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协议复制状态