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不为空时，进行以下处理：
- 如果请求的lastDirtyTimestamp值大于Server本地该实例的lastDirtyTimestamp值，则表示Eureka Server之间的数据冲突，这个时候返回404，要求应用实例重新进行register操作；
- 如果请求的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端通过当前注册的实例数，去计算每分钟应该从应用实例接收到的心跳数，如果最近一分钟接收到的续约的次数小于指定的阈值，则关闭租约失效剔除，禁止定时任务剔除失效的实例，从而保护注册信息。
