共计 2549 个字符，预计需要花费 7 分钟才能阅读完成。
【摘要】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…
点击关注，第一工夫理解华为云陈腐技术~