SpringCloud --- Eureka

一、Eureka是什么

Eureka是Netflix组件的一个子模块，也是核心模块之一。云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移

Eureka服务端（以下简称服务端）与Eureka客户端（以下简称客户端）之间协同工作的流程：

二、Eureka优缺点

优点：

（1）故障转移：

在Eureka平台中，如果某台服务器宕机，Eureka不会像zookeeper选择leader的过程，客户端请求会自动切换到新的Eureka节点，当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理中，而对于它而言，所有要做的无非是同步一些新的服务注册信息。所以不用担心“掉队”的服务器恢复以后，会从Eureka服务器集群中踢除的风险。

（2）客户端缓存功能：

Eureka还有客户端缓存功能（Eureka分为客户端程序与服务端程序两个部分，客户端程序负责向外提供注册与发现服务接口）所以即便Eureka集群中所有节点都失效，或者发生网络分割故障导致客户端不能访问任何一台Eureka服务器；

Eureka服务的消费者仍然可以通过Eureka客户端缓存来获取现有的服务注册信息。甚至最极端的环境下，所有正常的Eureka节点都不对请求产生相应，也没有更好的服务器解决方案来解决这种问题时；得益于Eureka的客户端缓存技术，消费者服务仍然可以通过Eureka客户端查询与获取注册服务信息，这点很重要。

缺点：

（1）配置地址麻烦：实际生产中，不会将服务注册中心与业务服务部署在同一台机器上。实际部署中，当 eureka server 的地址发生变化时，还得修改配置文件里 eureka server的地址，太麻烦了。

（2）服务发现慢： eureka因为缓存设计的原因，使得服务注册上去之后，最迟需要两分钟后才能发现。

（3）安全性问题：实际使用中，服务注册发现中心的安全性也是需要考虑的，应该对服务注册和发现的请求进行鉴权，来确保服务的安全性，安全也是急需解决的问题。

• Eureka从理论上讲作为系统服务的注册中心是最适合的。

备注：

也有不少人认为，在现实生产环境中他（她）遇到的很多项目都采用的是 Zookeeper + Dubbo 实现的服务注册与发现，那是因为你们的集群（业务流量需求）还不够庞大，流量小，一般环境运行都比较稳定的，基本上不会遇到注册中心的实例（节点）半数以上都挂了的情况，问题也不会那么的明显罢了，或根本就遇不到。

三、Eureka原理

注册表这块是采用三级缓存register-Map ==> readWriterMap ==> readOnlyMap，提高并发能力的同时，防止出现并发加锁解锁的开销以及安全问题；

四、Eureka主要功能：

（1）服务注册：

Eureka Client会通过发送HTTP REST请求的方式向Eureka Server将自己注册为服务，提供自身的元数据，比如 IP 地址、端口、运行状况指标的URL、主页地址等信息。Eureka Server接收到注册请求后，就会把这些元数据信息存储在一个ConcurrentHashMap中。

（2）服务续约：

在服务注册后，Eureka Client会维护一个心跳来持续通知Eureka Server，说明服务一直处于可用状态，防止被剔除。Eureka Client在默认的情况下会每隔30秒发送一次心跳来进行服务续约。

（3）服务同步：

Eureka Server之间会互相进行注册，构建Eureka Server集群，不同Eureka Server之间会进行服务同步，用来保证服务信息的一致性。

（4）获取服务：

服务消费者（Eureka Client）在启动的时候，会发送一个Http REST请求给Eureka Server，获取上面所有注册的服务清单，并且缓存在Eureka Client本地，默认缓存30秒。同时，为了性能考虑，Eureka Server也会维护一份只读的服务清单缓存，该缓存每隔30秒更新一次。[由eureka server进行更新]

（5）服务调用：

服务消费者（Eureka Client）在获取到服务清单后，就可以根据清单中的服务列表信息，查找到其他服务的地址，从而进行远程调用。Eureka有Region和Zone的概念，一个Region可以包含多个Zone，在进行服务调用时，优先访问处于同一个Zone中的服务提供者。

（6）服务下线：

当Eureka Client需要关闭或重启时，就不希望在这个时间段内再有请求进来，所以，就需要提前先发送REST请求给Eureka Server，告诉Eureka Server自己要下线了，Eureka Server在收到请求后，就会把该服务状态置为下线（DOWN），并把该下线事件传播出去。

（7）服务剔除：

有时候，服务实例可能会因为网络故障等原因导致不能提供服务，而此时该实例也没有发送请求给Eureka Server来进行服务下线，所以，还需要有服务剔除的机制。Eureka Server在启动的时候会创建一个定时任务，每隔一段时间（默认60秒），从当前服务清单中把超时没有续约（默认90秒）的服务剔除。

（8）自我保护：

既然Eureka Server会定时剔除超时没有续约的服务，那就有可能出现一种场景，网络一段时间内发生了异常，所有的服务都没能够进行续约，Eureka Server就把所有的服务都剔除了，这样显然不太合理。所以，就有了自我保护机制，当短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。

备注：

1.Eureka与Zookeeper比较

（1）Zookeeper是CP，分布式协同服务，突出一致性。对ZooKeeper的的每次请求都能得到一致的数据结果，但是无法保证每次访问服务可用性。如请求到来时，zookeer正在做leader选举，此时不能提供服务，即不满足A可用性。

即任何时刻对zookeeper的访问请求能得到一致的数据结果，同时系统对网络分区具有容错性；但是它不保证每次服务请求都是可用的。极端环境下，zookeeper会丢弃一些请求，消费者端需要重新请求才能得到结果。

作为zookeeper的核心算法Zab（zookeeper  Atomic Broadcast，全称：原子消息广播协议），就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。

（2）Euerka是AP，高可用与可伸缩的Service发现服务，突出可用性。相对于Zookeeper而言，可能返回数据没有一致性，但是保证能够返回数据，服务是可用的。

2.CAP定理：

概念：⼀个分布式系统最多只能同时满⾜⼀致性（Consistency）、可⽤性（Availability）和分区容错性（Partition tolerance）这
三项中的两项。

• C:Consistency ，一致性。更新操作成功并返回客户端完成后，所有节点在同⼀时间的数据完全⼀致，所以，⼀致性，说的就是数据⼀致性。
• A: Availability，可用性。服务⼀直可⽤，⽽且是正常响应时间。
• P:Partition tolerance，分区容错性。类似多机房部署，保证服务稳定性。分布式系统在遇到某节点或⽹络分区故障的时候，仍然能够对外提供满⾜⼀致性和可⽤性的服务。