Eureka -- 浅谈Eureka

目录：

　　一：Eureka介绍

　　二：Eureka架构图

　　三：Eureka组件

　　四：Eureka做用

　　五：Eureka和Zookeeper对比

什么是Eureka

　　引入SpringCloud中文文档介绍

Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers.

At Netflix, Eureka is used for the following purposes apart from playing a critical part in mid-tier load balancing.

• For aiding Netflix Asgard - an open source service which makes cloud deployments easier, in

  • Fast rollback of versions in case of problems avoiding the re-launch of 100's of instances which could take a long time.
  • In rolling pushes, for avoiding propagation of a new version to all instances in case of problems.

• For our cassandra deployments to take instances out of traffic for maintenance.

• For our memcached caching services to identify the list of nodes in the ring.

• For carrying other additional application specific metadata about services for various other reasons.

　　意思为：

Eureka是一种基于REST（Representational State Transfer）的服务，主要用于AWS云，用于定位服务，以实现中间层服务器的负载平衡和故障转移。

在Netflix，除了在中间层负载平衡中起关键做用以外，Eureka还用于如下目的。

• 为了帮助Netflix Asgard - 一种开源服务，能够更轻松地实现云部署

  • 在出现问题的状况下快速回滚版本，避免从新启动可能须要很长时间的100个实例。
  • 在滚动推送中，以免在出现问题时将新版本传播到全部实例。

• 对于咱们的cassandra部署，将实例从流量中取出进行维护。

• 对于咱们的memcached缓存服务来识别环中的节点列表。

• 因为各类其余缘由而携带有关服务的其余应用程序特定元数据。

 

Eureka架构图

　　上面的架构图描述了Eureka是如何在Netflix部署的，这也是Eureka集群的运行方式。在每一个区域（region）都有一个eureka集群，它只知道该区域内的实例信息。每一个分区（zone）至少有一个eureka服务器来处理本分区故障。

　　服务注册在Eureka上而且每30秒发送心跳来续租。若是一个客户端在几回内没有刷新心跳，它将在大约90秒内被移出服务器注册表。注册信息和更新信息会在整个eureka集群的节点进行复制。任何分区的客户端均可查找注册中心信息（每30秒发生一次）来定位他们的服务（可能会在任何分区）并进行远程调用。

　　摘自：Eureka at a glance  

Eureka组件

　　Eureka包含两个组件：Eureka Server和Eureka Client。

　　Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储全部可用服务节点的信息，服务节点的信息能够在界面中直观的看到。

　　Eureka Client是一个java客户端，用于简化与Eureka Server的交互，客户端同时也就别一个内置的、使用轮询(round-robin)负载算法的负载均衡器。

　　在应用启动后，将会向Eureka Server发送心跳,默认周期为30秒，若是Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。

　　Eureka Server之间经过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即便全部的Eureka Server都挂掉，客户端依然能够利用缓存中的信息消费其余服务的API。综上，Eureka经过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

　　摘自： Eureka（服务发现框架）

Eureka做用

　　在多个服务节点下，若是经过人为管理地址配置，随着节点增多，会出现不方便管理，不方便维护的状况。  所以须要一一个服务治理的中间件协助咱们管理注册的服务节点。

　　常见的注册中心有　　　

　　　　如: eureka ，zookeeper, consul, redis等。-般在eureka中会保存节点的IP地址，端口号，服务名等

 

      注册方式
　　　　1.中心化配置:用一个统一的注册中心管理各个节点，如zookeeper

　　　　2.去中心化配置:每一个服务既是服务端又是客户端，如: eureka 

Zookeeper和Eureka对比

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

　　zookeeper优先保证CP，当服务发生故障会进行leader的选举，整个期间服务处在不可用状态，若是选举时间过长势必会大幅度下降性能，另外就用途来讲zookeeper偏向于服务的协调，固然含有注册中心的做用

　　eureka优先保证AP, 即服务的节点各个都是平等的，没有leader不leader一说， 当服务发生故障时，其他的节点仍然能够提供服务，所以在出现故障时，性能表现优于zookeeper，可是可能会形成数据不一致的状况。

 

　总结：Eureka做为单纯的服务注册中心来讲要比zookeeper更加“专业”，由于注册服务更重要的是可用性，咱们能够接受短时间内达不到一致性的情况。