微服务配置中心作用（微服务服务器配置）

大家好，我是讯享网，很高兴认识大家。

我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第7篇文章，点击查看活动详情

在微服务中，随着服务的拆分，带来的配置文件也逐渐增多，配置和维护不同环境、不同节点下的配置文件变得很麻烦。

配置中心是将分布式系统中配置信息功能，抽离出来，作为一个单独的模块来进行配置的一个微服务组件。区别于传统的配置信息分散到系统的各个角落的方式，配置中心采用中心化统一的配置方式，降低了维护多个配置文件的复杂度。

在分布式系统中动态配置中，可以避免重复重启服务，动态更改服务参数等。Nacos作为Spring 推荐的分布式调度系统其也具备配置中心的功能， Nacos配置中心，通过其client端主动定时发起与配置中心同步的pull机制，实现动态配置的的更新。

服务的数量以及配置信息的日益增多，比如各种服务器参数配置、各种数据库访问参数配置、各种环境下配置信息的不同、配置信息修改之后实时生效等等，传统的配置文件方式或者将配置信息存放于数据库中的方式已无法满足开发人员对配置管理的要求，如：

安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏
时效性：修改配置，需要重启服务才能生效
局限性：无法支持动态调整：例如日志开关、功能开关

因此，配置中心就是为了解决以上痛点而存在的功能。

XDiamond：全局配置中心，存储应用的配置项，解决配置混乱分散的问题。名字来源于淘宝的开源项目diamond，前面加上一个字母X以示区别。
QConf：奇虎 360 内部分布式配置管理工具。用来替代传统的配置文件，使得配置信息和程序代码分离，同时配置变化能够实时同步到客户端，而且保证用户高效读取配置，这使的工程师从琐碎的配置修改、代码提交、配置上线流程中解放出来，极大地简化了配置管理工作。
Disconf：百度的分布式配置管理平台，专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」，但目前已停止维护。
Spring Cloud Config：Spring Cloud生态中为分布式系统中的外部配置提供服务器和客户端支持的组件。
ConfigKeeper ：由随行付架构部基于Spring Cloud研发的分布式配置中心，自带版本管理功能，能自动生成版本号以及回退功能。
Apollo：是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
Nacos：阿里开源的配置中心，还可以做DNS和RPC的服务发现。

Apollo、Spring Cloud Config与ConfigKeeperd的对比

功能点ApolloSpring Cloud ConfigConfigKeeper配置界面一个界面管理不同环境、不同集群配置无，需要通过git操作配置信息落入数据库中，友好页面管理配置生效时间实时重启生效或者手动refresh生效实时推送、重启生效、手动refresh生效版本管理界面上直接提供发布历史和回滚按钮无，需要通过git操作管理页面一键回滚灰度发布支持不支持支持，与Spring Cloud其他组件打通授权、审核、审计界面上直接支持，而且支持修改、发布权限分离需要通过git仓库设置，且不支持修改、发布权限分离应用分配制权限管理实例配置监控可以方便的看到当前哪些客户端在使用哪些配置不支持心跳推送，一目了然配置获取性能快，通过数据库访问，还有缓存支持较慢，需要从git clone repository，然后从文件系统读取本地式缓存文件，配置增量推送客户端支持原生支持所有Java和.Net应用支持Spring应用，提供annotation获取配置Spring、Spring Boot、Spring Cloud支持YAML格式不支持支持支持

主流配置中心性能对比

讯享网

说明

压测环境：Nacos和Apollo使用同样的数据库（32C128G）部署Server服务的机器使用的8C16G配置的容器，磁盘是100G SSD。
Spring Cloud Config使用2.0.0.M9版本，Apollo使用1.2.0 release版本，Nacos使用0.5版本。
Spring Cloud Config 依赖git，使用局限性较大。

总的来说，Apollo和Nacos相对于Spring Cloud Config的生态支持更广，在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面，不过使用起来也要麻烦一些。Nacos使用起来相对比较简洁，在对性能要求比较高的大规模场景更适合。此外，Nacos除了提供配置中心的功能，还提供了动态服务发现、服务共享与管理的功能，降低了服务化改造过程中的难度。

除了灰度发布和回滚功能(Setinel承担这部分功能)，Nacos功能都基本具备。并且，从数据来看，Nacos各项指标应该是最好的；加上与Spring Cloud Alibaba生态的搭配性，Nacos应该是作为配置中心的合理选择，另外的选择是Apollo。

在nacos配置中心中有两个概念：分别是命名空间和DataId，下面进行解释：

命名中心

　命名空间可以类似于我们配置maven时的不同profiles，即可以用来区分不同的环境。当我们需要针对不同的环境进行不同的配置时就可以用到这个功能了。

DataId

作用：DataId即配置文件的名称。默认情况下，nacos会根据命名规则，在我们的代码工程中获取几个参数来拼接成DataId，然后再用DataId去nacos中找到相应的配置来进行读取。

拼接公式： {spring.profiles.active}.${spring.cloud.nacos.config.file-extension}

1.prefix默认为spring.application.name的值，也可以通过spring.cloud.nacos.config.prefix来自定义配置；

2.spring.profiles.active一般命名dev、prd、test分别为：开发、生产、测试环境配置；

3.我们除application.properties外，还可以根据命名约定（命名格式：application-{profile}.properties）来配置，如果active赋予的参数没有与使用该命名约定格式文件相匹配的话，app则会默认从名为application-default.properties 的配置文件加载配置。项目会先从application-dev.properties加载配置，再从application.properties配置文件加载配置；

4.配置文件加载顺序：bootstrap.yml > {spring.application.name}.yml > application.yml

5.这里值得注意的是，bootstrap.yml也是Spring Boot的配置文件，且它的加载优先级会高于application.yml。我们启动工程代码时就需要先去nacos读取公用的配置，再进行工程的个性化初始化，所以nacos信息一般都是配置在bootstrap.yml上的。

PS： 如果没有配置spring.profiles.active时，则会改为{spring.cloud.nacos.config.file-extension}，我们最好还是主动声明spring.profiles.active。

在集成nacos config首先需要明白一个原理：那就是nacos怎么做到读取多个服务的配置文件，并且实现动态更新的呢？

这是因为需要动态更新的配置文件信息是直接由nacos管理的(相当于区别于spring的另一套配置文件管理系统)，并且持久化到nacos信息存储的mysql数据库中，因此与本地无关；

并且客户端会定时对比nacos服务器的配置信息，从而实现动态更新的功能。另外，nacos配置中心的主要功能其实是动态更新配置信息，但是需要在开发环境中可能无注册中心服务器，因此不需要动态更新配置的功能的话可以不用配置中心。

项目本地配置文件的功能分类：

bootstrap-{profile} ：主要存放 nacos 的环境信息，不同环境下的nacos服务器地址可能不同。
bootstrap ：存放 nacos 与环境无关的基础信息，如 shared-configs[n]、extension-configs 等，以及服务名称、端口号等。
application-{profile} ：主要用于开发环境的配置，本地开发时有些参数不希望直接改公共的 nacos，可以在配置文件中修改。
application ：本地开发时，存放与环境无关的基础信息。

常用的做法，就是项目工程中不存放 application 相关的配置文件，只保留文件。不同环境下的配置文件是完全通过不同的nacos服务器或namespace来区分的

创建service-config-nacos子模块：

讯享网

编写主启动类：

讯享网

这里值得注意的是，bootstrap.yml也是Spring Boot的配置文件，且它的加载优先级会高于application.yml。我们启动工程代码时需要先去nacos读取公用的配置，再进行工程的个性化初始化，所以nacos信息一般都是配置在bootstrap.yml上的。

nacos配置中心读取不到application.yml，因此我们需要创建优先级更高的bootstrap.yml

添加配置文件bootstrap.yml，主要是对Nacos的作为配置中心的功能进行配置：

namespace的设计是nacos基于此做多环境以及多租户（多个用户共同使用nacos）数据(配置和服务)隔离的。

注意：当为空时，对应的连接符也将不存在，的拼接格式变成。因此，下面创建在Nacos服务器的dataId应该为nacos-config-client.yaml。

当然，我们也可以在本地创建application.yml配置文件指定开发环境的配置文件：

讯享网

这是没有开启namespace配置时，由本地声明启用特定开发环境的配置文件的方式。

注意：本地与远程配置中心最好不要混用，易出错。

如果用不到动态刷新配置功能，建议不要引入nacos配置中心依赖，直接使用项目本地的配置进行读取；

因为，读取nacos服务器的配置，依旧有一定的网络风险；如果是要求风险小但要动态刷新配置的项目，建议本地application.yml配置所有固定的配置项，只将动态更新的配置项放到nacos服务器。

配置中心模式时远程配置的优先级默认高于本地配置，因此读取的配置其实与本地无关。

这里dataId的命名有严格的规则

打开Nacos控制台地址：http://localhost:8848/nacos/#/configurationManagement?dataId=&group=&appName=&namespace=&pageSize=&pageNo=&serverId=

然后创建一份public配置(公共配置)，添加相关参数到配置文件中：

Data ID命名规则：{spring.profiles.active}.${spring.cloud.nacos.config.file-extension}，例如：nacos-config-client-dev.yaml

因此：nacos配置信息一般配置在本地的bootstrap.yml中，优先级最高；开发、测试、生产环境的配置文件通过nacos服务器的namespace来区分(不要本地远程两种配置中心混用)，这种方式相当于除nacos配置文件外抛弃了本地配置中心，完全托管给nacos管理配置文件。

点击发布，我们就成功创建了一份可以被动态刷新配置的配置文件，数据持久化在nacos连接的mysql数据库中。

查看nacos_config数据库，发现config_info表中以及有了配置文件数据：

因为默认的配置文件的命名空间就是public，没有命名空间ID值，因此无需在bootstrap.yml配置文件中声明namespace的值。

既然配置中心数据已经成功写入到了nacos服务器，下面我们测试读取nacos配置中心中默认配置文件的配置项的值并且测试动态刷新配置功能。

创建NacosConfigController，使用 @RefreshScope注解开启动态刷新配置功能：

nacos的动态刷新配置功能：是指修改nacos服务器的配置文件后，不用重启nacos服务端和客户端就能完成客户端读取配置项值的更新。

讯享网

同样，点击"▶"启动子模块项目：

成功运行子模块项目后，使用curl或postman测试配置项读取接口：

配置项读取测试成功，下面去nacos控制台更改配置项的值，然后再次测试配置项读取接口：

编辑修改配置文件，然后点击并确认发布修改后的配置文件：

不用重启nacos服务器，也不用重启nacos客户端服务，再次调用配置项读取接口，可以看到配置已经发生改变了：

讯享网

在dev、prd或test等不用的环境需要启用的配置也不相同，因此为了避免不同环境下的配置发生冲突，需要进行多环境配置。

使用规则和spring的配置文件配置相同，通过声明spring.profile.active参数来指定不同环境下的启用配置文件。

默认配置文件还是生效的，只有遇到启动的配置文件与默认配置文件中K-V冲突时，才会优先启用环境下的配置文件。

几种方式的比较

通过Data ID与profile实现

优点：这种方式与Spring Cloud Config的实现类似，命名规则类似。缺点：这种方式在项目与环境多的时候，配置内容会显得非常混乱。配置列表中会看到各种不同应用，不同环境的配置交织在一起，非常不利于管理。建议：项目不多时使用，或者可以结合Group对项目根据业务或者组织架构做一些拆分规划

通过Group实现

优点：通过Group按环境将各个应用的配置隔离。可以非常方便地利用Data ID和Group的搜索功能，分别从应用纬度和环境纬度来查看配置。缺点：由于会占用Group纬度，所以需要对Group的使用做好规划，毕竟业务上的一些配置分组起冲突等问题。建议：这种方式虽然结构上比上一种更好一些，但是依然可能会有一些混乱，主要是在Group的管理上要做好规划和控制。