商城网站风格,钓鱼网站怎么做防护教程,wordpress修改登录框字体,官网网站页面设计文章目录 前言1.EnableEurekaServer2.初始化缓存3.jersey应用程序构建3.1注册jeseryFilter3.2构建JerseyApplication 4.处理注册请求5.registry#xff08;#xff09; 前言
前段时间遇到了一个业务问题就是k8s滚动发布Eureka微服务的过程中接口会有很多告警#xff0c;当时… 文章目录 前言1.EnableEurekaServer2.初始化缓存3.jersey应用程序构建3.1注册jeseryFilter3.2构建JerseyApplication 4.处理注册请求5.registry 前言
前段时间遇到了一个业务问题就是k8s滚动发布Eureka微服务的过程中接口会有很多告警当时想着应该是Ribbon没有同步到实时的Eureka缓存导致列表中存在下线服务于是通过Redis手动更新了Ribbon缓存详细实现可以见上篇文章通过Redis手动更新Ribbon缓存来解决Eureka微服务架构中服务下线感知的问题但是那样的方式存在一个弊端即更新缓存的操作并不是“服务下线“这一动作来驱动而是服务调用方发送请求才会触发虽然用AOP可以做到无入侵式不影响业务代码但却或多或少会影响业务接口耗时如果不能定位到准确的告警接口此举会“牵一发而动全身”。基于此我也想过替代方案比如Eureka-Server端存在两个监听器
EventListener
public void listen(EurekaInstanceCanceledEvent event){log.debug(event.getServerId()\tevent.getAppName()服务下线);
}
EventListener
public void listen(EurekaInstanceRegisteredEvent event){InstanceInfo instanceInfo event.getInstanceInfo();log.debug(instanceInfo.getId()\tinstanceInfo.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 在EurekaServerContextEureka-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的最后要去清除特定信息下的缓存这是为了确保在注册实例后缓存中的信息是最新的。由于注册实例可能导致缓存中的信息过时因此需要在注册后进行缓存的重置以便在下一次访问时能够获取最新的实例信息。
