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

栏目: Go · 发布时间: 6年前

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

引言

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

架构

Go语言分布式系统配置管理实践--go 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接口,允许你决定如何将文件内容处理为配置项

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

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

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

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

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

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

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

配置运行时热加载

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

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

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

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语言分布式系统配置管理实践--go archaius》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

火球

火球

张传波 / 2012-2 / 39.80元

《火球:UML大战需求分析》融合UML、非UML、需求分析及需求管理等各方面的知识,帮助读者解决UML业界问题、需求分析及需求管理问题。全书主要介绍UML的基本语法、面向对象的分析方法、应用UML进行需求分析的最佳实践及软件需求管理的最佳实践四个方面的内容。 《火球:UML大战需求分析》各章以问题为引子,通过案例、练习、思考和分析等,由浅入深地逐步介绍UML综合应用的知识。《火球:UML大战......一起来看看 《火球》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

XML、JSON 在线转换
XML、JSON 在线转换

在线XML、JSON转换工具