今天这篇文章将从10个维度介绍一下配置中心的选型问题,为什么要写这篇文章呢?是因为:
- 工作所需,要做一款好用的开源产品,去试用提供相似功能的开源产品是必要的环节,以找出优势,弥补不足;
- 用户所需,对于提供相似功能的产品进行选型对比,是引入某个开源项目必须要做的事,如果有一份参考,那么势必能提供一些帮助;(建议:即便有一份可参考的材料,技术选型的工作仍需要亲力亲为,实际的业务场景和资源配置才是技术选型最重要的依据);
- 微服务配置中心是一个微服务组件,而不是一个大的框架,选型成本较小,客观对比时不易走偏;
本文将从产品功能、使用体验、实施过程和性能4个纬度进行对比,所有素材均来源于该开源项目的官网或GitHub项目页。
如果您对微服务配置中心的功能不是很了解,可以看下以下的背景介绍,若比较熟悉可以直接跳过。
1、为什么需要配置中心
1、配置实时生效
传统的静态配置方式要想修改某个配置只能修改之后重新发布应用,要实现动态性,可以选择使用数据库,通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长,轮询频率高,感知配置变化的延时就短,但比较损耗性能,需要在实时性和性能之间做折中。配置中心专门针对这个业务场景,兼顾实时性和一致性来管理动态配置。
2、配置管理流程
配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。
2、开源配置中心基本介绍
目前市面上用的比较多的配置中心有:(按开源时间排序)
Disconf
2014年7月百度开源的配置管理中心,同样具备配置的管理能力,不过目前已经不维护了,最近的一次提交是两年前了。
Spring Cloud Config
2014年9月开源,Spring Cloud 生态组件,可以和Spring Cloud体系无缝整合。
Apollo
2016年5月,携程开源的配置管理中心,具备规范的权限、流程治理等特性。
Nacos
2018年6月,阿里开源的配置中心,也可以做DNS和RPC的服务发现。
3、配置中心核心概念的对比
由于Disconf不再维护,下面对比一下Spring Cloud Config、Apollo和Nacos。Spring Cloud Config、Apollo和Nacos在配置管理领域的概念基本相同,但是也存在一些不同的点,使用配置的过程中会涉及到一些比较重要的概念。
1、应用
应用是客户端系统的基本单位,Spring Cloud Config 将应用名称和对应Git中的文件名称关联起来了,这样可以起到多个应用配置相互隔离的作用。Apollo的配置都是在某个应用下面的(除了公共配置),也起到了多个应用配置相互隔离的作用。Nacos的应用概念比较弱,只有一个用于区分配置的额外属性,不过可以使用 Group 来做应用字段,可以起到隔离作用。
2、集群
不同的环境可以搭建不同的集群,这样可以起到物理隔离的作用,Spring Cloud Config、Apollo、Nacos都支持多个集群。
3、 Label Profile & 环境 & 命名空间
Spring Cloud Config可以使用Label和Profile来做逻辑隔离,Label指远程仓库的分支,Profile类似Maven Profile可以区分环境,比如{appl