深度对比三种主流微服务配置中心
|
副标题[/!--empirenews.page--]
【编者的话】在撰写这篇技术选型的文章之前，是比较犹豫的。因为，以其中一个开源项目开发者的身份，去写一篇三个开源项目的对比，即便很克制的去客观的比较，也很难有信服力。这就像，既是参赛选手，又想做裁判，观众肯定是不买账的。 但最后，仍然决定去写一篇配置中心的技术选型参考文，是因为： 工作所需，要做一款好用的开源产品，去试用提供相似功能的开源产品是必要的环节，以找出优势，弥补不足; 用户所需，对于提供相似功能的产品进行选型对比，是引入某个开源项目必须要做的事，如果有一份参考，那么势必能提供一些帮助;(建议：即便有一份可参考的材料，技术选型的工作仍需要亲力亲为，实际的业务场景和资源配置才是技术选型最重要的依据); 微服务配置中心是一个微服务组件，而不是一个大的框架，选型成本较小，客观对比时不易走偏; 本文将从产品功能、使用体验、实施过程和性能4个纬度进行对比，所有素材均来源于该开源项目的官网或GitHub项目页。 如果您对微服务配置中心的功能不是很了解，可以看下以下的背景介绍，若比较熟悉可以直接跳过。 为什么需要配置中心 配置实时生效： 传统的静态配置方式要想修改某个配置只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置变化的延时就短，但比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。 配置管理流程：
开源配置中心基本介绍 目前市面上用的比较多的配置中心有(按开源时间排序)：
配置中心核心概念的对比 由于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使用起来相对简单，易用性相对更好些。 多环境 （编辑：孝感站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
