1。AP比CP好。eureka是在部署AWS的背景下设计的。它的设计认为在云中失败是不可避免的，尤其是在大规模部署中。可能是因为eureka本身部署失败或者网络分区等情况导致服务不可用。这些问题是不可避免的。为了解决这个问题，eureka需要在网络分区的情况下能够正常提供服务。因此，eureka选择满足可用性特性。当eureka选择A时，必须放弃C。也就是说，在eureka中，采用最终一致性的方式来保证数据的一致性。因此，实例的注册信息在集群的所有节点中都不强。是的，客户端需要支持负载均衡算法、失败重试等机制。2.PeertoPeer架构一般来说，分布式系统中的数据有多种复制方式，可以分为主从复制和对等复制。Master-slavereplicationMaster-Slavemode一个主副本和多个从副本，所有的数据写入操作都提交到主副本，最后从主副本更新到其他从副本（经常使用异步更新），通常写入是瓶颈整个系统。点对点复制是指PeertoPeer模式下副本之间没有主从之分。任何副本都可以接受写入的数据，然后在副本之间进行数据更新。在对等复制中，由于每个副本都可以进行写操作，所以副本之间的数据同步和冲突处理是一个比较难解决的问题。3.Zone和Region设计·用region表示一个独立的地理区域，比如us-east-1,us-east-2,us-west-1等。每个region分为多个AvailabilityZone，一个region对应多个AvailabilityZones，不同地域之间相互隔离。默认情况下，资源只会在单个区域的可用区之间复制，不会跨区域复制资源。·AvailabilityZone被视为该区域下的各个机房。每个机房相对独立，主要是为了区域的高可用性。如果一个区域下的机房宕机了，还有其他机房可以使用。·一个AvailabilityZone可以设置多个服务器实例，它们组成对等节点，然后使用对等复制模式进行数据复制。4.SelfPreservation设计在分布式系统设计中，通常需要对应用实例的存活进行健康检查。这里比较难处理的是偶尔的网络抖动或者暂时不可用导致的误判。因此，eureka设计了自我保护机制。服务器和客户端之间存在租约。客户端定时发送心跳来维护租约，说明心跳还活着。Eureka使用当前注册的实例数来计算应用程序每分钟从应用程序实例接收到的心跳数。如果在一分钟内接收到的租约数量小于或等于指定阈值，则禁用租约失效消除，禁止定时任务消除无效实例，从而保护注册信息。自保模式的设计理念是：在不确定节点是否可用的情况下，尽可能保留节点！
