SpringCloud Eureka认知(一)

Eureka简介

　　Eureka是Nerflix公司开源的一款服务发现（或注册中心）组件，该组件提供的服务发现能够为负载均衡、failover等提供支持。

　　Eureka包括Eureka Server和Eureka Client。Eureka Server提供REST服务，Eureka Client则是使用Java编写的客户端，用于简化与Eureka Server的交互。

服务发现组件对比

名称	类型	AP或CP	语言	依赖	集成	一致性算法
Zookeeper	General	CP	Java	JVM	Client Binding	Paxos
Doozer	General	CP	GO		Client Binding	Paxos
Consul	General	CP	GO			Raft
Etcd	General	CP	GO			Raft
SmarkStack	Dedicated	AP	Ruby	Zookerper
Eureka	Dedicated	AP	Java	JVM	Java Client

CAP理论

　　分布式领域有个重要的CAP理论：

1. Consistency：数据一致性，即数据存在多个副本的状况下，可能因为网络、机器故障、软件系统等问题致使数据写入部分副本成功，部分副本失败，进而形成副本之间的数据不一致，存在冲突。知足数据一致性要求对数据的更新操做成功后，多副本的数据报保持一致。
2. Availability：高可用，即任什么时候候客户端对集群进行读写操做时，请求能正常响应，即在必定的延迟内完成。
3. Partition Tolerance：分区容忍性，即发生通讯故障时，整个分区被分割为多个相互独立的没法通讯的分区时，集群仍可用。

　　对于分布式系统，通常网络条件不可控，出现网络分区是不可避免的，所以系统必须具有分区容忍性。

分布式系统的数据在多个副本之间的复制方式

　　通常而言，分布式系统的数据在多个副本之间的复制方式可分为主从复制和对等复制。

　　主从复制即Master-Slave模式，即有一个主副本，其余副本为从副本。全部对数据的写操做都提交到主副本，最后再由主副本更新到从副本，具体的更新方式有同步更新、异步更新、同步及异步混合。对于主从复制模式，写操做的压力主要都在主副本，从副本帮主副本分担读操做请求。

　　对等复制即Peer to Peer，即任何副本都是对等的，任何副本均可以接收写操做请求，而后每一个副本进行数据更新。

Zookeeper的CP原则

　　Zookeeper默认并非严格的强一致性，好比客户端A提交一个写操做，Zookeeper在半数节点操做成功后就返回，此时假设客户端B读操做请求的刚好是A写操做还没有同步到的节点，那么读取到的就不是客户端A写操做成功后的数据。

　　若是须要保证数据的强一致性，则须要在读取数据的时候先执行一下sync操做，即与leader节点先同步下数据。

　　Zookeeper不知足高可用特性，当 master 节点(主副本)由于网络故障与其余节点失去联系时，剩余节点会从新进行 leader 选举。问题在于，选举 leader 的时间太长，30 ~ 120s, 且选举期间整个 zookeeper 集群都是不可用的，这就致使在选举期间注册服务瘫痪。

Eureka的AP原则

　　Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工做，剩余的节点依然能够提供注册和查询服务。

　　而Eureka的客户端在向某个Eureka注册或时若是发现链接失败,则会自动切换至其它节点,只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。

　　除此以外, Eureka还有一种自我保护机制,若是在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现如下几种状况

1. Eureka再也不从注册列表中移除由于长时间没收到心跳而应该过时的服务
2. Eureka仍然可以接受新服务的注册和查询请求,可是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中.

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