Spring Cloud Eureka源码剖析---效劳注册
2019-11-18杂谈搜奇网49°c
A+ A-本篇我们偏重剖析Eureka效劳端的逻辑完成，重要涉及到效劳的注册流程剖析。
在Eureka的效劳治理中，会涉及到下面一些观点：
效劳注册：Eureka Client会经由过程发送REST要求的体式格局向Eureka Server注册本身的效劳，供应本身的元数据，比方 IP 地点、端口、运行状况目标的URL、主页地点等信息。Eureka Server吸收到注册要求后，就会把这些元数据信息存储在一个ConcurrentHashMap中。
效劳续约：在效劳注册后，Eureka Client会庇护一个心跳来延续关照Eureka Server，申明效劳一向处于可用状况，防备被剔除。Eureka Client在默许的情况下会每隔30秒发送一次心跳来举行效劳续约。
效劳同步：Eureka Server之间会相互举行注册，构建Eureka Server集群，差别Eureka Server之间会举行效劳同步，用来保证效劳信息的一致性。
猎取效劳：效劳消耗者（Eureka Client）在启动的时刻，会发送一个REST要求给Eureka Server，猎取上面注册的效劳清单，而且缓存在Eureka Client当地，默许缓存30秒。同时，为了机能斟酌，Eureka Server也会庇护一份只读的效劳清单缓存，该缓存每隔30秒更新一次。
效劳挪用：效劳消耗者在猎取到效劳清单后，就可以依据清单中的效劳列表信息，查找到其他效劳的地点，从而举行长途挪用。Eureka有Region和Zone的观点，一个Region可以包括多个Zone，在举行效劳挪用时，优先接见处于同一个Zone中的效劳供应者。
效劳下线：当Eureka Client须要封闭或重启时，就不愿望在这个时间段内再有要求进来，所以，就须要提早先发送REST要求给Eureka Server，通知Eureka Server本身要下线了，Eureka Server在收到要求后，就会把该效劳状况置为下线（DOWN），并把该下线事宜流传出去。
效劳剔除：有时刻，效劳实例可以会由于收集故障等缘由致使不能供应效劳，而此时该实例也没有发送要求给Eureka Server来举行效劳下线，所以，还须要有效劳剔除的机制。Eureka Server在启动的时刻会建立一个定时使命，每隔一段时间（默许60秒），从当前效劳清单中把超时没有续约（默许90秒）的效劳剔除。
自我庇护：既然Eureka Server会定时剔除超时没有续约的效劳，那就有可以涌现一种场景，收集一段时间内发生了非常，一切的效劳都没可以举行续约，Eureka Server就把一切的效劳都剔除了，如许明显不太合理。所以，就有了自我庇护机制，当短时间内，统计续约失利的比例，假如到达肯定阈值，则会触发自我庇护的机制，在该机制下，Eureka Server不会剔除任何的微效劳，比及一般后，再退出自我庇护机制。
1. 基础原理：
- Eureka Server 供应效劳注册效劳，各个节点启动后，会在Eureka Server中举行注册，如许Eureka Server中的效劳注册表中将会存储一切可用效劳节点的信息，效劳节点的信息可以在界面中直观的看到；
- Eureka Client 是一个Java 客户端，用于简化与Eureka Server的交互，客户端同时也具有一个内置的、运用轮询负载算法的负载均衡器；
- 在运用启动后，将会向Eureka Server发送心跳(默许周期为30秒)，假如Eureka Server在多个心跳周期没有收到某个节点的心跳，Eureka Server 将会从效劳注册表中把这个效劳节点移除(默许90秒)；
- Eureka Server之间将会经由过程复制的体式格局完成数据的同步；
- Eureka Client具有缓存的机制，纵然一切的Eureka Server 都挂掉的话，客户端依旧可以应用缓存中的信息消耗别的效劳的API；
上一篇中我们搭建了一个简朴的Eureka客户端和效劳端。假如你有启动过寓目启动日记不难发明：
这里有个EurekaServerBootstrap类，启动日记中给出：Setting the eureka configuration..，Initialized server context。看起来这个应该是个启动类，跟进去看一下，有个很显眼的要领：
这个要领的挪用先按住不表，我们先从启动类上增加的 EnableEurekaServer注解动手，看看为何增加了一个注解就可以激活 Rureka。
从server启动类上的EnableEurekaServer注解进入：
接下来援用了
EurekaServerMarkerConfiguration，看到在这个注解上有个解释：启用这个注解的目标是为了激活：EurekaServerAutoConfiguration类；进入EurekaServerAutoConfiguration看到在类头部有一个注解：
@ConditionalOnBean(EurekaServerMarkerConfiguration.Marker.class)即
EurekaServerAutoConfiguration启动的前提是EurekaServerMarkerConfiguration注解先加载。
上面这一张图标识出了从启动注解到预启动类的流程，然则你会发明实际上 EurekaServerAutoConfiguration 也没有做什么事变：设置初始化，启动一些基础的过滤器。同样在类头部的援用上有一个Import注解：
@Import(EurekaServerInitializerConfiguration.class)所以在 EurekaServerAutoConfiguration 初始化的时刻，会援用到 EurekaServerInitializerConfiguration，激活它的初始化。EurekaServerInitializerConfiguration 完成了SmartLifecycle.start要领，在spring 初始化的时刻会被启动，激活 run 要领。可以看到在 run 要领中挪用的就是：
eurekaServerBootstrap.contextInitialized(EurekaServerInitializerConfiguration.this.servletContext);即我们上面截图中的EurekaServerBootstrap.contextInitialized()要领。
团体的挪用流程以下：
详细的初始化信息见下图：
2. 效劳注册完成
2.1 server端启动时同步别的server上的client
在上面讲到Eureka server启动过程当中，启动一个Eureka Client的时刻，initEurekaServerContext()内里会举行效劳同步和效劳剔除，syncUp()要领所属的类是：PeerAwareInstanceRegistry，即server端的效劳注册逻辑都在这内里。由于没有运用AWS的效劳器，所以默许实例化的完成类为：PeerAwareInstanceRegistryImpl。
PeerAwareInstanceRegistry registry;
if (isAws(applicationInfoManager.getInfo())) {
registry = new AwsInstanceRegistry(
eurekaServerConfig,
eurekaClient.getEurekaClientConfig(),
serverCodecs,
eurekaClient
);
awsBinder = new AwsBinderDelegate(eurekaServerConfig, eurekaClient.getEurekaClientConfig(), registry, applicationInfoManager);
awsBinder.start();
} else {
registry = new PeerAwareInstanceRegistryImpl(
eurekaServerConfig,
eurekaClient.getEurekaClientConfig(),
serverCodecs,
eurekaClient
);
}PeerAwareInstanceRegistryImpl 继承了一个抽象类 AbstractInstanceRegistry：
@Singleton
public class PeerAwareInstanceRegistryImpl extends AbstractInstanceRegistry implements PeerAwareInstanceRegistry {
}AbstractInstanceRegistry中的完成逻辑是真正的效劳注册存储所在地：
public abstract class AbstractInstanceRegistry implements InstanceRegistry {
private static final Logger logger = LoggerFactory.getLogger(AbstractInstanceRegistry.class);
private static final String[] EMPTY_STR_ARRAY = new String[0];
private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry
= new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();
protected Map<String, RemoteRegionRegistry> regionNameVSRemoteRegistry = new HashMap<String, RemoteRegionRegistry>();
protected final ConcurrentMap<String, InstanceStatus> overriddenInstanceStatusMap = CacheBuilder
.newBuilder().initialCapacity(500)
.expireAfterAccess(1, TimeUnit.HOURS)
.<String, InstanceStatus>build().asMap();
....
....
....
}一切的效劳实例信息都保留在 server 当地的map当中。所以在server端启动的时刻会去拉别的server上存储的client实例，然后存储到当地缓存。
2.2 client主动注册
假如是某个client主动发出了注册要求，那末是怎样注册到效劳端呢？
照样检察日记：启动效劳端，然后再启动客户端，检察效劳端日记：
这里能看到适才启动的客户端已经在效劳端注册了，注册逻辑走的类是：AbstractInstanceRegistry。
上面也提到 是效劳注册的逻辑完成类，完成保留客户端信息的要领是：
public void register(InstanceInfo registrant, int leaseDuration, boolean isReplication) {
......
}
代码就不贴了，重要完成的逻辑是保留当前注册的客户端信息。我们晓得客户端是发送了一次http要求给效劳端，那末真正的注册逻辑应该是从一个http要求的吸收处进来的。随着运用了register要领的处所去找，PeerAwareInstanceRegistryImpl内里有挪用：
@Override
public void register(final InstanceInfo info, final boolean isReplication) {
int leaseDuration = Lease.DEFAULT_DURATION_IN_SECS;
if (info.getLeaseInfo() != null && info.getLeaseInfo().getDurationInSecs() > 0) {
leaseDuration = info.getLeaseInfo().getDurationInSecs();
}
super.register(info, leaseDuration, isReplication);
//将新节点信息通知别的效劳端
replicateToPeers(Action.Register, info.getAppName(), info.getId(), info, null, isReplication);
}这里没有改写父类的register逻辑，下面还多了一句：replicateToPeers，这里重要做的逻辑是：给兄弟 server节点发送register 要求，通知他们有客户端来注册。
继承看谁挪用了这里,可以找到：ApplicationResource 的addInstance要领挪用了：
@POST
@Consumes({"application/json", "application/xml"})
public Response addInstance(InstanceInfo info,
@HeaderParam(PeerEurekaNode.HEADER_REPLICATION) String isReplication) {
......
registry.register(info, "true".equals(isReplication));
return Response.status(204).build(); // 204 to be backwards compatible
}而这里很明显是一个接口，逻辑就很清楚了：
别的，我们检察addInstance要领被谁挪用的过程当中发明：PeerReplicationResource--->batchReplication 要领也挪用了注册的逻辑。
这个要领一看居然解答了之前我的迷惑：效劳端之间是怎样发送心跳的。本来完成是在这里。经由过程dispatch要领来辨别当前的挪用是何种要求，
可以看到，效劳注册，心跳检测，效劳作废，效劳下线，效劳剔除的进口都在这里：
@Path("batch")
@POST
public Response batchReplication(ReplicationList replicationList) {
try {
ReplicationListResponse batchResponse = new ReplicationListResponse();
for (ReplicationInstance instanceInfo : replicationList.getReplicationList()) {
try {
batchResponse.addResponse(dispatch(instanceInfo));
} catch (Exception e) {
batchResponse.addResponse(new ReplicationInstanceResponse(Status.INTERNAL_SERVER_ERROR.getStatusCode(), null));
logger.error("{} request processing failed for batch item {}/{}",
instanceInfo.getAction(), instanceInfo.getAppName(), instanceInfo.getId(), e);
}
}
return Response.ok(batchResponse).build();
} catch (Throwable e) {
logger.error("Cannot execute batch Request", e);
return Response.status(Status.INTERNAL_SERVER_ERROR).build();
}
}
private ReplicationInstanceResponse dispatch(ReplicationInstance instanceInfo) {
ApplicationResource applicationResource = createApplicationResource(instanceInfo);
InstanceResource resource = createInstanceResource(instanceInfo, applicationResource);
String lastDirtyTimestamp = toString(instanceInfo.getLastDirtyTimestamp());
String overriddenStatus = toString(instanceInfo.getOverriddenStatus());
String instanceStatus = toString(instanceInfo.getStatus());
Builder singleResponseBuilder = new Builder();
switch (instanceInfo.getAction()) {
case Register:
singleResponseBuilder = handleRegister(instanceInfo, applicationResource);
break;
case Heartbeat:
singleResponseBuilder = handleHeartbeat(serverConfig, resource, lastDirtyTimestamp, overriddenStatus, instanceStatus);
break;
case Cancel:
singleResponseBuilder = handleCancel(resource);
break;
case StatusUpdate:
singleResponseBuilder = handleStatusUpdate(instanceInfo, resource);
break;
case DeleteStatusOverride:
singleResponseBuilder = handleDeleteStatusOverride(instanceInfo, resource);
break;
}
return singleResponseBuilder.build();
}从这个进口进去，人人可以跟踪一下感兴趣的逻辑。
