一. 前言
经历过组件多个版本的迭代后，应该会发现，随着工具的不断演进，能搜索到的配置方式可能大多数都过时了，那么如何根据自己的版本快速的找到配置方式呢？
有时候官方文档里面能给我们正确答案，或者网上正好有对应版本的资料，这些都不在本次的讨论范围内。
本次思考的就是，如何在缺失这些的情况下快速的进行配置。以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还是做技术调研，都涉及到这种配置不知道咋搞的场景。这些方式也是慢慢摸索出来的，也许也和经验多了有关，但是方法论多多少少还是有点用处的。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
