SpringCloud Eureka设计理念(二)

AP优于CP

　　Eureka设计者认为，在云端，特别是大规模部署的状况下，失败是不可避免的，可能由于Eureka自身部署失败，致使注册服务不可用，或者网络分区致使服务不可用，所以Eureka选择知足Availability这个特性。即Eureka全部节点都是对等的，即便挂掉几个节点，其余正常的几点仍能提供服务。

Peer to Peer 对等架构

　　Eureka Server采用的就是Peer to Peer的复制模式。

　　Eureka Server自己依赖客户端，也就是每一个Eureka Server做为其余Eureka Server的Client。在单个Eureka Server启动的时候，会有一个syncUp的操做，经过Eureka Client请求其余的Eureka Server节点中的一个节点获取注册的应用实例信息，而后复制到其余的peer节点。

　　Eureka Server在执行复制操做的时候，使用HEADER_REPLICATION的http header来将这个请求操做与普通应用实例的正常请求操做区分来。经过HEADER_REPLICATION来标志复制请求，这样其余peer节点收到请求的时候，就不会对它的peer节点进行复制操做，避免死循环。

　　Eureka Client客户端使用quarantineSet维护了一个不可用的Eureka Server列表，进行请求的时候，优先从列表中进行选择，若是请求失败则切换到下一个Eureka Server进行重试，重试的次数默认为3次。另外为了防止客户端都按配置文件指定的顺序进行请求形成Eureka Server节点请求分布不均衡的状况，客户端有个定时任务（默认5分钟执行一次）来刷新并随机化Eureka Server列表。

Eureka解决复制冲突的方式

　　针对数据的一致性，通常是经过版本号机制来解决，最后在不一样版本之间只须要判断请复制数据的版本号与本地数据的版本号高低就能够了。Eureka没有直接使用版本号的属性，而是采用一个叫作lastDirtyTimestamp的字段来对比。

　　若是开启SyncWhenTimestampDiffers配置（默认开启），当lastDirtyTimestamp不为空时，进行如下处理：

1. 若是请求的lastDirtyTimestamp值大于Server本地该实例的lastDirtyTimestamp值，则表示Eureka Server之间的数据冲突，这个时候返回404，要求应用实例从新进行register操做；
2. 若是请求的lastDirtyTimestamp值小于Server本地该实例的lastDirtyTimestamp值，若是是peer节点的复制请求，则表示数据出现冲突，返回409给peer节点，要求其同步本地实例最新的数据。

　　peer节点的相互复制并不能保证全部操做都能成功，所以Eureka还经过应用实例与Server之间的heartbeat(心跳)也就是renewLease（租约）操做来进行数据的最终恢复，即若是发现应用实例数据与某个server的数据出现不一致，则Server返回404，应用实例从新进行register操做。

Zone以及Region的设计

　　Eureka Server默认设置了4个Region，在每一个Region下面还分了多个AvailabilityZone；每一个Region是相互独立及隔离的，默认状况下资源只在单个Region之间的AvailabilityZone之间复制，所以Eureka Server的高可用主要就在与Region下的AvailabilityZone。

　　Eureka Client支持preferSameZone,也就是Eureka Server的serviceUrl优先拉取跟应用实例在同一个AvailabilityZone的Eureka Server地址列表。

SELF PRESERVATION 自我保护机制设计

　　Eureka Server与Eureka Client端之间有个租约，Client要定时发送心跳来维持这个租约，表示本身还活着。Eureka Server端经过当前注册的实例数，去计算每分钟应该从应用实例接收到的心跳数，若是最近一分钟接收到的续约的次数小于指定的阈值，则关闭租约失效剔除，禁止定时任务剔除失效的实例，从而保护注册信息。