平衡之美

1. AP 优于CP

eureka是在引进AWS的背景下设计的。 云，特别是大规模部署的情况下，被认为失败是不可避免的。 由于eureka自身的导入失败和网络分区等原因，服务可能无法使用，这些问题不可避免。 为了解决这个问题，eureka需要能够在网络分区正常提供服务，所以eureka选择了满足AvaVaS

如果 eureka选择了a，就必须放弃c。 也就是说，为了在eureka中采用最终的一致性方式来保证数据的一致性，实例的注册信息在集群的所有节点之间不是唯一的，客户端需要能够支持负载均衡算法和失败重试等机制。

2. Peer to Peer 架构

分布式系统中的数据通常有多种拷贝之间的复制方法，分为主从复制和对等复制

主从复制 Master-Slave模式

主副本和多个从副本。 所有数据的写入都将提交到主副本，最终从主副本更新到其他从副本。 写操作通常是整个系统的瓶颈。

对等复制 即Peer to Peer模式

副本之间与主从无关，任何副本都可以接受写入数据，并在副本之间进行数据更新。 在对等应用程序中，每个拷贝都是可写的，因此每个拷贝之间的数据同步和冲突处理是一个相对困难的问题。

使用

3. Zone 及 Region 设计

区域表示独立的地理区域，如美国-东部- 1、美国-东部- 2、美国-西部- 1等。 在各自的region下被分为多个AvailabilityZone，一个region对应多个AvailabilityZone，不同的region之间相互隔离。 缺省情况下，以下资源只是在单个区域之间的AvailabilityZone之间复制，而不是在区域之间复制资源：

AvailabilityZone视为region下的每一个机房。 各个机房比较独立，主要是为了region的高可用性而考虑的。 一个region下面的机房死机，其他机房可以使用。

可以在一个AvailabilityZone上设置多个服务器实例，在它们之间配置对等节点，以对等复制模式进行数据复制。

4. Self Preservation 设计

在分布式系统设计中，通常需要对应用实例的生存进行健康检查，这里难以应对的是网络有时抖动，有时无法使用而导致的误判。 因此，eureka设计了自准备机制。 server和client之间有一个租约，client定期发送心跳信号以维持这个租约，并表示心跳信号还活着。 eureka根据当前注册的实例数，计算一分钟从APP实例接收的心跳数，如果一分钟接收的租用次数小于等于指定阈值，则关闭租用失效排除，计算调度任务失效的实例的

自我保护模型的设计哲学是，如果不知道节点是否可用，则尽可能保留节点！