阅读本篇文章之前，请先阅读分布式链路追踪系列四（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容器的加载就分为两个阶段
- 通过从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...）
