配置中心介绍
除适用于服务治理场景外,Nacos
也能够以配置中心的角色在微服务架构中发挥重要的作用。下面笔者将对 Nacos
配置中心的整合和功能实现进行编码与讲解。不过,在编码前,读者首先要了解什么是配置中心,以及配置中心有什么作用。
编码中常用的配置方式分析
关于开发项目过程中做的一些配置,读者应该都不陌生,如常见的直接在代码里定义一个变量,或者通过配置项目的配置文件来实现。总结一下,编码时常用的配置方式有硬编码、使用项目的配置文件、启动命令指定变量、数据库动态获取,通过这四种方式都能够在项目中进行配置项的更改和使用,四种配置方式的实现整理如下。
硬编码的配置方式
这是最简单、常用的配置方式,直接通过在代码中定义一个变量来指定配置项的内容,如下面的代码,通过硬编码的方式指定了返回结果时的提示信息及购物车中单个商品的最大购买数量两个配置。
if (goodsId < 1) {
return ResultGenerator.genFailResult("参数异常");
}
public final static int SHOPPING_CART_ITEM_LIMIT_NUMBER = 5; // 购物车中单个商品的最大购买数量(可根据自身需求修改)
这种方式就是直接定义代码,不能动态修改。只有停止项目,修改后再重启项目,配置项才会生效。
使用项目的配置文件的配置方式
在普通的 SSM
项目中,常用的配置文件为 web.xml
、spring-context.xml
、spring-context-mvc.xml
、mybatis-config.xml
,在 Spring Boot
项目中则常用 application.yml
、application.properties
、bootstrap.yml
、bootstrap.properties
配置文件来设置项目的配置项,这是最为常见的方式,也是比较灵活和优雅的配置方式。因篇幅有限,这里就不展示这些配置文件的代码片段了。
启动命令指定变量的配置方式
使用命令中的 -D
参数(-DpropName=propValue
)或 --propName=propValue
传入配置项对项目中的一些变量进行配置。
比如,通过启动命令传入数据库地址,命令如下:
java -jar -DdatabaseUrl="mysql://localhost:3306/newbee_mall_db?user=root&password=root" newbee_mall_release.jar
Spring Boot
项目可以使用 --propName=propValue
的方式,如通过启动命令指定当前生效的环境配置及启动端口号,命令如下:
java -jar newbee-mall-release.jar --spring.profiles.active=dev --server.port=28081
数据库动态获取的配置方式
将配置项保存在数据库中,如 MySQL
或 Redis
等存储介质,每次请求时都会执行一条 SELECT
语句实现动态查询,需要动态更新的配置项存储在数据库中也是常见的配置方式,建表语句示例如下:
CREATE TABLE `tb_system_config` (
`config_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`config_key` varchar(50) NOT NULL DEFAULT '' COMMENT '配置项',
`config_value` varchar(50) NOT NULL DEFAULT '' COMMENT '配置内容',
`updated_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`created_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`config_id`),
UNIQUE KEY `idx_config_key` (`config_key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='系统配置表';
不过,以上几种配置方式或多或少都有一些缺点。硬编码的方式太死板,硬编码、使用项目的配置文件、启动命令指定变量的方式不够灵活,如果要对配置项进行变更,就必须对代码、配置文件或启动命令进行修改,之后重新编译打包部署,无法实现在项目运行时动态变更配置项。数据库动态获取的方式更为灵活,但是使用数据库作为配置中心需要进行额外的编码,并且存在性能问题,这种方式使开发工作变得更加复杂。
另外,随着业务量的增加和系统架构的演变,系统应用涉及数十个研发团队、上百台服务器、成百上千个服务实例,以上几种配置方式会暴露更多缺点,部分缺点整理如下。
-
无法实现动态更新配置项:一旦需要更新配置,就要重新编译打包部署,在分布式项目的开发流程中极不灵活,并且给开发人员带来额外的工作量。
-
纯粹的工作量增加:随着分布式系统中实例数量的不断增加,配置信息也会相应增多,配置信息的变更和维护就会增加更多的工作量,并且这个过程费时费力、容易出错。
-
没有版本管理和回滚机制:在开发过程中,配置经常被修改,版本控制非常必要,一旦出现问题能够对配置项进行快速回滚是非常必要的。
除上述缺点外,前述的几种配置方式还存在缺少权限控制、无法统一管理、管理难度大等缺点。
当然,如果没有开发大型的分布式项目,或者项目体量并不大,那么使用前述的几种配置方式完全没有问题,一些缺点也根本称不上缺点。
为什么需要配置中心
通过对编码中常用配置方式的举例和分析,能够发现随着业务量的增加和系统架构的演变、开发团队人员的增加、服务实例及配置信息的日益增多,一些常用的配置方式或通过数据库动态读取配置项的方式已无法满足开发人员对配置管理的要求。此时,系统中需要一个新的角色来统一管理配置项。
配置中心产生的原因是解决分布式系统中配置信息管理的问题。在分布式系统中,由于服务器数量众多,服务被部署在不同的位置,并且服务之间的依赖关系错综复杂,因此配置信息管理成为一个重要的问题。配置中心的出现可以解决这些问题,使得配置信息集中管理、易于维护,并且可以动态更新配置,使得分布式系统更加稳定、可靠。
总结一下,有以下几个原因需要使用配置中心。
-
使得应用程序能够更方便地获取配置信息,而不是将这些信息硬编码在程序里。
-
更方便地管理配置信息,使得修改配置信息更加方便。
-
当配置信息需要在多个环境中使用时(如开发、测试、生产等),使用配置中心可以方便地将配置信息进行分环境管理。
-
当部署应用程序集群时,使用配置中心可以方便地将配置信息同步到集群中的所有节点。
-
配置中心可以提供配置信息的版本管理功能,便于回滚和追踪变更历史。
当然,如果配置项不多或业务并不复杂,使用配置文件或硬编码的方式其实更加方便和简单,配置中心更适合大型的分布式项目使用。
什么是配置中心
配置中心是一种用于管理应用程序或系统配置信息的中央服务。它允许开发人员在多个环境(如开发、测试、生产)之间共享配置,并且可以在不停止应用程序的情况下动态更新配置,如图 6-25 所示。

配置中心是统一管理各种应用配置的工具。它能够集中管理系统中各个应用程序的配置,并将其分发到各个应用程序。这样,当需要更新配置项时,只需要在配置中心进行修改,而不需要更改每个具体的项目实例代码,也不需要重新打包、启动项目。区别于常见的几种配置方式,配置中心采用中心化统一的配置方式,降低了维护多个配置文件的复杂度。配置中心是一个将配置从各应用程序中剥离出来,作为一个单独的模块进行配置的分布式系统工具。对配置进行统一管理,应用程序自身不需要管理配置。
配置中心与应用程序的关系很简单,首先是独立,其次是能够提供系统所需的各种配置项的管理能力。二者的关系如图 6-26 所示。

配置中心就是把分布式系统中的配置项分离出自身的管理系统,而这些信息又能被应用程序实时获取。区别于常见的配置方式,配置中心一般是一个独立存在的组件,独立部署、独立运行。
使用配置中心可以帮助企业更好地管理配置,提高系统的可靠性和可维护性。如果需要灵活更改配置,避免重新部署系统,配置中心可以提供很好的帮助。目前,配置中心的落地方案已经非常丰富,成熟且被开发团队所使用的配置中心方案有携程旗下的 Appllo
、阿里巴巴旗下的 Nacos Config
、Apache
旗下的 ZooKeeper
、Spring
官方团队旗下的 Spring Cloud Config
、HashiCorp
旗下的 Consul
等,这些方案都提供了一些基本的配置管理功能,如存储配置、分发配置、权限等。
对这些落地方案感兴趣的读者可以查阅对应的官方文档,了解各配置中心间的详细对比信息,本书所选择的方案是 Nacos Config
,就不再拓展介绍了。
读者可能会思考这样一个问题:MySQL
、Redis
等数据库虽然独立于分布式系统之外,但是可以提供配置的存储和更新,只要读取就可以获取最新的配置,是否能够作为配置中心呢?
其实,这个问题在前文中已经说明了。使用数据库作为配置中心需要进行额外的编码,并且存在性能问题,这种方式使开发变得更复杂,充其量只能算是一个配置中心的半成品,数据库的主业还是系统中的存储方案。数据库不能主动推送配置更新、没有配置信息的版本管理、不能及时回滚。因此,不能将数据库方案当作一个合格的配置中心方案。
这个问题可以引出另一个需要讲解的知识:配置中心应该具备哪些功能。
配置中心具备哪些功能
配置中心具备的基本功能如下。
-
配置存储:配置中心可以存储各种应用程序的配置信息,如数据库连接配置项、项目信息配置项等。
-
配置版本控制:配置中心可以记录每次修改配置信息的版本,方便回滚和比较。
-
配置发布:配置中心可以将修改后的配置信息发布到指定的环境中,如开发环境、测试环境和生产环境。
-
配置查询:配置中心提供查询配置信息的功能,方便开发人员查看和调试,如提供封装好的可供客户端调用的API或配置管理页面UI,方便应用开发人员管理和发布配置。
除此之外,配置中心还能够提供如下更加核心的功能。
-
权限控制:管理配置项、实例获取配置项都需要认证授权,无权限的账号不能修改和发布配置,无权限的实例也不能获取相应的配置项。
-
数据持久化:支持将配置项信息持久化到数据库。
-
实时性:支持将配置更新实时推送到使用该配置的服务器节点上。配置更新后需要及时响应至客户端,间隔时间不能太久,理想状态下应该是实时的。
-
高可用:配置中心必须保证高可用,如果单点出现问题,则会导致分布式系统中的部分实例无法正常启动或配置更新。在极端的情况下,如果配置中心不可用,则客户端要有降级策略(如项目代码中保留一份配置文件,若配置中心不可用,则使用默认的配置),保证应用不受影响。
配置中心的优点
配置中心的优点如下。
-
可以将应用程序的配置与代码分离,使得修改配置不需要重新部署代码。
-
可以方便地在开发环境、测试环境和生产环境之间切换配置。
-
可以使用配置中心管理动态配置,这样就可以在不重启应用的情况下更新配置。
-
可以使用配置中心管理分布式系统的配置,这样就可以方便地在多个服务器之间同步配置。
-
可以使用配置中心管理用户个性化的配置,这样就可以为每个用户提供个性化的体验。
总体来说,在分布式系统中引入配置中心,可以避免重复重启服务、动态更改服务参数等。当然,在系统中增加了一个全新的技术组件,也意味着在开发和运维期间引入了新的复杂度。
此时,读者可能会思考这样一个问题:既然配置中心的优点那么多,是不是只要在项目中引入配置中心就万事大吉了,其他几种常用的配置方式就不再使用了呢?
当然不是,项目中的配置项有很多,在分布式系统中引入配置中心后,将大部分的配置项放到配置中心进行管理,部分配置项依然使用配置文件、启动命令参数方式来指定。例如,配置中心的 IP 地址和账号信息要放在项目中,否则无法获取配置中心所管理的配置项。一定要注意,常见的配置方式与配置中心方案并不是互斥的。
配置中心在微服务架构中的作用
有些读者在未接触微服务架构相关技术栈时,可能根本没听说过 “配置中心” 这个概念。配置中心并不是微服务架构独有的,二者并不是强关联的关系。配置中心是一个比较成熟的技术方案,被各个开发团队所使用,不管是微服务架构,还是其他分布式架构,都可以引入配置中心这个角色。
在微服务架构体系中,当然也会使用配置中心作为配置内容的管理者。这样,在编码时就可以将一些必要的配置项添加到配置文件中(如 application.yml
和 bootstrap.yml
),而大部分的配置项会在配置中心里进行存储和发布。微服务架构中的服务实例在启动时从配置中心获取所有的配置项,用于各种实体类的初始化。
配置中心在微服务架构中有很重要的作用,主要有以下几点。
-
集中管理配置:配置中心能够集中管理各种服务的配置信息,避免了在各个服务中硬编码配置的问题。
-
配置信息隔离:在配置中心里维护配置信息,有利于隔离不同环境的配置信息,如开发环境、测试环境、生产环境。
-
配置信息版本管理:配置中心能够管理配置信息的版本,便于回滚和版本控制。
-
动态更新配置:配置中心支持动态更新配置信息,使得服务在运行时能够动态地获取最新配置。
-
减少服务之间的耦合:使用配置中心可以减少服务之间对配置的依赖,有利于提高服务的独立性和可维护性。
以本书中所讲解的 Nacos
配置中心为例,在微服务架构中引入后的架构简图如图 6-27 所示。

从图 6-27 中可以看到配置中心在配置管理方面发挥的作用。Nacos
配置中心可以提供访问控制、版本控制、配置项动态更新、高可用性、环境隔离特性、多格式支持等核心功能。
本节主要讲解配置中心,并通过实际的编码进行相关的功能实现和演示。