「造个轮子」——cicada 设计一个配置模块

  • 时间:
  • 浏览:1
  • 来源:5分3D官方_极速5分排列5

这就说 本次 v1.0.2 中的升级内容,暗含了配置支持以及代码重构。其中许多内容我随便说说对接触少的同学来说还是挺有帮助的。

查询出来日后 自然是要进行遍历同时反射创建对象。

还要额外提许多的是:在查找所有用户自定义的配置管理类时还要手动将 cicada内置的 ApplicationConfiguration 加入其中。

原本使用起来就完整不还要管那此参数传递了。

来赋值配置文件名称,就说 还还要在遍历过程中将 Properties 进行赋值。

public class KafkaConfiguration extends AbstractCicadaConfiguration {

我这里的时间在查询一次日后 就不必了,就说 完整放心的在 getLocalTime() 方式中删掉。

}



ThreadLocalHolder.setLocalTime(System.currentTimeMillis());

同时在这里也体现出优先读取的是 VM 启动参数中的配置文件。

提供简易的接口使用。

定义比较简单,其中另另四个重要的成员变量:

       super.setPropertiesName("kafka.properties");



为了方便用户在使用日后 还要随意的读取各个配置文件,就说 还还要将反射创建的对象保存到另另四个内部管理缓存中,核心代码就说 上上图中的这段代码:

在看实现日后 先看看基于目前的配置管理怎样才能在业务中使用起来。

首先还要通过 ConfigurationHolder 获取人及 不同配置的管理对象(还要显式指定类类型)。

使用也比较简单,只还要继承 cicada 提供的另另四个抽象类即可。

同时将 cicada 升级到了 v1.0.2

按照原本的配置也会默认从 classpath 读取这另另四个配置文件。

这里还是有许多还要注意,在這個 长生命周期的容器中一定得要记得及时清除

在初始化的方式中我将当前时间写入:

同时也新增了另另四个 api。

这也简单,代码一看就懂:

同时 ThreadLocalHolder 的定义:

朋友 将会查看日志语句会发现应用启动日后 会打印本次的耗时,自然就说 在 启动日后 记录另另四个时间,初始化完毕日后 记录另另四个即可。



本次升级同时还重构了次责代码,比如启动类。

public class MainStart {

ConfigurationHolder.addConfiguration(aClass.getName(), conf);

当然这里有个前提:代码里配置的文件名还要得和配置文件名称相同。

   }

那怎样才能在业务中读取这另另四个配置文件的内容呢?

同时也支持获取 application.properties 里的配置。

-Dkafka.properties=/xx/kakfa.properties

就说 我按照另一方的想法创建了另另四个 issue ,也下发到了许多很不错的建议。







   public static void main(String[] args) throws Exception {

}

   public RedisConfiguration() {

在做日后 是要把需求想好,到底怎样才能的另另四个配置管理是对开发人员来说比较友好的?

那未免太不优雅了。

我认为有以下几点:

   public static void main(String[] args) throws Exception {

原本在不传默认地址的日后 cicada 会从 application.properties 中读取。

随便说说也是利用另另四个 Map 来存放那此对象。



// add configuration cache

理论上来说配置這個 东西应当完整独立出来,由另另四个配置中心来负责管理就说 原本还要与应用解耦。

文件名称:用于初始化时通过名称加载配置文件。

   }

结合现在朋友 使用 SpringBoot 的习惯, cicada 默认会读取 classpath 下的 application.properties 配置文件。就说 必默认读取其中的应用端口以及初始路由地址。

将会使用应用的包名通过反射是查询不在 该类的。

   public KafkaConfiguration() {

在最后记录日志的地方直接取出比较即可:

将会日后 将会调用了

public class RedisConfiguration extends AbstractCicadaConfiguration {

}

要实现以上的功能有多少核心点:

public class MainStart {

super.setPropertiesName("redis.properties");

通过 get() 方式直接获取配置。

-Dredis.properties=/xx/redis.properties

Properties 随便说说就说 另另四个 Map 价值形式的缓存,用于存放所有的配置。当然对外提供的查询是基于它的。

还要自定义配置,就说 支持不同的环境(开发、测试、生产)。

       super.setPropertiesName("redis.properties");

String brokerList = configuration.get("kafka.broker.list");

使用灵活。对使用者来说暂且有太大的束缚。

KafkaConfiguration configuration = (KafkaConfiguration) getConfiguration(KafkaConfiguration.class);

       CicadaServer.start(MainStart.class,"/cicada-example") ;

同时为了支持在不同环境的使用,当配置了启动参数将会优先读取。

加载所有配置文件。

原本在使用日后 只还要取出即可。

其中 ConfigurationHolder 的定义如下。



考虑到中间可维护的情况汇报, cicada 也支持配置各种不同的配置文件。

在前两次的 cicada 版本中随便说说还不支持读取配置文件,比如对端口、路由的配置。

就说 ThreadLocal 都有了发挥余地。

原本是是否是基本实现了上述的配置要求。

但现在优化日后 跨越了不同的方式和类,难道要把时间作为参数在各个方式日后 传递嘛?

接着就说 在 初始化时还要找出所有继承了 AbstractCicadaConfiguration 的类。

最终随便说说还是按照我日后 的想法来做了這個 配置管理。

现在看上去要清爽和直接的多:

   }

在日后 的实现中将会都有在另另四个方式内,就说 直接使用就行了。

其中都有许多还要注意的地方。

-Dapplication.properties=/xx/application.properties

   }

}

就说 基于原本的情况汇报便有了以下的实现。

将会 cicada 还要支持多个配置文件,所有还要定义另另四个抽象类供所有的配置管理实现。

不过原本的实现和当前 cicada 的定义许多冲突,我还要尽量小的依赖第三方组件并还要完整独立运行。

将不同的配置文件用不同的对象进行管理。

       CicadaServer.start(MainStart.class) ;