前言
本文素材来源于业务部门技术负责人某次线上事变复盘分享。故事的背景是这样,该业务部门招了一个技术挺不错的小伙子小张,因为小张技术能力在该部门比较突出,在入职不久后,他便成为这个部门某个项目组的 team leader,同时也领有 review 该项目标权力。(注: 该我的项目为微服务项目),在某次小张 review 我的项目的时候,他发现好几个我的项目,发现代码有很多反复,于是他就动了把这些反复代码封装成 starter 的念头,而后也是因为这次的封装,带来一次线上事变。上面就以代码示例的模式,模仿这次事变
代码示例
注: 本文仅模仿呈现事变的代码片段,不波及业务
1、模仿小张的封装的 starter
@Slf4j
public class HelloSevice {
private ThreadPoolTaskExecutor threadPoolTaskExecutor;
public HelloSevice(ThreadPoolTaskExecutor threadPoolTaskExecutor){this.threadPoolTaskExecutor = threadPoolTaskExecutor;}
public String sayHello(String username){threadPoolTaskExecutor.execute(()->{log.info("hello: {}",username);
});
return "hello :" + username;
}
}
@Configuration
public class HelloServiceAutoConfiguration {
@Bean
public ThreadPoolTaskExecutor threadPoolTaskExecutor(){ThreadPoolTaskExecutor threadPoolTaskExecutor = new ThreadPoolTaskExecutor();
threadPoolTaskExecutor.setCorePoolSize(2);
threadPoolTaskExecutor.setMaxPoolSize(4);
threadPoolTaskExecutor.setQueueCapacity(1);
threadPoolTaskExecutor.setThreadFactory(new ThreadFactory() {private AtomicInteger atomicInteger = new AtomicInteger();
@Override
public Thread newThread(Runnable r) {Thread thread = new Thread(r);
thread.setName("hello-pool-" + atomicInteger.getAndIncrement());
return thread;
}
});
return threadPoolTaskExecutor;
}
@Bean
public HelloSevice helloSevice(ThreadPoolTaskExecutor threadPoolTaskExecutor){return new HelloSevice(threadPoolTaskExecutor);
}
}
spring.factories
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.github.lybgeek.thirdparty.autoconfigure.HelloServiceAutoConfiguration
2、模仿有援用小张封装的 starter 的微服务项目
因为这些微服务中有一些耗时的工作,因而应用了 spring 的异步。示例如下
@Configuration
public class ThreadPoolConfig {
@Bean
public ThreadPoolTaskExecutor threadPoolTaskExecutor(){ThreadPoolTaskExecutor threadPoolTaskExecutor = new ThreadPoolTaskExecutor();
threadPoolTaskExecutor.setCorePoolSize(2);
threadPoolTaskExecutor.setMaxPoolSize(5);
threadPoolTaskExecutor.setQueueCapacity(10);
threadPoolTaskExecutor.setThreadFactory(new ThreadFactory() {private AtomicInteger atomicInteger = new AtomicInteger();
@Override
public Thread newThread(Runnable r) {Thread thread = new Thread(r);
thread.setName("echo-pool-" + atomicInteger.getAndIncrement());
return thread;
}
});
threadPoolTaskExecutor.setRejectedExecutionHandler((r, executor) -> System.err.println("记录日志。。。。"));
return threadPoolTaskExecutor;
}
}
@Service
@Slf4j
public class EchoService {@Async("threadPoolTaskExecutor")
public void echo(String content){log.info("echo -> {}",content);
try {
// 模仿耗时操作
TimeUnit.MINUTES.sleep(2);
} catch (InterruptedException e) {e.printStackTrace();
}
}
}
3、和本文有关系的配置内容
spring:
main:
allow-bean-definition-overriding: true
4、模仿调用耗时业务代码块示例
@Component
public class BeanCommandRunner implements CommandLineRunner {
@Autowired
private EchoService echoService;
@Override
public void run(String... args) throws Exception {for (int i = 0; i < 6; i++) {echoService.echo("content:" + i);
}
}
}
相干的代码如上述内容
大家能够思考一下下面的示例有没有什么问题
咱们启动一下程序,察看一下控制台
报了一个线程池回绝异样,而且通过这个异样信息,咱们发现这个线程池走是小张封装线程池,而非业务本人定义的线程池。这显著是不失常的,失常的逻辑是业务代码优先级需比公共代码优先高才正当
那如何解决呢?
仅需利用 springboot 的条件注解即可,在小张封装的 starter 下做如下改变
@Bean
@ConditionalOnMissingBean
public ThreadPoolTaskExecutor threadPoolTaskExecutor(){ThreadPoolTaskExecutor threadPoolTaskExecutor = new ThreadPoolTaskExecutor();
threadPoolTaskExecutor.setCorePoolSize(2);
threadPoolTaskExecutor.setMaxPoolSize(4);
threadPoolTaskExecutor.setQueueCapacity(1);
threadPoolTaskExecutor.setThreadFactory(new ThreadFactory() {private AtomicInteger atomicInteger = new AtomicInteger();
@Override
public Thread newThread(Runnable r) {Thread thread = new Thread(r);
thread.setName("hello-pool-" + atomicInteger.getAndIncrement());
return thread;
}
});
return threadPoolTaskExecutor;
}
批改后,咱们在启动一下程序,察看控制台
此时走就是业务自定义的线程池了
为什么加了一个 @ConditionalOnMissingBean 就能够了
这就得从 springboot 的主动拆卸说起了,springboot 的主动拆卸类继承了 org.springframework.context.annotation.DeferredImportSelector,这个接口具备懒加载的性能,当我的项目启动后,先加载业务自定义的 bean,再来加载 starter 的 bean,当咱们我的项目中没有配置
spring:
main:
allow-bean-definition-overriding: true
时,我的项目启动就会间接报相似如下异样
过后他们业务我的项目因为他们 feign 没有指定 contextId,导致报了上述的异样,业务开发为了省事就间接把
allow-bean-definition-overriding 设置成 true,这也为后续小张自定义的 starter 引发的事变埋下了很好的根基。那咱们再切回主线,当 spring 发现有两个一样的 bean,且发现 allow-bean-definition-overriding 为 true,前面加载的 bean 会把后面加载的 bean 笼罩掉,这也是为啥小张 starter 的 bean 会失效。当咱们在 starter 上的 bean 上加载 @ConditionalOnMissingBean 后,因为业务我的项目的 bean 曾经存在了,starter 的 bean 就不会加载进 spring 容器了。
咱们从技术维度阐明了解决方案,咱们再从非技术的角度上复盘一下这次事变
复盘
不晓得会不会有敌人说,你说那么多,不就加一个 @ConditionalOnMissingBean 就能解决这个问题,下次留神就好了啊。但据业务技术人反馈过后他们排查了挺久,因为他们业务我的项目平时没啥并发量,所以小张那个问题就被掩盖住了,而有次他们业务搞了一个营销流动,因为并发下来了,才把问题裸露进去。这侧面也阐明我的项目压测的重要性,不能因为平时没啥并发,就漫不经心
不懂大家的公司是否也有这样的状况,在咱们这边,底下成员代码只能 merge request,只有 team leader review 后,再将代码合并到骨干,因为 team leader 领有的权限比拟大,他写的代码,只有他违心,间接就能合并到骨干了。这次也是因为小张间接将他写的代码推到骨干公布,酿成事变。前面咱们这边提出了一个办法,就是 team leader 的代码要由更高级的 leader 进行走查,然而这个办法我是感觉也不是很好,因为有不少项目组的 team leader 的老板基本上曾经脱离一线,不敲代码了,也不懂能不能行。
其次因为小张入职不久,对业务其实没有齐全吃透,因为看到反复的代码,出于技术洁癖,就想去改,出发点是好的,但有句话技术是为业务服务,业务都没搞懂,就去动,有时候会带来意想不到的危险
总结
对本人的不相熟的我的项目或者开发公共组件,三思而行再入手是很重要的