从实际业务问题出发去分析Eureka-Server端源码

前言

前段时间遇到了一个业务问题就是k8s滚动发布Eureka微服务的过程中接口会有很多告警，当时想着应该是Ribbon没有同步到实时的Eureka缓存，导致列表中存在下线服务，于通过Redis手动更新了Ribbon缓存（详细实现可以见上篇文章：通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题）但是那样的方式存在一个弊端即更新缓存的操作并不是“服务下线“这一动作来驱动，而是服务调用方发送请求才会触发（虽然用AOP可以做到无入侵式，不影响业务代码，但却或多或少会影响业务接口耗时）如果不能定位到准确的告警接口，此举会“牵一发而动全身”。基于此我也想过替代方案，比如Eureka-Server端存在两个监听器：

@EventListener
public void listen(EurekaInstanceCanceledEvent event){
    log.debug(event.getServerId()+"\t"+event.getAppName()+"服务下线");
}
@EventListener
public void listen(EurekaInstanceRegisteredEvent event){
    InstanceInfo instanceInfo = event.getInstanceInfo();
    log.debug(instanceInfo.getId()+"\t"+instanceInfo.getAppName()+"进行注册");
}

可以实时监听Eureka-Client端的注册情况，通过这样一种"服务实时上下线"的事件来驱动，可以完全确保每一次服务上下线都会伴随Ribbon缓存的更新。这样对业务接口就没有了影响，但理想很丰满现实很骨感，在实际中更新的操作不能执行。
当然也引入了MQ让服务调用方模拟消费者，让服务被调用方模拟生产者来效仿监听器的效果去清理缓存同样也是失败了…

所以对于每一个服务Eureka到底采取的是什么样的方式来进行注册，分发，我想借今天这个机会来好好整理一下：

EurekaServer是Netflix开源的服务注册和发现组件，它可以管理和监控集群中各个微服务实例的状态，并提供服务注册、发现和负载均衡的功能。EurekaServer存储了所有可用服务的实例，并根据负载情况将请求转发到不同的实例。
同样地，分析源码前先从整体流程图入手（手图）：

1.@EnableEurekaServer

先从入口开始，由于受到了SpringCoud的整合，通过一个注解@EnableEurekaServer就将进程标志成为了服务注册和发现的组件：

关键点@Import(EurekaServerMarkerConfiguration.class)将该配置类纳入当前的配置中，使得Eureka服务器能够正常运行并提供相关的服务注册和发现功能，进入到EurekaServerMarkerConfiguration中：

发现在该类中存在一个象征性的Marker类并且被实例化作为Bean注册到了IOC容器中，这让我联想到了ArrayList之所以能够支持元素的随机访问也是因为实现了一个名为RandomAccess的接口，并且该接口下无声明无实现。可谓是有异曲同工之妙~

回归正题，注释中写到此Bean用于作为标记来加载一个自动配置类：EurekaServerAutoConfiguration，那为什么当加载该自动配置类之后就可以作为服务注册的中间件呢？在这过程中有着以下一系列动作：

2.初始化缓存

EurekaServerContext
在EurekaServerContext（Eureka-Server上下文）的实现类DefaultEurekaServerContext中存在一个initialize()方法用于进行服务端的初始化工作：

主要是初始化Eureka-Server各个节点间的一些基础信息，在这之中特别重要的是在init()方法中初始化了Eureka-server端的响应缓存：

可以看到的是为了在多线程环境下对于变量responseCache安全初始化，方法加上了synchronized来修饰，初始化的方法也比较直接，传入了配置信息与注册请求就完成了缓存初始化，在该类的有参构造中，做了以下动作：

对Eurek-Server开启debug,在Register（）方法入口打上断点，启动一个Eurek-Client服务，立即就触发了注册流程，也就是在Eureka-Server核心的一个类AbstractInstanceRegistry中，也是在这个类中一级缓存registry得到了初始化：

3.jersey应用程序构建

3.1注册jeseryFilter

当上线的微服务要进行注册，他会发送Http注册请求到注册中心中，“不是mvc胜似mvc”但还是存在一点点差异：
服务端的请求入口是基于Jersey（类似mvc的web层框架）的RestFul方式，当服务上线，会发送http注册请求到Eureka-Server中，该请求会被Eureka内部的控制层框架Jesery中的过滤器拦截（和SpringMVC非常相似）过滤所有的注册请求，过滤器的注册发生在自动加载配置类的过程中：

JeseryFilter拦截注册请求的行为：

3.2构建JerseyApplication

当对Eureka-Server中的EurekaServerAutoConfiguration类debug，在该方法中打上断点，他将Eureka服务器所需的资源构建Jersey应用程序对象

并将返回值作为参数传递到jerseyFilterRegistration（）中作为构建Jersey filter的必要条件

至此Filter构建完成
Eureka所进行的心跳连接，服务剔除，服务注册，自我保护都是通过发送http请求的形式，而这些都会被Jersey的过滤器所拦截随即分发到具体的处理类上（类似于Controller）只不过在Eureka中是被名为Resource的处理类来处理，有了他Eureka-Client发送的注册请求才会被分发处理

4.处理注册请求

注册请求被Jesery拦截，在ApplicationResource类中被处理，就像MVC中的Controller一样在这一层中主要是对Eureka-Client发来的请求做一些校验工作，最后调用实质的注册方法

其实这不重要，因为他最终还是去调用了Register（）换一个断点：

5.registry（）

紧接着就是注册流程registry（）开启，开始注册请求的服务实例信息：

为什么在register（）的最后要去清除特定信息下的缓存，这是为了确保在注册实例后，缓存中的信息是最新的。由于注册实例可能导致缓存中的信息过时，因此需要在注册后进行缓存的重置，以便在下一次访问时能够获取最新的实例信息。