背景
今年负责一个特别紧急的项目，从需求沟通到应用上线只有一个月的时间，四月中旬开始具体沟通项目需求并准备资源，五月中旬要完成第一次上线。这次不聊整个项目的开展过程，而是说一下通过一个月艰苦卓绝的奋斗，顺利完成了需求沟通、分析、设计、开发、测试、验收，上线前也准备了详尽的上线序列并一一清点了，但上线时应用启动时出现的一个异常的排查过程。
现象
测试环境验证通过后，将镜像推送给运维部署到生产环境，应用启动时报如下错误
[ERROR] [DbSessionContextPlugin.java:] 测试数据库连接失败(Test DB Connection Fail)[driver:oracle.jdbc.driver.OracleDriver,url:store:xxxx.store:xxxx,user:uuuuuu]
java.sql.SQLException: No suitable driver found for store:xxxx.store:xxxx
at java.sql.DriverManager.getConnection(DriverManager.java:689)
at java.sql.DriverManager.getConnection(DriverManager.java:247)
at com.sinolife.sf.framework.dbcontext.DbSessionContextPlugin.testConnectionValidate(DbSessionContextPlugin.java:427)
at com.sinolife.sf.framework.dbcontext.DbSessionContextPlugin.postProcessAfterInitialization(DbSessionContextPlugin.java:61)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:437)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1710)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:579)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:501)
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:317)
at org.springframework.beans.factory.support.AbstractBeanFactory$$Lambda$146/1684106402.getObject(Unknown Source)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:315)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
at org.springframework.beans.factory.config.DependencyDescriptor.resolveCandidate(DependencyDescriptor.java:251)
......
差异
测试环境与生产环境之间的差异主要有两个方面
- 数据库连接串的配置方式
测试环境的配置方式
jdbc.user=system
jdbc.password=oracle
jdbc.jdbcUrl=jdbc:oracle:thin:@ip:port:uid
生产环境的配置方式
jdbc.user=tmsopr
jdbc.jdbcUrl=store:xxxx.store:xxxx
生产的配置方式是将连接串及秘钥信息加密保存到指定路径下的xxxx.store文件，需要这些信息时再去store文件中读取，目的主要是指定路径权限和加密方式可以保证敏感信息的安全，防范攻击。
- 数据库版本差异
测试环境数据库是11G，而生产环境数据库是19c。公司其他应用使用的11G，11G官方支持周期到2018年就结束了，于是公司开始尝试使用oracle 19c的版本，而我们的应用有幸成为了第一个尝试者。
分析 - 数据库版本差异
根据异常日志信息java.sql.SQLException: No suitable driver found for第一反应是oracle升级了，但是ojdbc驱动没有升级，有可能是驱动版本老旧导致的问题。解决方法有两个：升级OJDBC驱动版本；回退oracle数据库版本。
-
升级OJDBC驱动版本
由于项目中间使用了两个个数据源，应用的数据库是19c的版本，而另一个数据源数据库的版本是11c，如果升级OJDBC驱动的版本，有可能会影响另一个数据源。另外，MAVEN中对OJDBC的依赖较多，调整影响面大，而且需要架构组支持，有可能会出现反复调整并测试验证的情况。为了尽快解决问题让应用部署上线，放弃升级OJDBC驱动的方案。
ojdbc的依赖关系 - 回退oracle数据库版本
选定了方案之后，第一时间与运维沟通好后，运维开始协助回退oracle数据库的版本。运维一阵犀利的操作过后（导出、删除19c、创建11g、导入），数据库回退成11c的版本。
满怀希望的通知部署人员重新部署应用，然而令人绝望的是，依然是原来的错误，一模一样。
说明： 此处优先选择这个方案另一个重要的原因是测试环境oracle是11g，应用可以正常启动，至于为什么测试和生产不一致，后面会提及。
分析 - 数据库连接串的配置方式
数据库回退没解决掉问题，只能将矛头指向数据库连接串的配置方式上了。将生成环境的连接串配置方式调整为和测试环境一致，jdbc.jdbcUrl和jdbc.password直接在配置文件中写死。调整后重新打包镜像并推送运维部署。
应用居然成功启动了！
开始怀疑是不是store文件的格式和解析是否有问题？但是这个是通用的模块，已经使用很多年了。为了消除疑惑，改回从store文件读取jdbc.jdbcUrl和jdbc.password配置，增加日志，重新部署启动还是和原来一样报错。检查输出日志，参数都正常解析并获取到了。那究竟为什么在properties文件中配置就可以，而在store文件中配置就报错了呢？
数据源的配置很常规，很简单，如下：
@Bean(name = "dataSource")
@Primary
@ConfigurationProperties(prefix = "jdbc")
public DataSource dataSource() throws PropertyVetoException {
ComboPooledDataSource dataSource = DataSourceBuilder.create().type(ComboPooledDataSource.class).build();
String jdbcUrl = context.getEnvironment().getProperty("jdbc.jdbcUrl");
String user = context.getEnvironment().getProperty("jdbc.user");
String driverClass = context.getEnvironment().getProperty("jdbc.driverClass");
......
// 从store文件中解析并读取jdbcUrl和password
String[] jdbcUrlAndPassword = DbParamterResolverUtil.resolveJdbcUrlAndPassword(jdbcUrl, user, null);
dataSource.setDriverClass(driverClass);
dataSource.setJdbcUrl(jdbcUrlAndPassword[0]);
dataSource.setUser(user);
dataSource.setPassword(jdbcUrlAndPassword[1]);
......
return dataSource;
}
通过再次仔细分析异常日志，将焦点放在了@ConfigurationProperties(prefix = "jdbc")这个注解上，
......// 原理待完善
将@ConfigurationProperties(prefix = "jdbc")注解去掉，重新部署，一切正常。
思考
- 知其然，知其所以然
作为一个程序员不求甚解是要不得的，应该在熟练使用工具的同时，多了解其背景和原理，这样才不会滥用，遇到问题才能快速准确的定位。
As a programmer, I hate to use things I don’t understand.
- 沟通
应该积极主动的沟通，不应该回避沟通，避免出现信息孤岛。
其实运维的同事在开发环境部署了一套19c，但是并没有通知我们。由于项目周期短，时间太紧张了，开发人员直接在测试环境开发，已期望提高部署和用户验证的效率。从而导致了很多不必要的操作。 - 规范
我们有开发、测试、生产三个环境，考虑到项目时间紧张，期望最大化提高效率，只维护了测试环境，直接忽略了开发环境。这样不规范的操作导致了一系列的问题，环境问题，配置问题，开发频繁部署，导致用户测试体验极差等等。
开发、测试、生产环境应该保持一致，都应该部署19c的数据库，但是不知道什么原因运维再开发部署了19c、测试部署了11g、生产部署了19c。环境不一致增加了问题分析的很多不必要的复杂度。
引入更新或一项新技术的时候，应该先做好充足的知识储备和测试环境验证（最好由架构组先尝试、总结、然后培训推广），而不是盲目的尝试，评估的时候应该更谨慎。
