Go语言分布式系统配置管理实践--go archaius

获取配置

---

获取配置有2种不同的手段：

1. 调用archaius API的Get 方法

2. 注册监听器

事件的触发是由soruce的开发者来决定的，每个source的行为会有不同：

命令行与环境变量是不会产生任何事件的，当archaius运行后配置项就已经定下来了，只能使用Get方法获取。而文件source会在启动后拉取一遍本地文件内容并转换为配置项（可自定义转换算法，决定配置项形态），之后持续监听本地文件变化，当有变化发生时会刷新本地配置并通知到监听器。所以2种方法都支持。config center source行为与文件又不同，在启动后，它就会周期拉取配置中心的配置，并且对比每一次配置项的不同，并触发不同类型事件。

配置项形态

---

假设程序有一个配置文件叫a.yaml，内容如下

registry:
  enabled: true
  interval: 30s复制代码

要考虑该如何去对待这raw data，目前有2种方式

第一种，将配置项拆分为java properties风格的配置：

registry.refresh: true

registry.interval: 30s

go archaius开放了file handler接口，允许你决定如何将文件内容处理为配置项

那么在远程的配置中心中，key value的管理方式就要遵循 file handler的行为，当你想变更registry.refresh时，就要在配置中心种更改这个配置项及值。

类似于开关类的配置项，这种java properties的管理方式还是不错的，当一个配置项改变时触发一次事件。

但是有一类配置项并不适合如此管理，这就是第二种方式，比如go chassis中的路由管理配置文件：

通常都需要大范围的更改配置项，那么如果还使用切分的方式在配置中心中管理将会引起go archaius运行时大量的事件触发，并且，用户在使用体验上大打折扣，到处去找分散的配置项，逐一更改。正确的行为是，将文件名作为配置中心中的key，文件内容作为value。用户需要更改时，去找对应的文件名即可，修改后一次性下发，只会触发一次事件，完成路由的变更。

开发者应根据实际场景判断如何处理配置项形态。也可以自己实现handler来决定配置项形态

配置运行时热加载

---

在运行时可以随时通过统一的配置中心或者本地文件（不推荐分布式环境登到机器里改文件，但在本地debug时还是推荐使用文件来测试程序的热加载逻辑）更改配置了，那么接下来要解决的问题就是配置在运行时生效。

这里的技巧是使用go语言中的读写锁。我以go chassis中路由配置来说明

go chassis运行时总是会有不断地大并发数据访问router config这块缓存，使用一个读写锁lock中的读锁，每次访问缓存都用读锁，使用后，解开读锁。

向archaius注册监听器，需要自己编写监听器的逻辑，每当事件出发后就会通过archaius中的数据构建一个结构体数据，然后将数据存到本地缓存，首先使用lock的写锁锁住router config，更新后，解开写锁。

在这样的机制下，就可以做到运行时热加载配置项而无需重启服务。