SpringCloud系列之Eureka简介与对比

Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来讲是很是重要的，有了服务发现与注册，只须要使用服务的标识符，就能够访问到服务，而不须要修改服务调用的配置文件了。

 

Eureka的基本架构

 

Eureka采用了C-S的设计架构，使用Eureka的客户端链接到Eureka Server并维持心跳链接，这样系统的维护人员就能够经过Eureka Server来监控系统中各个微服务是否正常运行。

 

举例说明：一座大厦，其中全部的业主买房子入住都须要去物业登记。其中物业就是我们的Eureka的服务注册中心，我们的业主就是一个个的微服务。业主交物业费就至关于Eureka维持客户端的心跳链接。

 

Eureka包含组件

 

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

 

Eureka Server提供服务注册服务

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

 

Eureka Client是一个java客户端，用于简化Eureka的交互，客户端同时也具有一个内置的、使用轮询（round-robin）负载算法的负载均衡器。

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

 

 

ACP原则

 

首先咱们来说一下ACP原则，便于一会的产品对比。

CAP是Consistency、Availablity和Partition-tolerance的缩写。

 

分别是指：

1.一致性（Consistency）：每次读操做都能保证返回的是最新数据；

2.可用性（Availablity）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果；

3.分区容忍性（Partition-torlerance）：当节点间出现网络分区，照样能够提供服务。

 

注意：在分布式系统中，CAP只能三选二，没有任何分布式架构三种都知足。

分布式架构通常要么CP要么AP，由于分布式必定要保证分区容忍性。

 

为何说是三进二呢？

 

1：知足C和A，那么P能不能知足呢？

知足C须要全部的服务器的数据要同样，也就是说要实现数据的同步，那么同步要不要时间？确定是要的，而且机器越多，同步的时间确定越慢，这里问题就来了，咱们同时也知足了A，也就是说，我要同步时间短才行。这样的话，机器就不能太多了，也就是说P是知足不了的

2：知足C和P，那么A能不能知足呢？

知足P须要不少服务器，假设有1000台服务器，同时知足了C，也就是说要保证每台机器的数据都同样，那么同步的时间可就很大，在这种状况下，咱们确定是不能保证用户随时访问每台服务器获取到的数据都是最新的，想要获取最新的，能够，你就等吧，等所有同步完了，你就能够获取到了，可是咱们的A要求短期就能够拿到想要的数据啊，这不就是矛盾了，因此说这里A是知足不了了

3：知足A和P，那么C能不能知足呢？

自行考虑一下。

与Zookeeper的对比

 

为何要讲CAP呢，由于咱们下面要对Dubbo中的Zookeeper和SpringCloud中的Eureka进行对比了。

 

与Eureka功能相似的是Dubbo的注册中心，好比Zookeeper。

 

那么Eureka和Zookeeper区别在哪里，咱们又如何进行选择呢？

Eureka开发是吸收了Zookeeper的全部教训后出现的一个产品：

Netflix在设计Eureka时遵照的是AP原则。

Zookeeper使用的是CP原则。

 

下面咱们来分析一下：

 

Zookeeper保证CP

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

 

Eureka保证AP

Eureka看明白了这一点，所以在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工做，剩余的节点依然能够提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时若是发现链接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此以外，Eureka还有一种自我保护机制，若是在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现如下几种状况： 
1. Eureka再也不从注册列表中移除由于长时间没收到心跳而应该过时的服务 
2. Eureka仍然可以接受新服务的注册和查询请求，可是不会被同步到其它节点上(即保证当前节点依然可用) 
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

所以， Eureka能够很好的应对因网络故障致使部分节点失去联系的状况，而不会像zookeeper那样使整个注册服务瘫痪。

 

小总结

Eureka做为单纯的服务注册中心来讲要比zookeeper更加“专业”，由于注册服务更重要的是可用性，咱们能够接受短时间内达不到一致性的情况。不过Eureka目前1.X版本的实现是基于servlet的java web应用，它的极限性能确定会受到影响。期待正在开发之中的2.X版本可以从servlet中独立出来成为单独可部署执行的服务。

总结

 

今天我描述了一下Eureka是什么，以及Eureka的基本组成与架构，最后作了与Dubbo的Zookeeper的对比，分析了两个组件的优劣势。下一讲我讲会进行把Eureka集成到咱们上一讲的项目当中，并把Eureka进行集群处理。