代码之家  ›  专栏  ›  技术社区  ›  LppEdd

弹簧性能热再加载

  •  0
  • LppEdd  · 技术社区  · 7 年前

    在一个项目中,我有一个 org.apache.commons.configuration.PropertiesConfiguration 对象注册为bean,以提供应用程序周围的配置值,并具有热重新加载功能。

    示例:我定义了 DataSource 单身豆。然后我创建了一个 ReloadingDataSource 对象,它包装并委托给“real” 数据来源 ,并且每次配置文件更改时,它都能够以线程安全的方式重新创建它。

    我想为简单的属性值做一些类似的事情。
    我想创造一个简单的, Autowire 可将检索委托给Apache的对象 PropertiesConfiguration 豆类。

    使用方法应类似于:

    @Property("my.config.database")
    private Property<String> database;
    

    呼叫地点简单来说是:

    final String databaseValue = database.get()
    

    你会说,只要绕过 属性配置 对象。也许你是对的,但我想在此基础上提供另一个抽象,一个更简单易用的抽象。

    我知道这和 ProxyFactoryBean 可以为方法调用创建AOP代理。这是正确的道路,还是有更好的选择?也许是纯粹的春天?

    我不想使用SpringCloud或类似的依赖项。

    1 回复  |  直到 7 年前
        1
  •  0
  •   Derrops    7 年前

    SpringCloud将重新创建bean,因此请记住您提出的任何解决方案,如果您有另一个bean,它只读取一次这个值,例如,当它被启动时,它不会重新初始化自己,这就是SpringCloud配置所关心的问题。

    据我所知,AOP只在方法级别工作,因此您可以截获对 somebean.getFoo() . 但在 somebean ,无法代理对变量本身的调用: somebean.foo . 你必须重置 foo 每一次你 PropertiesConfiguration 改变了,再次记住,如果还有什么需要 你需要处理这个或者用弹簧云咬住子弹。

    在运行时为了避免重新部署而更改内容的开销应该仔细考虑。对于Netflix来说,这是有意义的,因为他们有成千上万的服务器。但对于较小的参与者,我看不到理由,这一决定增加了很多复杂性。测试的噩梦。

    • 您是在运行时测试更改配置,还是接受风险并假设其有效?
    • 在用户执行数据库事务时,是否测试从A->B更改?
    • 测试其他提升条件,其中 正在改变吗?

    有些事情需要考虑。