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

引言

https://github.com/go-chassis...，而微服务开发框架带来的其中一个课题就是：当单体利用向微服务转型后，有大量的配置须要治理，而你并不心愿登录到远端机器去更改配置，并重启利用，尤其是当初曾经是容器的时代了，也不心愿因为一个配置的变更，而公布一个新的软件包。那么分布式系统中每个过程的动静配置管理及运行时热加载就成为了一个亟待解决的问题。https://github.com/go-chassis... 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来决定配置项状态

配置运行时热加载

在运行时能够随时通过对立的配置核心或者本地文件（不举荐分布式环境登到机器里改文件，但在本地debug时还是举荐应用文件来测试程序的热加载逻辑）更改配置了，那么接下来要解决的问题就是配置在运行时失效。

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

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

向archaius注册监听器，须要本人编写监听器的逻辑，每当事件登程后就会通过archaius中的数据构建一个构造体数据，而后将数据存到本地缓存，首先应用lock的写锁锁住router config，更新后，解开写锁。

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

例子

一个本地文件事件监控的例子

https://github.com/go-chassis...

治理本地多文件的例子

https://github.com/go-chassis...

Go chassis介绍

https://juejin.im/post/684490...

点击关注，第一工夫理解华为云陈腐技术~