Eureka 是 Netflix 开发的服务发现框架，本身就是一个基于 REST 的服务。Spring Cloud 将它集成在其子项目 spring-cloud-netflix 中，用来实现服务的注册与发现功能。
服务注册
在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，包括服务的主机与端口号、服务版本号、通讯协议等一些附加信息。注册中心按照服务名分类组织服务清单，同时还需要以心跳检测的方式去监测清单中的服务是否可用，若不可用需要从服务清单中剔除，以达到排除故障服务的效果。
服务发现
在服务治理框架下，服务间的调用不再通过指定具体的实例地址来实现，而是通过服务名发起请求调用实现。服务调用方通过服务名从服务注册中心的服务清单中获取服务实例的列表清单，通过指定的负载均衡策略取出一个服务实例位置来进行服务调用。
Zookeeper和Eureka的选择
在分布式系统中有个著名的CAP定理（C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个）；
Zookeeper
Zookeeper是基于CP来设计的，即任何时刻对Zookeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务请求的可用性。从实际情况来分析，在使用Zookeeper获取服务列表时，如果zookeeper正在选主，或者Zookeeper集群中半数以上机器不可用，那么将无法获得数据。所以说，Zookeeper不能保证服务可用性。
Eureka
而Spring Cloud Netflix在设计Eureka时遵守的就是AP原则。Eureka Server也可以运行多个实例来构建集群，解决单点问题，但不同于ZooKeeper的选举leader的过程，Eureka Server采用的是Peer to Peer对等通信。这是一种去中心化的架构，无master/slave区分，每一个Peer都是对等的。在这种架构中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的serviceUrl指向其他节点。每个节点都可被视为其他节点的副本。
如果某台Eureka Server宕机，Eureka Client的请求会自动切换到新的Eureka Server节点，当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会进行replicateToPeer（节点间复制）操作，将请求复制到其他Eureka Server当前所知的所有节点中。
总结
Eureka作为注册中心更加专业。项目中也可能会使用ZooKeeper，那是因为集群不够大，并且基本不会遇到用做注册中心的机器一半以上都挂了的情况。所以实际上也没什么大问题。
工作原理
-
架构图
-
组件之间的调用关系
服务提供者
1、启动服务：服务提供者会向服务注册中心发起 Register 请求，注册服务。
2、运行过程中：服务提供者会定时向注册中心发送 Renew 心跳，告诉它“我还活着”。
3、停止服务提供：服务提供者会向服务注册中心发送 Cancel 请求，告诉它清空当前服务注册信息。服务消费者
1、启动后：从服务注册中心拉取服务注册信息。
2、运行过程中：定时更新服务注册信息。
3、发起远程调用：1）服务消费者会从服务注册中心选择同机房的服务提供者，然后发起远程调用，只有同机房的服务提供者宕机才会去选择其他机房的服务提供者。2）如果服务消费者发现同机房没有服务提供者，则会按照负载均衡算法选择其他机房的服务提供者，然后发起远程调用。注册中心
1、启动后：从其他节点拉取服务注册信息。
2、运行过程中：1）定时运行 Evict 任务，定时清理没有按时发送 Renew 的服务提供者，这里的清理会将非常正常停止、网络异常等其他因素引起的所有服务。2）接收到的 Register、Renew、Cancel 请求，都会同步到其他的注册中心节点。Eureka Server
通过 Register、Renew、Get Registry 等接口提供服务的注册、发现和心跳检测等。
Eureka Client
一个 java 客户端，用于简化与 Eureka Server 的交互，客户端本身也内置了负载均衡器（默认使用 round-robin 方式），在启动后会向 Eureka Server 发送心跳检测，默认周期为 30s，Eureka Server 如果在多个心跳周期内没有接收到 Eureka client 的某一个节点的心跳请求，Eureka Server 会从服务注册中心清理到对应的 Eureka Client 的服务节点（默认 90s）。
-
数据结构
服务存储的数据结构可以简单的理解为是一个两层的 HashMap 结构（为了保证线程安全使用的 ConcurrentHashMap），具体的我们可以查看源码中的AbstractInstanceRegistry类：
private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();第一层 ConcurrentHashMap 的 key=spring.application.name，也就是应用名称，value 为 ConcurrentHashMap。
第二层 ConcurrentHashMap 的 key=instanceId，也就是服务的唯一实例 id，value 为 Lease 对象，也就是具体的服务。Lease 其实就是对 InstanceInfo 的包装，里面保存了实例信息、服务注册的时间等。具体的我们可以查看InstanceInfo源码。
-
缓存
Eureka Server 为了提供响应效率，提供了两层的缓存结构，将 Eureka Client 所需要的注册信息，直接存储在缓存结构中。
-
一级缓存：readOnlyCacheMap，本质上是 ConcurrentHashMap，没有过期时间，保存服务信息的对外输出的数据结构。依赖定时从 readWriteCacheMap 同步数据，默认时间为 30 秒。
readOnlyCacheMap ： 是一个 CurrentHashMap 只读缓存，这个主要是为了供客户端获取注册信息时使用，其缓存更新，依赖于定时器的更新，通过和 readWriteCacheMap 的值做对比，如果数据不一致，则以 readWriteCacheMap 的数据为准。
private final ConcurrentMap<Key, Value> readOnlyCacheMap = new ConcurrentHashMap<Key, Value>(); -
二级缓存：是 guava 的缓存，包含失效机制，保存服务信息的对外输出的数据结构。
readWriteCacheMap：readWriteCacheMap 的数据主要同步于存储层。当获取缓存时判断缓存中是否没有数据，如果不存在此数据，则通过 CacheLoader 的 load 方法去加载，加载成功之后将数据放入缓存，同时返回数据。
readWriteCacheMap 缓存过期时间，默认为 180 秒，当服务下线、过期、注册、状态变更，都会来清除此缓存中的数据。
private final LoadingCache<Key, Value> readWriteCacheMap;
Eureka Client 获取全量或者增量的数据时，会先从一级缓存中获取；如果一级缓存中不存在，再从二级缓存中获取；如果二级缓存也不存在，这时候先将存储层的数据同步到缓存中，再从缓存中获取。
-
-
其他缓存设计
除过 Eureka Server 端存在缓存外，Eureka Client 也同样存在着缓存机制，Eureka Client 启动时会全量拉取服务列表，启动后每隔 30 秒从 Eureka Server 量获取服务列表信息，并保持在本地缓存中。
Eureka Client 增量拉取失败，或者增量拉取之后对比 hashcode 发现不一致，就会执行全量拉取，这样避免了网络某时段分片带来的问题，同样会更新到本地缓存。
同时对于服务调用，如果涉及到 ribbon 负载均衡，那么 ribbon 对于这个实例列表也有自己的缓存，这个缓存定时(默认30秒)从 Eureka Client 的缓存更新。
这么多的缓存机制可能就会造成一些问题，一个服务启动后可能最长需要 90s 才能被其它服务感知到：
1、首先，Eureka Server 维护每 30s 更新的响应缓存
2、Eureka Client 对已经获取到的注册信息也做了 30s 缓存
3、负载均衡组件 Ribbon 也有 30s 缓存
这三个缓存加起来，就有可能导致服务注册最长延迟 90s ，这个需要我们在特殊业务场景中注意其产生的影响。
总结
Eureka用来实现微服务中的服务注册和发现，分成server和client。Eureka server满足AP原则，去中心化，每个节点相互独立但需要同步数据。使用二级缓存提高效率。Eureka client与Eureka server通过定时器发送Rest请求不断同步，发送心跳实现最终的功能。
扫一扫
107
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
