摘要：分布式系统中每一个进程的动态配置管理及运行时热加载就成为了一个亟待解决的问题。go chassis汲取了netflix的archaius框架经验，并作出来本身的创新特性。
引言
https://github.com/go-chassis/go-chassis是一个微服务开发框架，而微服务开发框架带来的其中一个课题就是：当单体应用向微服务转型后，有大量的配置须要管理，而你并不但愿登陆到远端机器去更改配置，并重启应用，尤为是如今已是容器的时代了，也不但愿由于一个配置的变动，而发布一个新的软件包。那么分布式系统中每一个进程的动态配置管理及运行时热加载就成为了一个亟待解决的问题。https://github.com/go-chassis/go-archaius为go chassis而生，他汲取了netflix的archaius框架经验，并作出来本身的创新特性。java
架构
Source: 配置源是一种标准接口，能够经过实现一个source来接入不一样配置源，它定义配置来自哪一个资源，配置能够来自配置中心configcenter，来自本地文件，来自环境变量或是启动命令行。source负责将配置项缓存到本地内存。用户能够选择加载任意的source实现。git
Config center source： 配置中心源不一样于其余source，它包含一个client抽象，能够对接不一样的生态系统，目前对接了携程开源的配置中心Apollo。github
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来决定配置项形态
配置运行时热加载
在运行时能够随时经过统一的配置中心或者本地文件（不推荐分布式环境登到机器里改文件，但在本地debug时仍是推荐使用文件来测试程序的热加载逻辑）更改配置了，那么接下来要解决的问题就是配置在运行时生效。
这里的技巧是使用go语言中的读写锁。我以go chassis中路由配置来讲明
go chassis运行时老是会有不断地大并发数据访问router config这块缓存，使用一个读写锁lock中的读锁，每次访问缓存都用读锁，使用后，解开读锁。
向archaius注册监听器，须要本身编写监听器的逻辑，每当事件出发后就会经过archaius中的数据构建一个结构体数据，而后将数据存到本地缓存，首先使用lock的写锁锁住router config，更新后，解开写锁。
在这样的机制下，就能够作到运行时热加载配置项而无需重启服务。
例子
一个本地文件事件监控的例子
https://github.com/go-chassis/go-archaius/tree/master/examples/event
管理本地多文件的例子
https://github.com/go-chassis/go-archaius/tree/master/examples/file
Go chassis介绍
https://juejin.im/post/6844903682362834952
本文分享自华为云社区《Go语言分布式系统配置管理实践--go archaius》，原文做者：APTX-486977 。