Eureka 的设计理念
服务实例注册到服务中心
服务的注册，本质上就是在服务启动的时候，调用 Eureka Server 的 REST API 的 Registrer 方法，注册应用实例的信息。对于 Java 应用，可以使用 Netflix 的 Eureka Client 封装 API 调用；对于 Spring Cloud 应用，可以使用 spring-cloud-starter-netflix-eureka-client 基于 Spring Boot 自动配置，自动注册服务。
服务实体从服务中心剔除
正常情况下，服务实例在关闭应用的时候，应该通过钩子方法或其他生命周期回调方法，调用 Eureka Server 的 REST API 的 de-register 方法，来删除自身服务实例的信息。另外，为了解决服务挂掉，或网络中断等其他异常情况没有及时删除自身信息的问题，Eureka Server 要求 Client 定时进行续约，也就是发送心跳，来证明自己是存活的、健康的、可调用的。如果超过一定时间没有续约，则认为 Client 停掉了，Server 端会主动剔除。
服务实例一致性问题
由于注册中心（Eureka Server）通常来说是一个集群，就需要 Client 在集群中保持一致。Eureka 通过 CAP、Peer to Peer、Zone + Region、SELF PRESERVATION 四个方面保证一致性。
CAP
C：Consistency，数据一致性。即数据在存在多个副本的情况下，可能由于网络、机器故障、软件系统等问题早上数据写入部分副本成功，副本副本失败，进而造成副本之间数据不一致，存在冲突。满足一致性则要求对数据的更新操作成功后，多副本的数据保持一致。
A：Availablility，服务可用性。在任何时候，客户端对集群进行读写操作时，请求能够正常响应，即，在一定的时间内完成。
P：Partition Tolerance，分区容忍性，即发生通信故障的时候，整个集群被分隔成多个无法相互通信的分区时，集群仍然可用。
在分布式系统中，网络条件一般是不可控的，网络分区是不可避免的，因此分布式系统必须满足分区容忍性，所以分布式系统的设计需要在 AP、CP 之间进行选择。
Zookeeper 是 CP Eureka是CA
Peer to Peer
分布式系统的数据在多个副本直接的复制方式，可分为：主从复制、对等复制
主从复制
主从复制，就是 Master-Slave 模式，有一个主副本，其他为从副本。所有的对数据的写操作，都提交到主副本，然后由主副本更新到其他的从副本。具体的更新方式有：同步更新、异步更新、同步异步混合更新。
对于主从复制的模式，写操作都要经过主副本，所有主副本的压力会很大。但是，从副本会分担主副本的读请求，而一个系统最大的请求都是读请求，所有可以一般情况下都是一主多从的架构。
对等复制
即 Peer to Peer 模式。副本之间不分主从，任何副本都能接收写操作，然后每个副本之间相互进行数据更新。对于对等复制模式来说，由于任何副本都可以接收到写操作，所以不存在写操作的压力瓶颈。但是由于每个副本都能进行写操作，各个副本之间的数据同步及冲突处理是一个比较棘手的问题。
Eureka 采用的就是 Peer to Peer
SELF PRESERVATION
在分布式系统中，通常需要对应用实例的存活进行健康检查，需要处理好网络抖动或短暂的不可用造成的误判；另外，Eureka Server 和 Client 之间如果存在网络分区，在极端情况下可能会导致 Eureka Server 情况部分服务的实例列表，这个将严重影响到 Eureka Server 的高可用。因此，Eureka 引入了自我保护机制(SELF PRESERVATION)。
Client 与 Server 之间有租约，Client 需要定时发送心跳维持租约，表示自己存活。Eureka 通过当前注册的实例数，计算每分钟应该从应用实例接收到的心跳数，如果最近一分钟接收到的续约次数小于指定的阈值的话，则关闭租约失效剔除，进制定时任务剔除失效的实例，从而保护注册信息。