我们知道,在程序中不应该把代码或流程写死,而应该把一些流程提取成开关、变量等。这样,就可以在不改变代码的情况下,在程序运行时执行不同的功能。这些开关、变量的集合一般放在一个或者多个文件里,称之为配置文件。一般来说,大部分程序都会存在这个文件,既然有文件,就需要管理。尤其是现在微服务化的趋势下,服务拆分,服务数量变多,配置文件的数量也跟着增加,就需要一个中心化的服务来管控这些配置文件,我们称之为配置中心,它一般会提供以下能力:
那么,如何才能做好一个配置中心?下面列出几种可行的方案,并对比了其中的区别和优缺点。
配置信息存到 Git,比如:Spring 的 ConfigServer。这种方式利用了 Git 的存储特性和保存历史提交的特性,开发量小,接入简单,架构图如下:
在写入端,管理员通过 git push
推送配置到仓库,并且能通过 git 提供的历史提交、权限管理等功能,对配置进行集中化管理,企业的 git 仓库一般也都会备份,所以数据不容易丢失。
在获取端,git 的弊端就比较明显了,你不能直接在程序中访问 git 获取配置,只能用个服务做中转,它根据程序的元信息去 git 仓库取配置,也不支持自动更新(虽然可以利用 git webhook,但是中转服务如何通知到程序,还是个问题。)而且加密解密也只能做到中转服务里,发送给程序的配置文件是不能加密的,不然程序没办法读取。
最后,Git 本身是单点服务,要是升级个版本或者做些运维操作时候,把 git 服务器弄挂了,就没办法获取配置了。
总而言之,读者可以发现,如果使用 git,其实整个系统中最关键的节点是中转服务,也就是那个 ConfigServer,可是既然要满足一个配置中心的所有要求,需要对这个 ConfigServer 进行开发迭代,那还不如把配置文件存到 Mysql 里,Mysql 相对更稳定,运维经验成熟,也容易扩展一些。
Apollo 就是这样做的,它没有依赖 git 去实现历史版本、权限等功能,全部由自己实现,它的架构图如下(从官网下载):
Apollo 确实是配置中心的标杆级项目,基本实现了一个配置中心的所有该有的功能,也十分契合当今微服务化、分布式的趋势,无需吹嘘它的功能多么多么强大,明者自鉴。只需说它的一个最大缺点,这个缺点正是源自它众多的功能 --- 它太复杂了。
我们不说如上的架构图,一个新手能不能看懂。就说它提供的命名空间、集群、环境、注册中心等等概念,就不是一下子能快速上手的。而且这么多功能在它的管理后台上,老实说组织的确实比较乱,东一块西一块的,没有层级划分。
我感觉 Apollo 和 git 配置中心正好相反,git 配置中心架构简单,功能不丰富;Apollo 提供了所有的能力,架构也是非常复杂。
随着云原生时代的来临,越来越多的组织在它们的技术架构中添加注册中心,以处理越来越多的微服务之间的发现和通信问题。Nacos 就是开源的注册中心中的佼佼者,它在 2.0 版本中又增加了配置中心的功能,让配置中心和注册中心得以合并。
Nacos 的问题主要是它不是专注于配置中心,提供的功能相对比较薄弱。比如:只有 java 的客户端,其它语言客户端是社区贡献,文档方面会差一些;不支持配置的加密解密(新版本支持了,但是需要编译,工作量大);自动更新支持的不是很好等等。
Nacos 目前还在蓬勃发展,也是属于 Java 世界中配置中心的比较好的一个选择。
最后剩下的一类,就是不使用开源方案,全自研。自研的好处就是可以适应内部项目,便于迭代和掌控。而且,配置中心说到底,也不是一个十分复杂的项目,自研起来并没有特别的难点。
自研的配置中心一般类似于 Apollo和 Nacos,通过 Mysql 来存储配置,并提供一个管理界面。可以理解为对这两个项目进行模仿和改造,虽然会有些不同,但殊途同归,基本上是差不了多少的。
这里还有一类自研的配置中心,用的不是 mysql 存储配置,而是 ETCD。原因是 ETCD 提供的功能,和配置中心的需求重合性很高,天生就比较适合,自研起来工作量小,基本上,只需要开发个操作 ETCD 的配置的后台即可。我们把配置中心的六大需求一个个拉下来看:
配置存在 ETCD,因为 ETCD 没有专门的配置中心后台,需要自己实现一个,做出来增删改查和权限管控,就基本可以了。
ETCD 作为 Kubernetes 的底层存储,安全性应该是很有保证了。
V3版本支持 基于 grpc 的 Watch 机制,性能和可用性都有保证,可以实时更新配置。
加密这块 ETCD 本身也不支持,需要开发。
支持多节点部署,作为云原生时代的基础设施,相关运维的经验也比较丰富,可用性有保证。
有各语言的 SDK,接入起来比较简单。
这里最难的就是高可用部署,如果自研,多节点数据一致性保证,包括后期的运维都是在重复造 ETCD 的轮子。配置中心本身的属性也决定了它不是被高频访问的应用,因此 ETCD 提供的并发能力完全已经足够了。
Sail 是一款开源的配置中心,它是我在开发了多款配置中心的基础上,总结经验,最后写出的一个开源项目,实际上,它的架构核心正是 ETCD:
它为 ETCD 提供了一个专业的配置中心管理界面,通过界面对配置进行增删改查,并且提供了sdk,简化接入 etcd 的步骤。从配置中心的六大能力块来看:
通过 Web 管理界面管理,支持配置层级划分、公共配置、权限管理、配置增删改查、多种类型的配置等各种功能。
正如上面所说,基于 ETCD 的 Sail,无需开发数据安全、一致性保证等功能,ETCD 本身会提供。
封装 ETCD 的 SDK,提供更简单的接入。
源头上支持加密,ETCD 存储的就是加密信息。在 SDK 中解密。解密秘钥可以通过环境变量等方式传递,环境变量可以通过 Jenkins 等发布系统注入,全程秘钥可以不公开,运行时才解密,保证了配置的安全性。
可用性也是通过 ETCD 保证,ETCD 的部署节点越多,则越安全。但官方建议,不要超过 7 个。
提供 golang SDK ,go 项目接入起来无任何压力。其它语言项目,需要通过 ETCD 提供的语言相关客户端处理。
同时,Sail 还在全力开发 配置发布管理 和 监控指标输出 功能,这是 Sail 的最后两块拼图。
通过发布管理,可以控制自动更新时的策略,是按比例推送,还是先推指定节点等。
监控指标输出,则是对接 Prometheus,完善配置中心的可观察性。
最后,引用那句经典的“软件开发里没有银弹”,我想补充一句:“你要知道你手里有哪些类型的子弹。”通过对比和分析,来确定当时,当地,最适合项目的那个方式,比如项目着急上线,先直接把配置文件写死在代码里,都不是不可以的,后期可以再改。如何做好一款配置中心?希望看完本文你能有自己的答案。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。