SpringCloud系列之Eureka简介与对比

每日英文

Your inexperience is an asset and will allow you to think in original and unconventional ways.

你的经验不足也是种财富，能让你有新颖和跳出常规的点子。--娜达莉·波特曼

卯卯有话说

父亲节快乐，预祝端午节快乐。

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进行集群处理。