阅读本篇文章之前,请先阅读分布式链路追踪系列四(Opentracing实战)以及Spring扩展点总结,然后我们开始我们的历险
这到底是个什么问题
我们开发了一个全套的接入全链路的starter框架,供SpringBoot项目使用,上线初期都没什么问题,但是最近有一个项目在使用我们的框架后说Redis没有产生链路数据。
再具体一点,就是使用Spring Redis组件的链路数据都没有上报成功。那下面我们就来看一下我们是怎么做Spring Redis埋点链路数据的。
Spring Redis埋点浅析
直接上代码
public class RedisTracingBeanPostProcessor implements BeanPostProcessor {
private Tracer tracer;
private boolean withActiveSpanOnly;
public RedisTracingBeanPostProcessor(Tracer tracer,boolean withActiveSpanOnly) {
super();
this.tracer = tracer;
this.withActiveSpanOnly = withActiveSpanOnly;
}
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
if (this.canBeReplaced(bean)) {
RedisConnectionFactory origin = (RedisConnectionFactory) bean;
// 替换原生的Spring RedisConnectionFactory 为带有Tracing功能的ConnectionFactory
return new TracingRedisConnectionFactory(origin, withActiveSpanOnly, this.tracer);
}
return bean;
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
private boolean canBeReplaced(Object bean) {
return this.tracer != null && bean instanceof RedisConnectionFactory && !(bean instanceof TracingRedisConnectionFactory);
}
}
我们看到最为核心的逻辑就是自定义了Spring的后置处理器BeanPostProcessor来偷偷地替换Spring Redis产生的RedisConnectionFactory 为带有Tracing功能的RedisConnectionFactory 。
那么很自然地就想到,这个项目之所以没有上报Spring Redis的链路数据,就是因为这个BeanPostProcessor根本没有生效。
那么问题来了,为什么这个BeanPostProcessor根本没生效呢?
Spring加载流程浅析
要弄清楚为什么BeanPostProcessor没有生效,那么我们就必须对Spring整个的加载流程特别清楚才行。那么下面我们就要给Spring趴衣服了,嘿嘿!!!
由于整个Spring的框架的加载流程及其复杂,我只拿出我们这个问题有关的流程来说一说(只趴外衣,内裤不趴),其他的流程我们这里暂时先忽略。大家有兴趣了解Spring的可以直接去看一下源代码或者学习一下其他大神的源代码解析
下面,我们就来简单说一下Spring的大体流程,直接上图
Spring整体流程
从大体上看Spring容器的加载就分为两个阶段
- 通过从XML或者源代码的注解中扫描出所有的BeanDefinition(描述Bean的元数据)
- 根据扫描出的所有的BeanDefinition创建Bean
第一步的实现主要依赖BeanFactoryPostProcessor以及其子接口BeanDefinitionRegistryPostProcessor(Spring自己实现的或者用户自定义的)来实现的
第二部的实现主要依赖BeanPostProcessor以及其各种子接口,如InstantiationAwareBeanPostProcessor(Spring自己实现的或者用户自定义的)来实现的
正常情况下,都是按照这个节奏来走的,但是总是有不走寻常路的bean根本不按照套路出牌。如某些BeanPostProcessor。
由于我们自定义的BeanPostProcessor其实也是归Spring管理的,所以Spring在实例化我们的BeanPostProcessor之前,也会有一个BeanPostProcessor对应的BeanDefinition来描述我们自定义的BeanPostProcessor。而实例化普通Bean的时候需要BeanPostProcessor,所以正常情况下BeanPostProcessor实例化要早于普通的Bean,但是也有特殊情况,当我们自定义的BeanPostProcessor依赖普通Bean的时候,普通bean就会提前实例化。一旦Bean提前实例化,后面Spring就不对对Bean再次实例化,也就享受不到BeanPostProcessor的特殊处理。
下面我们来简单梳理一下这个过程:
1.首先我们得知道Spring中创建Bean需要两种原材料,一种就是BeanDefinition,一种就是BeanPostProcessor(当然也包含其子接口及其实现)
2.BeanPostProcessor及其子接口实现不是一开始就都是Spring中的Bean,它也一样需要经过Spring加载的两个阶段,先要转换为BeanDefinition,然后才能转变为Spring中的对象,然后才能服务于其他Bean的创建过程。
3.BeanPostProcessor转换为Spring中的Bean的时候有一个固定的顺序,具体如下:
具体的源代码这里我就不贴了,可以参考PostProcessorRegistrationDelegate类的registerBeanPostProcessors方法,顺便提一句BeanFactoryPostProcessor的处理也很类似。
4.所以如果有一个BeanPostProcessor中依赖普通的Bean,那么在调用BeanFactory的getBean的时候来生成BeanPostProcessor的时候,BeanPostProcessor依赖的普通的Bean也会在BeanPostProcessor生成之前被调用getBean方法生成Bean。那么Spring容器之后生产BeanPostProcessor的时候,就无法对已经生成的Bean产生任何作用了。
因此,得出结论
被PriorityOrderedBeanPostProcessor所依赖的Bean其初始化时无法享受到PriorityOrdered、Ordered、和nonOrdered的BeanPostProcessor的服务。而被OrderedBeanPostProcessor所依赖的Bean无法享受Ordered、和nonOrdered的BeanPostProcessor的服务。最后被nonOrderedBeanPostProcessor所依赖的Bean无法享受到nonOrderedBeanPostProcessor的服务。
失效原因分析
我们后来发现,Spring Redis失效的项目中都依赖了Shiro,然后Shiro中定义了一些BeanPostProcessor,并且该BeanPostProcessor简洁依赖了RedisConnectionFactory,那么就导致我们自己的BeanPostProcessor无法替换RedisConnectionFactory。
问题复现
由于shiro的环境稍微有点复杂,我们这里就模拟一下这种情况。
定义接口,模拟RedisConnectionFactory接口
public interface MyRedisConnectionFactory {
String getRedisConnection();
}
给一个默认实现,并且加上注解@Component,加入Spring容器
@Component
public class MyRedisConnectionFactoryImpl implements MyRedisConnectionFactory {
@Override
public String getRedisConnection() {
return "MyRedisConnection";
}
}
再 模拟一个带Tracing功能的RedisConnectionFactory,注意没有@Component注解
public class MyTracingRedisConnectionFactoryImpl implements MyRedisConnectionFactory {
private MyRedisConnectionFactory delegate;
public MyTracingRedisConnectionFactoryImpl(MyRedisConnectionFactory delegate){
this.delegate = delegate;
}
@Override
public String getRedisConnection() {
// 模拟tracing功能
return "tracing----------" + delegate.getRedisConnection();
}
}
然后定义一个替换RedisConnectionFactory的BeanPostProcessor,注意加上@Component注解
@Component
public class MyTracingBeanPostProcessor implements BeanPostProcessor {
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
if (bean instanceof MyRedisConnectionFactory && !(bean instanceof MyTracingRedisConnectionFactoryImpl)){
return new MyTracingRedisConnectionFactoryImpl((MyRedisConnectionFactory)bean);
}
return bean;
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
}
然后我们写一个测试类
@Configuration
// 注意这里修改为你们自己的包路径
@ComponentScan("com.example.demo")
public class DemoApplication {
public static void main(String[] args) {
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(DemoApplication.class);
MyRedisConnectionFactory bean = context.getBean(MyRedisConnectionFactory.class);
System.out.println(bean.getRedisConnection());
}
}
下面我我们测试一下,对象却是替换成了MyTracingRedisConnectionFactoryImpl对象
然后结果也变成了
tracing----------MyRedisConnection
这个时候一切都正常,下面我们来模拟shiro的情况,加上@Component注解
@Component
public class ShiroMockBeanPostProcessor implements BeanPostProcessor {
// 注意这里依赖了MyRedisConnectionFactory
@Autowired
private MyRedisConnectionFactory myRedisConnectionFactory;
@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
@Override
public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
return bean;
}
}
这个时候我们再运行一下,发现还是原来的MyRedisConnectionFactoryImpl,并没有替换为MyTracingRedisConnectionFactoryImpl对象。
运行结果
MyRedisConnection
至此,我们已经复现了shiro的场景,并且也已经复现了问题,也证实了我们上面的分析过程。
怎么解决呢
- 修改BeanPostProcessor的order顺序
- 不共享对象。即两个BeanPostProcessor依赖不同的对象。
- 懒加载。+@Lazy注解
相关阅读
BeanPostProcessor加载次序及其对Bean造成的影响分析
【小家Spring】注意BeanPostProcessor启动时对依赖Bean的“误伤”陷阱(is not eligible for getting processed by all...)
网友评论