1.简介
EureKa在Spring Cloud全家桶中担任着服务的注册与发现的落地实现。Netflix在设计EureKa时遵循着AP原则，它基于R
EST的服务，用于定位服务，以实现云端中间层服务发现和故障转移，功能类似于Dubbo的注册中心Zookeeper。
2.实现原理
EureKa采用C-S的设计架构，即包括了Eureka Server（服务端），EureKa client（客户端）。
1.EureKa Server 提供服务注册，各个节点启动后，在EureKa server中进行注册；
2 EureKa Client 是一个Java客户端，用于和服务端进行交互，同时客户端也是一个内置的默认使用轮询负载均衡算法的负载均衡器。在应用启动后，会向Eueka Server发送心跳（默认30秒）。如果EUR额卡 Server在多个心跳周期内没有接受到某个节点的心跳，EureKa Server将会从服务注册表中将这个服务移出（默认90秒）。
一 Eureka基本规则
- 服务启动时会生成服务的基本信息对象InstanceInfo，然后在启动时会register到服务治理中心。
- 注册完成后会从服务治理中心拉取所有的服务信息，缓存在本地。
- 之后服务会被30s(可配置)发送一个心跳信息，续约服务。
- 如果服务治理中心在90s内没有收到一个服务的续约，就会认为服务已经挂了，会把服务注册信息删掉。
- 服务停止前，服务会主动发送一个停止请求，服务治理中心会删除这个服务的信息。
- 如果Eureka Server收到的心跳包不足正常值的85%（可配置）就会进入自我保护模式，在这种模式下，Eureka Server不会删除任何服务信息。
有两个比较重要的配置
服务过期时间配置：eureka.instance.lease-expiration-duration-in-seconds
服务刷新时间配置：eureka.instance.lease-renewal-interval-in-seconds
二 Eureka服务注册中心的缓存
Eureka注册中心有一个Map来保存所有的服务及映射的机器信息：
private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry
= new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();
- 服务注册时，会把服务的信息写到这个registry中
- 服务从治理中心拉取服务列表信息时，不会从这个registry中拉取，而是从一个ResponseCache中拉取，这样读写分离的原因应该是为了支持高并发。
而ResponseCache又分为了两个部分，一个是ReadWriteMap，一个是ReadOnlyMap。
- ReadWriteMap的数据是从registry中来的，可以认为是registry的缓存，当服务注册时，除了把信息写到registry中外，还会让ReadWriteMap主动过期，使得会去从registry重新拉取数据。
- ReadOnlyMap的数据是从ReadWriteMap来的，可以认为是ReadWriteMap的缓存（所以它是registry缓存的缓存，双层缓存了），当服务需要获取服务列表是，会直接取这个ReadOnlyMap的数据，当这个数据不存在时，才会从ReadWriteMap中更新。
- ReadWriteMap与registry的数据是实时一致的（因为有注册后让ReadWriteMap失效的机制），但是ReadWriteMap与ReadOnlyMap不是实时一致的。
- 有定时任务会定时从ReadWriteMap同步到ReadOnlyMap，这个时间配置是：eureka.server.responseCacheUpdateInvervalMs
- EurekaServer内部有定时任务，每隔检查过期实例时间，扫描Registry里面过期的实例并删除，并且使对应的ReadWriteMap缓存失效，这个时间是eureka.server.eviction-interval-timer-in-ms
三 服务注册的细节
3.1 客户端做了什么事？
服务在启动完成后，会启动一个线程，去执行注册信息，具体代码在InstanceInfoReplicator中，这个类实现了Runnable:
public void run() {
try {
discoveryClient.refreshInstanceInfo();
Long dirtyTimestamp = instanceInfo.isDirtyWithTime();
if (dirtyTimestamp != null) {
discoveryClient.register();
instanceInfo.unsetIsDirty(dirtyTimestamp);
}
} catch (Throwable t) {
logger.warn("There was a problem with the instance info replicator", t);
} finally {
Future next = scheduler.schedule(this, replicationIntervalSeconds, TimeUnit.SECONDS);
scheduledPeriodicRef.set(next);
}
}
- 在run方法中，会先去检测服务信息是否发生了变更，如果发生了，会调用 discoveryClient.register();方法重新注册，第一次的时候也会认为是发生了变更，从而发起第一次注册。
- 在finally块中，schedule了this，说明会在指定时间后再次执行这个方法。
3.2 服务端做了什么事？
- 首先会处理上面第二节所说的registry以及它的缓存对象。
- 其次会把这次的注册信息添加到一个“最近变更队列中”
private ConcurrentLinkedQueue<RecentlyChangedItem> recentlyChangedQueue =
new ConcurrentLinkedQueue<RecentlyChangedItem>();
之所以要维护一个这样的队列，是为了方便服务增量更新服务列表的信息。
- 然后会把注册的信息发送到其他的Eureka节点，发送的方式就是调用其他节点的register方法。
四 服务续约的细节
在服务启动时，会创建一个后台心跳任务，定时去续约服务信息：
scheduler.schedule(
new TimedSupervisorTask(
"heartbeat",
scheduler,
heartbeatExecutor,
renewalIntervalInSecs,
TimeUnit.SECONDS,
expBackOffBound,
new HeartbeatThread()
),
renewalIntervalInSecs, TimeUnit.SECONDS);
HeartbeatThread就是心跳线程，这里把它包装成了一个TimedSupervisorTask，
注意：scheduler.schedule方法只会在延时一定时间后执行一次提交的任务，所以这里会延时执行，同时，虽然schedule只会执行一次，但是TimedSupervisorTask里封装了循环调用的信息，所以其实是定时调用了。
而HeartbeatThread非常简单：
private class HeartbeatThread implements Runnable {
public void run() {
if (renew()) {
lastSuccessfulHeartbeatTimestamp = System.currentTimeMillis();
}
}
}
- if语句中的renew()方法就是服务续约的方法，里面的逻辑就是向服务治理中心发送了一个http请求。
- 如果http请求返回的状态码是404，则会认为这个服务没有注册或者注册了但是已经失效，因此会直接调用register()方法进行注册。
五 服务取消的细节
服务停止前会向服务治理中心发一个服务取消的请求，用于注销服务。收到服务注销的请求之后，服务治理中心会做以下操作：
- 从registry中删除对应的服务信息
- 使ReadWriteMap缓存失效
- 将服务取消的信息加入到最近变更队列中
原文地址：https://www.cnblogs.com/bolang100/p/11819230.html