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

关注

发布于: 2021 年 01 月 06 日

【摘要】 https://github.com/go-chassis/微服务开发框架是一个微服务开发框架，而微服务开发框架带来的其中一个课题就是：当单体应用向微服务转型后，有大量的配置需要管理，而你并不希望登录到远端机器去更改配置，并重启应用，尤其是现在已经是容器的时代了，也不希望因为一个配置的变更，而发布一个新的软件包。那么分布式系统中每个进程的动态配置管理及运行时热加载就成为了一个亟待解决的问题。

引言

https://github.com/go-chassis/微服务开发框架是一个微服务开发框架，而微服务开发框架带来的其中一个课题就是：当单体应用向微服务转型后，有大量的配置需要管理，而你并不希望登录到远端机器去更改配置，并重启应用，尤其是现在已经是容器的时代了，也不希望因为一个配置的变更，而发布一个新的软件包。那么分布式系统中每个进程的动态配置管理及运行时热加载就成为了一个亟待解决的问题。https://github.com/go-chassis/go-archaius为 go chassis 而生，他汲取了 netflix 的 archaius 框架经验，并做出来自己的创新特性。

架构

Source: 配置源是一种标准接口，可以通过实现一个 source 来接入不同配置源，它定义配置来自哪个资源，配置可以来自配置中心 configcenter，来自本地文件，来自环境变量或是启动命令行。source 负责将配置项缓存到本地内存。用户可以选择加载任意的 source 实现。

Config center source： 配置中心源不同于其他 source，它包含一个 client 抽象，可以对接不同的生态系统，目前对接了携程开源的配置中心 Apollo。

**Config manager：负责整合管理所有 source 的配置，每个 source 可以定义优先级，**当通过 manager 获取配置时，如果 2 个不同的 source 有相同的配置，那么就会取最大优先级的配置。

**Event Dispatcher：**用户可以通过 Archaius API 进行配置变化监听，当 source 内部的配置项新增，更新，删除配置时，都会通知到监听器。

**Source 优先级：**优先级由大到小依次为 Config center，CLI，ENV，file，当有相同配置项的时候仅优先级大的配置生效。在一个分布式系统中，远程的配置中心理应拥有最大优先级，而在本地运行一个独立的进程时，通常的思维是，命令行参数优先级高于环境变量，高于本地文件内容。拥有了这样一套机制后，用户就无需再写代码处理配置项生效逻辑。

Config Factory： 封装了 event 和 config manager 的 API

Archaius API： 封装底层实现，提供友好的 API 供开发者使用

获取配置

获取配置有 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 来决定配置项形态