1. AP 优于CP
· eureka是在部署AWS的背景下面设计的，其设计认为，在云端，特别是大规模部署情况下面，失败是不可以避免的，可能是因为eureka自身部署失败或者网络分区等情况导致服务不可用，这些问题是不可以避免的，要解决这个问题就需要eureka在网络分区的时候，还能够正常提供服务，因此eureka选择满足availability这个特性。
· eureka选择了A也就必须放弃C，也就是说在eureka中采用最终一致性的方式来保证数据的一致性问题，因此实例的注册信息在集群的所有节点之间的数据都不是强一性的，需要客户端能支持负载均衡算法及失败重试等机制。
2. Peer to Peer 架构
一般而言在分布式系统的数据有多个副本之间的复制方式，可以分为主从复制和对等复制
主从复制 Master-Slave模式
一个主副本和多个从副本，所有数据的写操作都是提交到主副本，最后由主副本更新到其他的从副本(常采用异步更新)，通常写是整个系统的瓶颈所在。
对等复制 即Peer to Peer模式
副本之间不分主从，任何的副本都可以接受写数据，然后副本之间进行数据更新。在对等复制中，由于每一个副本都可以进行写操作，各个副本之间的数据同步及冲突处理是一个比较难解决的问题。
3. Zone 及 Region 设计
· 使用region来代表一个独立的地理区域，比如us-east-1、us-east-2,、us-west-1等。在每一个region下面还分为多个AvailabilityZone，一个region对应多个AvailabilityZone，不同的region之间相互隔离。默认情况下面资源只是在单个region之间的AvailabilityZone之间进行复制，跨region之间不会进行资源的复制。
· AvailabilityZone看成是region下面的一个一个机房，各个机房相对独立，主要是为了region的高可用考虑的，一个region下面的机房挂了，还有其他的机房可以使用。
· 一个AvailabilityZone可以设置多个server实例，他们之间构成peer节点，然后采用peer to peer的复制模式进行数据复制。
4. Self Preservation 设计
在分布式系统设计中，通常需要对应用实例的存活进行健康检验，这里比较难处理的就是网络偶尔抖动或者短暂不可用而造成的误判。因此eureka设计了self preservation机制。server和client之间有一个租约，client定期发送心跳来维护这个租约，表示心跳还活着，eureka通过当前注册的实例数量，去计算每分钟应用从应用实例接受到的心跳数量，如果近一分钟接受到的租约的次数小于等于指定的阈值，则关闭租约失效剔除，禁止定时任务剔除失效的实例，从而保护注册信息。
自我保护模式的设计哲学是：在不确定节点是否可用的情况下，尽可能保留节点!
