设为首页 - 加入收藏 渭南站长网 (http://www.0913zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 如何 中国 发布 手机
当前位置: 首页 > 广州正版综合 > 外闻 > 正文

深度对比三种主流微服务配置中心

发布时间:2019-04-17 06:24 所属栏目:[外闻] 来源:Dockone.io
导读:【编者的话】在撰写这篇技术选型的文章之前,是比较犹豫的。因为,以其中一个开源项目开发者的身份,去写一篇三个开源项目的对比,即便很克制的去客观的比较,也很难有信服力。这就像,既是参赛选手,又想做裁判,观众肯定是不买账的。 但最后,仍然决定去

【编者的话】在撰写这篇技术选型的文章之前,是比较犹豫的。因为,以其中一个开源项目开发者的身份,去写一篇三个开源项目的对比,即便很克制的去客观的比较,也很难有信服力。这就像,既是参赛选手,又想做裁判,观众肯定是不买账的。

但最后,仍然决定去写一篇配置中心的技术选型参考文,是因为:

工作所需,要做一款好用的开源产品,去试用提供相似功能的开源产品是必要的环节,以找出优势,弥补不足;

用户所需,对于提供相似功能的产品进行选型对比,是引入某个开源项目必须要做的事,如果有一份参考,那么势必能提供一些帮助;(建议:即便有一份可参考的材料,技术选型的工作仍需要亲力亲为,实际的业务场景和资源配置才是技术选型最重要的依据);

微服务配置中心是一个微服务组件,而不是一个大的框架,选型成本较小,客观对比时不易走偏;

本文将从产品功能、使用体验、实施过程和性能4个纬度进行对比,所有素材均来源于该开源项目的官网或GitHub项目页。

如果您对微服务配置中心的功能不是很了解,可以看下以下的背景介绍,若比较熟悉可以直接跳过。

为什么需要配置中心

配置实时生效:

传统的静态配置方式要想修改某个配置只能修改之后重新发布应用,要实现动态性,可以选择使用数据库,通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长,轮询频率高,感知配置变化的延时就短,但比较损耗性能,需要在实时性和性能之间做折中。配置中心专门针对这个业务场景,兼顾实时性和一致性来管理动态配置。

配置管理流程:

  • 配置的权限管控、灰度发布、版本管理、格式检验和安全配置等一系列的配置管理相关的特性也是配置中心不可获取的一部分。

开源配置中心基本介绍

目前市面上用的比较多的配置中心有(按开源时间排序):

  • Disconf,2014年7月百度开源的配置管理中心,同样具备配置的管理能力,不过目前已经不维护了,最近的一次提交是两年前了。
  • Spring Cloud Config,2014年9月开源,Spring Cloud 生态组件,可以和Spring Cloud体系无缝整合。
  • Apollo,2016年5月,携程开源的配置管理中心,具备规范的权限、流程治理等特性。
  • Nacos,2018年6月,阿里开源的配置中心,也可以做DNS和RPC的服务发现。

配置中心核心概念的对比

由于Disconf不再维护,下面对比一下Spring Cloud Config、Apollo和Nacos。

Spring Cloud Config、Apollo和Nacos在配置管理领域的概念基本相同,但是也存在一些不同的点,使用配置的过程中会涉及到一些比较重要的概念。

应用

应用是客户端系统的基本单位,Spring Cloud Config 将应用名称和对应Git中的文件名称关联起来了,这样可以起到多个应用配置相互隔离的作用。Apollo的配置都是在某个应用下面的(除了公共配置),也起到了多个应用配置相互隔离的作用。Nacos的应用概念比较弱,只有一个用于区分配置的额外属性,不过可以使用 Group 来做应用字段,可以起到隔离作用。

集群

不同的环境可以搭建不同的集群,这样可以起到物理隔离的作用,Spring Cloud Config、Apollo、Nacos都支持多个集群。

Label Profile & 环境 & 命名空间

Spring Cloud Config可以使用Label和Profile来做逻辑隔离,Label指远程仓库的分支,Profile类似Maven Profile可以区分环境,比如{application}-{profile}.properties。

Nacos的命名空间和Apollo的环境一样,是一个逻辑概念,可以作为环境逻辑隔离。Apollo中的命名空间指配置的名称,具体的配置项指配置文件中的一个Property。

配置管理功能的对比

作为配置中心,配置的整个管理流程应该具备流程化能力。

灰度发布

配置的灰度发布是配置中心比较重要的功能,当配置的变更影响比较大的时候,需要先在部分应用实例中验证配置的变更是否符合预期,然后再推送到所有应用实例。

Spring Cloud Config支持通过/bus/refresh端点的destination参数来指定要更新配置的机器,不过整个流程不够自动化和体系化。

Apollo可以直接在控制台上点灰度发布指定发布机器的IP,接着再全量发布,做得比较体系化。

Nacos目前发布到0.9版本,还不支持灰度发布。

权限管理

配置的变更和代码变更都是对应用运行逻辑的改变,重要的配置变更常常会带来核弹的效果,对于配置变更的权限管控和审计能力同样是配置中心重要的功能。

Spring Cloud Config依赖Git的权限管理能力,开源的GitHub权限控制可以分为Admin、Write和Read权限,权限管理比较完善。

Apollo通过项目的维度来对配置进行权限管理,一个项目的owner可以授权给其他用户配置的修改发布权限。

Nacos目前看还不具备权限管理能力。

版本管理&回滚

当配置变更不符合预期的时候,需要根据配置的发布版本进行回滚。Spring Cloud Config、Apollo和Nacos都具备配置的版本管理和回滚能力,可以在控制台上查看配置的变更情况或进行回滚操作。Spring Cloud Config通过Git来做版本管理,更方便些。

配置格式校验

应用的配置数据存储在配置中心一般都会以一种配置格式存储,比如Properties、Json、Yaml等,如果配置格式错误,会导致客户端解析配置失败引起生产故障,配置中心对配置的格式校验能够有效防止人为错误操作的发生,是配置中心核心功能中的刚需。

Spring Cloud Config使用Git,目前还不支持格式检验,格式的正确性依赖研发人员自己。

Apollo和Nacos都会对配置格式的正确性进行检验,可以有效防止人为错误。

监听查询

当排查问题或者进行统计的时候,需要知道一个配置被哪些应用实例使用到,以及一个实例使用到了哪些配置。

Spring Cloud Config使用Spring Cloud Bus推送配置变更,Spring Cloud Bus兼容 RabbitMQ、Kafka等,支持查询订阅Topic和Consumer的订阅关系。

Apollo可以通过灰度实例列表查看监听配置的实例列表,但实例监听的配置(Apollo称为命名空间)目前还没有展示出来。

Nacos可以查看监听配置的实例,也可以查看实例监听的配置情况。

基本上,这三个产品都具备监听查询能力,在我们自己的使用过程中,Nacos使用起来相对简单,易用性相对更好些。

多环境

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章