前言
有些以前工作时写的博文,没有同步到博客过来。这一篇可能是1年多前写的,希望能给读者一些启示。
我们是多款游戏公用一个数据后台,通过不同的配置区分不同的游戏和环境。通过指定application.properties
的spring.profiles.active
来决定读取哪套配置。
例如我们需要发布到代号为sfish下的prd环境就选择spring.profiles.active=sfishlyprd
,同时我们的配置文件在resources/config下有
application-sfishlyprd.properites`。
该文件下用gameid来区分:
gameid=sfishlyprd
正文
原本的定时任务只有一个类,这个类里有很多方法,每个方法都隶属于某种项目。然后通过类似于以下的逻辑进行判断:
我做了第一步优化就是先把方法按项目进行分类,专有的类对应相应的项目。类似于:
这样做只是简单的按逻辑划分,对实际的运行并没有太大的影响,就是说即使当前是Sfish项目,lytj项目的定时任务也依旧在运行。
SpringBoot的定时任务会映射为一个操作系统的线程去跑,那么我们进行进一步的优化也是比较有必要的。
- 首先我们定义一个父类,让这些项目的计划类继承这个父类。
public class GameSchedule {
}
public class SfishSchedule extends GameSchedule{
}
- 注释掉这些项目计划类的
@Componet
让SpringBoot不去自动加载这些类。
- 编写配置类。逻辑就是读取当前项目的配置文件获取gameid,通过gameId去决定我们启用哪个子类。现在的定时任务都是针对某个项目的,后续如果有针对公共的可以直接在GameSchedule类中添加方法。
@Configuration
public class ScheduleConfig {
@Value("${gameid}")
private String gameid;
@Bean
public GameSchedule createSchedule(){
if (gameid.startsWith("sfish") || gameid.startsWith("zfsfish")) {
return new SfishSchedule();
} else if (gameid.startsWith("lytj")) {
return new LytjSchedule();
}
return new GameSchedule();
}
}
以后我们添加新方法的时候就不用再写gameid判断啦。
回看
现在看来上面的这段配置类的代码也是可以更进一步优化,但是前提是要统一各种gameid的命名,或者用新的属性来区分,例如解析了lytj就去找LytjSchedule
,sfish
就找SfishSchedule
,然后用反射去实例化相关的类。