微服务配置中心完全解读

本文作者:风卿,Nacos 社区 committer.

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

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

  • 工作所需,要做一款好用的开源产品,去试用提供相似功能的开源产品是必要的环节,以找出优势,弥补不足;
  • 用户所需,对于提供相似功能的产品进行选型对比,是引入某个开源项目必须要做的事,如果有一份参考,那么势必能提供一些帮助;(建议:即便有一份可参考的材料,技术选型的工作仍需要亲力亲为,实际的业务场景和资源配置才是技术选型最重要的依据);
  • 微服务配置中心是一个微服务组件,而不是一个大的框架,选型成本较小,客观对比时不易走偏;

本文将从产品功能、使用体验、实施过程和性能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使用起来相对简单,易用性相对更好些。

多环境

在实际生产中,配置中心常常需要涉及多环境或者多集群,业务在开发的时候可以将开发环境和生产环境分开,或者根据不同的业务线存在多个生产环境。如果各个环境之间的相互影响比较小(开发环境影响到生产环境稳定性),配置中心可以通过逻辑隔离的方式支持多环境。

Spring Cloud Config支持Profile的方式隔离多个环境,通过在Git上配置多个Profile的配置文件,客户端启动时指定Profile就可以访问对应的配置文件。

Apollo也支持多环境,在控制台创建配置的时候就要指定配置所在的环境,客户端在启动的时候指定JVM参数ENV来访问对应环境的配置文件。

Nacos通过命名空间来支持多环境,每个命名空间的配置相互隔离,客户端指定想要访问的命名空间就可以达到逻辑隔离的作用。

多集群

当对稳定性要求比较高,不允许各个环境相互影响的时候,需要将多个环境通过多集群的方式进行物理隔离。

Spring Cloud Config可以通过搭建多套Config Server,Git使用同一个Git的多个仓库,来实现物理隔离。

Apollo可以搭建多套集群,Apollo的控制台和数据更新推送服务分开部署,控制台部署一套就可以管控多个集群。

Nacos控制台和后端配置服务是部署在一起的,可以通过不同的域名切换来支持多集群。

配置实时推送的对比

当配置变更的时候,配置中心需要将配置实时推送到应用客户端。

Nacos和Apollo配置推送都是基于HTTP长轮询,客户端和配置中心建立HTTP长联接,当配置变更的的时候,配置中心把配置推送到客户端。

Spring Cloud Config原生不支持配置的实时推送,需要依赖Git的WebHook、Spring Cloud Bus和客户端/bus/refresh端点:

  • 基于Git的WebHook,配置变更触发server端refresh
  • Server端接收到请求并发送给Spring Cloud Bus
  • Spring Cloud Bus接到消息并通知给客户端
  • 客户端接收到通知,请求Server端获取最新配置

整体比较下来,Nacos和Apollo在配置实时推送链路上是比较简单高效的,Spring Cloud Config的配置推送引入Spring Cloud Bus,链路较长,比较复杂。

部署结构 & 高可用的对比

Spring Cloud Config

Spring Cloud Config包含config-server、Git和Spring Cloud Bus三大组件:

  • config-server提供给客户端获取配置;
  • Git用于存储和修改配置;
  • Spring Cloud Bus通知客户端配置变更;

本地测试模式下,Spring Cloud Bus和config-server需要部署一个节点,Git使用GitHub就可以。在生产环境中,Spring Cloud Config,config-server需要部署至少两个节点。Spring Cloud Bus如果使用RabbitMQ,普通集群模式至少需要两个节点。

Git服务如果使用GitHub就不用考虑高可用问题,如果考虑到安全性要自建Git私有仓库,整体的成本比较高。Web服务可以部署多节点支持高可用,由于Git有数据的一致性问题,可以通过以下的方式来支持高可用:

  • Git+Keepalived冷备模式,当主Git挂了可以马上切到备Git;
  • Git多节点部署,存储使用网络文件系统或者通过DRBD实现多个Git节点的数据同步;

Apollo

Apollo分为MySQL,Config Service,Admin Service,Portal四个模块:

  • MySQL存储Apollo元数据和用户配置数据;
  • Config Service提供配置的读取、推送等功能,客户端请求都是落到Config Service上;
  • Admin Service提供配置的修改、发布等功能,Portal操作的服务就是Admin Service;
  • Portal提供给用户配置管理界面;

本地测试Config Service,Admin Service,Portal三个模块可以合并一起部署,MySQL单独安装并创建需要的表结构。在生产环境使用Apollo,Portal可以两个节点单独部署,稳定性要求没那么高的话,Config Service和Admin Service可以部署在一起,数据库支持主备容灾。

Nacos

Nacos部署需要Nacos Service和MySQL:

  • Nacos对外提供服务,支持配置管理和服务发现;
  • MySQL提供Nacos的数据持久化存储;

单机模式下,Nacos可以使用嵌入式数据库部署一个节点,就能启动。如果对MySQL比较熟悉,想要了解整体数据流向,可以安装MySQL提供给Nacos数据持久化服务。生产环境使用Nacos,Nacos服务需要至少部署三个节点,再加上MySQL主备。

整体来看

Nacos的部署结构比较简单,运维成本较低。Apollo部署组件较多,运维成本比Nacos高。Spring Cloud Config生产高可用的成本最高。

多语言支持的对比

一个公司的各个系统可能语言不尽相同,现在使用的比较多的比如C++,Java,PHP,Python,Nodejs,还有Go等。引入配置中心之后,配置中心要想让多语言的系统都能享受到动态配置的能力,需要支持多语言生态。

多语言支持

Spring Cloud服务于Java生态,一开始只是针对Java微服务应用,对于非Java应用的微服务调用,可以使用Sidecar提供了HTTP API,但动态配置方面还不能很好的支持。
Apollo已经支持了多种语言,并且提供了open API。其他不支持的语言,Apollo的接入成本相对较低。

Nacos支持主流的语言,例如Java、Go、Python、Nodejs、PHP等,也提供了open API。

迁移支持

国内主流的互联网公司仍是以Java为主,除了原生Java SDK,在对整个Java生态,比如Spring Boot和Spring Cloud的支持上,三个产品都是支持的。

Spring Cloud Config原生就支持Spring Boot和Spring Cloud,Nacos通过Spring Cloud for Alibaba支持Spring Boot和Spring Cloud生态,符合Spring生态中的标准实现方式,可以无缝从Spring Cloud Conig迁移到Nacos。

Apollo支持Spring Boot和Spring Cloud项目,但是实现方式不同于标准,无法做无缝迁移,从Spring Cloud迁移到Apollo,存在代码改造和兼容性成本。

性能对比

性能也是配置中心绕不过的一环,在同样的机器规格下,如果能支撑更大的业务量,势必能替公司节省更多的资源成本,提高资源利用率。应用客户端对配置中心的接口操作有读、写和变更通知,由于变更通知需要大量的客户端实例,不好模拟测试场景,下面仅对读和写操作做了测试。

硬件环境

Nacos和Apollo使用同样的数据库(32C128G),部署Server服务的机器使用的8C16G配置的容器,磁盘是100G SSD。

版本

Spring Cloud Config使用2.0.0.M9版本,Apollo使用1.2.0 release版本,Nacos使用0.5版本。

单机读场景

客户端测试程序通过部署多台机器,每台机器开启多个线程从配置中心读取不同的配置(3000个)。Nacos QPS可以达到15000,Apollo分为读内存缓存和从数据库中读两种方式,从数据库中读能达到7500,从内存读缓存性能可以达到9000QPS。Spring Cloud Config使用jGit读写Git,由于有客户端限制,单机读能力被限制在7QPS。

3节点读场景

将配置中心的压测节点数都部署成3个节点。Nacos QPS可以达到45000 QPS,Apollo读内存缓存可以达到27000 QPS。Nacos和Apollo由于读场景各个节点是独立的,基本就是单机读场景的3倍关系。Spring Cloud Config三个节点读能力可以到达21QPS。

单机写场景

同样的方式,多台机器同时在配置中心修改不同的配置。Nacos QPS可以达到1800,Apollo未使用默认的数据库连接池(10)QPS只能达到800 QPS(CPU未压满),调整连接池至100可以达到1100 QPS(CPU压满)。Git在提交同一个项目的时候会加锁,单机Git写能在5QPS左右,Spring Cloud Config在使用的时候以一个项目作为数据源,写能力受到Git限制。

3节点写场景

同样的方式,将配置中心的压测节点数都部署成3个节点。Nacos QPS可以达到6000,Apollo可以达到3300 QPS(CPU压满),此时MySQL数据库因为配置较高,未成为性能瓶颈。Spring Cloud Config三个节点时候,Git也是一个节点,写QPS为5。

整体上来看,Nacos的读写性能最高,Apollo次之,Spring Cloud Config的依赖Git场景不适合开放的大规模自动化运维API。

功能特性对比总结

这里列一个表格总结一下三个产品的功能特点。

总的来说,Apollo和Nacos相对于Spring Cloud Config的生态支持更广,在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面,不过使用起来也要麻烦一些。Nacos使用起来相对比较简洁,在对性能要求比较高的大规模场景更适合。

此外,Nacos除了提供配置中心的功能,还提供了动态服务发现、服务共享与管理的功能,降低了服务化改造过程中的难度。

以上,我们从产品功能、使用体验、实施过程和性能 4 个纬度对Spring Cloud Config、Apollo和Nacos进行对比。但对于一个开源项目的选型,除了以上这4个方面,项目上的人力投入(迭代进度、文档的完整性)、社区的活跃度(issue的数量和解决速度、Contributor数量、社群的交流频次等)、社区的规范程度(免责说明、安全性说明等),这些可能才是用户更关注的内容。

参考文档

https://springcloud.cc/spring-cloud-config.html
https://github.com/ctripcorp/apollo
https://nacos.io/

原文链接:https://mp.weixin.qq.com/s/8BHjBhqCfygzFsTBXJOkhg

Image placeholder
IT头条
未设置
  22人点赞

没有讨论,发表一下自己的看法吧

推荐文章
Hyperf 发布 Session、极简 DB、zk 配置中心组件和支持 Twig/Plates 视图引擎支持

更新内容 本周更新主要新增极简DB组件,Zookeeper配置中心,和Session组件,以及为视图组件增加了Twig和Plates视图引擎的支持,同时为计划任务组件增加了集群执行的支持。极简DB组件

Hyperf 接入阿里 ACM 配置中心

后期更改配置有两种方法,一是使用DockerSwarmConfig,这个在部署章节有说明。二就是使用在线的配置中心,这里介绍阿里的ACM。注册阿里云并开通ACMhttps://acm.console.

Nacos配置中心原理

动态配置管理是Nacos的三大功能之一,通过动态配置服务,我们可以在所有环境中以集中和动态的方式管理所有应用程序或服务的配置信息。动态配置中心可以实现配置更新时无需重新部署应用程序和服务即可使相应的配

《Gartner 2019年数据中心网络魔力象限》报告解读

日前,Gartner发布了2019年数据中心网络魔力象限。此次报告从7个维度(产品或服务、总体生存能力、销售执行/定价、市场反应/记录、营销执行、客户体验和操作),来衡量12个入选企业,并基于前瞻性和

【CSS全解01】CSS基础-体系化学CSS

大纲 基础部分学习占比:HTML1%`CSS19%Javascript80%`(`基础部分?%框架?%`项目?%) CSS历史 AcidTestforbrowser CSS是艺术(非逻辑,用测试经验来

ES6系列之箭头函数全解析

引言ES6中允许使用箭头=>来定义箭头函数,是ES6中较受欢迎也较常使用的新增特性。本文将从箭头函数的基本语法,与普通函数对比,箭头函数不适用场景三个方面进行梳理。基本语法//箭头函数 letfunc

Elasticsearch分词器介绍、内置分词器及配置中文分词器

1、分词器、分词器是从一串文本中切分一个个的词条,并对每个词条进行标准化,包含三个部分: characterfilter:分词之前的预处理,过滤掉HTML标签、特殊符号转换(例如,将&符号转换成and

微服务架构之「 服务注册 」

微服务架构是一个庞大复杂的工程,为什么说它庞大复杂呢?因为想要做好微服务,就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章《架构设计之「微服务入门」》中已经初步介绍过了这些组件,包括:

一站式入口服务|爱奇艺微服务平台 API 网关实战

写在前面在互联网业务微服务化改造过程中,按照以往的服务治理体系,各服务需要单独实现限流、鉴权、监控、日志等通用功能,构建入口时资源申请、工单批复、多系统配置等一系列流程对精力消耗极大,学习成本较高

微服务架构中如何构建一个数据报告服务?

场景描述在微服务架构中,每个微服务负责自己的数据库,微服务A是不允许直接连接微服务B的数据库进行操作的。现在有2个微服务,一个是订单服务,一个是用户服务。有一个数据报告的需求:生成一份包含用户信息的订

号称以客户为中心的保险行业如何做到真正的“按需”服务?

随着客户消费模式的改变和对服务要求的不断提高,当前保险行业正经历深刻变化。虽然保险行业已经积累了大量的客户数据,但由于其业务的复杂性及缺少系统的建设,大多数数据都是孤立的。而在数字化浪潮的推进下,许多

前端微服务在字节跳动的落地之路

不少前端团队都面临着独石应用的工程巨大、理解困难和合作混乱的种种问题,微前端或许是一种比较好的解决方案,它允许我们为应用加入新功能而不影响整体结构。但同时,我们可能会付出一些代价,例如重复依赖、团

🚀 Hyperf 发布 v1.1.8 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 新增 #965新增RedisLua模块,用于管理Lua脚本; #1023hyperf/metric组件的Prometheus驱动新增CUSTOM_MODE模式; 修复 #1013修复Js

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象管

《PHP 微服务练兵》系列教程

本系列教程将从零开始使用PHP搭建微服务,涉及知识docker、mysql、Elasticsearch+Kibana日志分析系统、minio文件储存、阿里ACM配置中心、jenkens自动化测试部署、

微服务架构:拆分单体应用的难点

拆分单体应用为服务的难点从表面上看,通过定义与业务能力或子域相对应的服务来创建微服务架构的策略看起来很简单。但是,你可能会遇到几个障碍:网络延迟。同步进程间通信导致可用性降低。 在服务之间维持数据一致

微服务架构的四大金刚利器

Photo@ChristopherCampbell 文 | 孔凡勇概述互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分

大神讲解微服务治理的技术演进和架构实践

摘要:随着业务的发展,规模扩大,服务越来越多,需要协调线上运行的各个服务,保障服务的SLA;基于服务调用的性能KPI数据进行容量管理,合理分配各服务的资源占用;对故障业务做服务降级、流量控制、流量迁移

从五个方面入手,保障微服务应用安全

随着计算机、互联网技术的飞速发展,信息安全已然是一个全民关心的问题,也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。对

基于JWT规范实现的认证微服务

本文由公众号EAWorld翻译发表,转载需注明出处。作者:MarceloFonseca译者:白小白 原题:Buildinganauthenticationmicro-servicewithJWTsta

一个知名网站的微服务架构最佳实现

译者:蓝梦,十余年研发经验,现就职于某上市互联网公司。作者:小马,Medium 首席架构师。译者有话说,如果你的项目正在从单体升级为微服务而忧心;或者你在实践微服务过程中手忙脚乱,本文都是你不容错过的

可伸缩的微服务告警系统设计指南

Uber的软件架构由成千上万的微服务组成,有赖于此,我们的团队可以快速的自主迭代并支撑公司的全球扩张。这一架构支撑了大量的上层解决方案,如移动应用,内部基础设施服务,以及拥有复杂配置的产品,相关配置会

再见微服务,从100多个问题儿童到一个超级明星

翻译| 马岛本文翻译自AlexandraNoonan的 GoodbyeMicroservices:From100sofproblemchildrento1 superstar。内容是描述 Segmen

微服务?数据库?它们之间到底是啥关系?

过去几年来,“微服务架构”这个术语持续火热,它描述了一种将软件应用程序设计为可独立部署的服务套件的特定方式。尽管这种架构风格没有确切的定义,但围绕业务能力,自动化部署,网点智能以及语言和数据的分散控制