vertx config - downgoon/hello-world GitHub Wiki

vertx config 设计理念

vertx config 关于软件设计中用到的配置文件，带来了非常好的理念：

  • 配置的表征是JSONObject的，不再是key=value结构。
  • 两个抽象：ConfigStore和ConfigRetriever
  • 1对多关系：1个ConfigRetriever可以有多个ConfigStore
  • 类型和格式交叉变化：file/http/git + properties/json

很长一段时间，我们认为的配置都是key-value结构。于是出现了这种间接表达层次的配置：

employee.num=2
employee.1.name=wangyi
employee.1.age=25
employee.2.name=xiaoer
employee.2.age=28

而vertx还原了真实，它认为配置是层次的，并且在Java空间用JSONObject来描述，同时JSONObject被vertx认定为一种内置的数据类型（就好比JDK的String一样），于是JSONObject被放在vertx.core这样的基础上。

vertx 观察到：我们平时的配置，有的是配置文件，有的是Redis，或者请求另一个系统的JSON接口，最近也出现了 yaml 格式。它做了一个抽象总结，抽象出ConfigStore和ConfigRetriever的概念，并彻底将两者解耦，编程时，人们只需要从ConfigRetriever中获取配置信息，至于ConfigRetriever从哪里获取的配置（File/Http/Git），哪种格式（Properties/yaml/XML），人们都不用关心了，程序员只需要在Java空间编程，按基础的JSONObject去处理。

这种解耦带来的好处非常多：

  • 轻松实现可以从多个源头读取配置：比如有个默认配置，外加一个覆盖配置，或者多个覆盖配置，只取决于ConfigStore的个数和Order顺序。
  • 轻松实现 源头类型和源头格式的组合。这非常类似 ORM领域的桥模式，两个独立变化的维度，可以交叉的组合。一个维度区分User表，还是Post表；另一个维度区分Mysql数据库，还是Oracle数据库；它们可以交叉变化。
  • 轻松复用在线编辑：比如git源头，直接可以在gitlab上编辑配置文件，而且带了版本管理功能。比起我们之前很多人在ZooKeeper上做配置中心，然后再写一个可视化界面去做配置编辑，还有版本管理，要强太多太多。

有了 vertx config，我们有时候可以更新下观念，比如从前我们访问另外一个系统的HTTP接口，并且是JSON数据，然后这个数据对我们就是一个不怎么更新的数据，我们完全可以把它当做一个配置源来处理，而且通过借助ConfigRetriever自然拥有了 本地缓存 + 定时刷新的功能。

vertx config 结构图

vertx_config.png

参考资料