一. 前言

　　经历过组件多个版本的迭代后，应该会发现，随着工具的不断演进，能搜索到的配置方式可能大多数都过时了，那么如何根据自己的版本快速的找到配置方式呢？

　　有时候官方文档里面能给我们正确答案，或者网上正好有对应版本的资料，这些都不在本次的讨论范围内。

　　本次思考的就是，如何在缺失这些的情况下快速的进行配置。以MongoDB 来学习一下 。

　　二. 解决方式

　　2.1  方法一 ： 入口类 向下查找

　　首先 ，作为工具类的软件，底层可能会有变动，但是对外的接口通常是不会有大的变化的。

　　// 在高版本里面  MongoDbFactory 已经过时了 >> 
　　@Bean
　　public MongoTemplate mongoTemplate(MongoDbFactory mongoDbFactory, MappingMongoConverter converter) {
　　    MongoTemplate mongoTemplate = new MongoTemplate(mongoDbFactory, converter);
　　    mongoTemplate.setReadPreference(ReadPreference.secondaryPreferred());
　　    return mongoTemplate;
　　}

　　以上是一个 MongoDB 入口类的配置， MongoDB 只要不发生大的迭代，MongoTemplate 这个入口类是不会有太大的变化。

　　但是抄过来后，会马上发现 MongoDbFactory 过时了，这里说明我们已经找到关键点了 ：我们需要一个新的 Factory。

　　点开 MongoTemplate 就知道需要一个 MongoDatabaseFactory ， 通过实现类就能快速找到我们应该创建哪个类了 ：

　　xxxBuilder ： 好东西 ， 通常都是官方提供的配置类，用于帮助创建实例，例如 RestTemplateBuilder，就可以快速创建 RestTemplate。

　　xxxFactory : Client的创建类 ，也是比较核心的创建类。

　　xxxSupport ： 这种通常是最后的支持类，一般都是实际的业务，这种类可配置的点就很局限。

　　xxxClient ：通常基于这个调用远程组件，一般配置这个Bean就能实现对应的远程调用了。

　　xxxConverter ： 最常见的就是做数据映射，把DTO的数据转换成组件需要的数据格式。

　　Simplexxx : 这个前缀是个很明显提示，说明基础的功能用它就没错了。

　　然后再往上找一找，就很容易找到对应 MongoClientSettings 类 ，里面神奇的发现了一个 Builder ：

　　MongoClientSettings.Builder builder = MongoClientSettings.builder();
　　// 设置服务器地址
　　builder.applyToClusterSettings(clusterSettingsBuilder ->
　　        clusterSettingsBuilder.hosts(Arrays.asList(new ServerAddress(localhost, port))));
　　// .... 省略
　　 MongoClientSettings settings = builder.build();
　　// 创建MongoClient客户端 , 最后创建一个 Factory
　　MongoClient client = MongoClients.create(settings);
　　return new SimpleMongoClientDatabaseFactory(client, database);

　　2.2  方法二 ： 反馈式-针对提供了配置项,但是缺少或者不知道配置的场景

　　这种方案在我配置 Sharding 的时候效果非常好，最直接的表现就是，每次启动缺少配置时，都会有相关的反馈。

　　org.apache.shardingsphere.infra.exception.ShardingSphereException: Can not route tables for `[t_blog]`, please make sure the tables are in same schema.
　　    at org.apache.shardingsphere.sharding.route.engine.type.unconfigured.ShardingUnconfiguredTablesRoutingEngine.route

　　首先，进代码去找原因 ，这里不难发现第一个线索，没有 tableRule ，导致表名没有正确的分表。

　　正常情况下，我们不应该进到第三步里面，那么就网上找，为什么我的 rule 不存在。

　　流程不复杂，通过6步就快速找到了配置类，后续按照配置类进行配置即可，熟练情况下，可能十几分钟就能解决一个配置问题。

　　2.3 方法三 ： 由下到上 - 针对 Client 对应不上，有微小版本差异的情况

　　这种方式和上面的类似，也是找到对应的下层入口，可能这里会有一些模糊，怎么知道下层入口？

　　除了报错的反馈式，最好的方式就是直接看最终的源码包，以 ES 为例 ：

　　第一步 : 找 Jar 包 ，如果是需要调用外部组件的 ，直接看对应的 Client。

　　但是一般的Client都会做脱Spring处理，这里的东西是没办法直接注入的

　　第二步 : 找到对应的 Spring 包。

　　这里可能会有疑惑,我都找到了 Spring 包，为什么还要找底层，我先走第二步，再往下不就完事了吗？

　　以 ES 进行举例就是因为 ES 的变动太频繁了，我们可能只能从ES官方找到对应的 Client 版本，但是不太好去找这个 Client 应该对应哪个 Spring 版本。

　　第三步 ：参考 Configuration 仿写。

　　这个有一定难度，主要在于串通流程。

　　这个方法一般只针对具有微小版本差导致跑不起来的情况。

　　2.4 方案四 ： 弯道超车，直接搜索 AutoConfiguration 类

　　一般常用的配置在Spring AutoConfiguration 包中都会有定义，我们可以尝试从这个包中直接进行配置 ，但是这种方案的前提是你的 Configuration 能和对应组件匹配正确。

　　当然，通常Spring在写这些配置类的时候，也是基于接口进行的开发，从某种形式上说也是为了避免这类版本偏差大的问题。

　　但是你碰到 Elastic 这种小版本 = 大变动的组件，那就没办法了。

　　总结

　　东西不多，主要是思考和总结。

　　感觉没有把那种想法描述清楚 ，还是得靠意会。

　　这些年不过是自己写Demo还是做技术调研，都涉及到这种配置不知道咋搞的场景。这些方式也是慢慢摸索出来的，也许也和经验多了有关，但是方法论多多少少还是有点用处的。

作者：AntBlack    

来源：http://www.51testing.com/html/08/n-7796908.html