1为什么需要配置中心

配置实时生效：

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

配置管理流程：

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

2开源配置中心基本介绍

目前市面上用的比较多的配置中心有：（按开源时间排序）

Disconf

2014年7月百度开源的配置管理中心，同样具备配置的管理能力，不过目前已经不维护了，最近的一次提交是两年前了。

Spring Cloud Config

2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。

Apollo

2016年5月，携程开源的配置管理中心，具备规范的权限、流程治理等特性。

Nacos

2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。

3配置中心核心概念的对比

由于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。

4配置管理功能的对比

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

灰度发布

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

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控制台和后端配置服务是部署在一起的，可以通过不同的域名切换来支持多集群。 

5配置实时推送的对比

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

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，链路较长，比较复杂。

6部署结构 & 高可用的对比

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生产高可用的成本最高。

7多语言支持的对比

一个公司的各个系统可能语言不尽相同，现在使用的比较多的比如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，存在代码改造和兼容性成本。

8性能对比

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

硬件环境

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。

9功能特性对比总结

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

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

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

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

目前公司内部微服务架构基础设施建设中，技术选型以Spring Cloud技术为主，也被大家俗称作“全家桶”。

★

因其具备微服务架构体系中所需的各个服务组件，比如服务注册发现(如Spring Cloud Eureka、Zookeeper、Consul)、API网关路由服务(Spring Cloud Zuul)，客户端负载均衡(Spring Cloud Ribbon，Zuul默认集成了Ribbon)、服务容错保护(Spring Cloud Hystrix)，消息总线 (Spring Cloud Bus)、分布式配置中心(Spring Cloud Config)、消息驱动的微服务(Spring Cloud Stream)、分布式链路跟踪服务(Spring Cloud Sleuth)。

”

本篇主要围绕其中一个组件 分布式配置中心 展开讨论。

Spring Cloud Config配置中心介绍&架构

在微服务架构体系中配置中心是比较重要的组件之一，Spring Cloud官方自身提供了Spring Cloud Config分布式配置中心，由它来提供集中化的外部配置支持，它分为客户端和服务端两个部分。

其中服务端称作配置中心，是一个独立的微服务应用，用来连接仓库(如Git、Svn)并未客户端提供获取配置的接口；而客户端是各微服务应用，通过指定配置中心地址从远端获取配置内容，启动时加载配置信息到应用上下文中。

因Spring Cloud Config实现的配置中心默认采用了Git来存储配置信息，所以版本控制管理也是基于Git仓库本身的特性来支持的 。
对该组件调研后，主要采用基于消息总线的架构方式，架构图如下所示：

基于消息总线的配置中心架构中需要依赖外部的MQ组件，如Rabbit、Kafka 实现远程环境事件变更通知，客户端实时配置变更可以基于Git Hook功能实现。

同时架构图中看到最右侧，有一个Self scheduleing refresher 这个是我在实践中自己新增的一个扩展功能，目的是当依赖的消息组件出现问题时，此时如果Git仓库配置发生了变更，会导致部分或所有客户端可能无法获取到最新配置，这样就造成了客户端应用配置数据无法达到最终一致性，进而引起线上问题。

★

Self scheduleing refresher 是一个定时任务，默认5分钟执行一次，执行时会判断本地的Git仓库版本与远程Git仓库版本如果不一致，则会从配置中心获取最新配置进行加载，保障了配置最终一致性。

”

经过实际使用你会发现Spring Cloud Config这个配置中心并不是非常好用，如果是小规模的项目可以使用问题不大，但它并不适用于中大型的企业级的配置管理。

因此，我对业界开源的配置中心做个对比后最终选择了携程开源的Apollo配置中心解决了微服务架构配置管理和其他项目中配置管理痛点。

下面就针对Spring Cloud Config和Apollo配置中心做个更加直观的比对：

Apollo VS Spring Cloud Config

通过以上对比图发现Spring Cloud Config缺陷还是挺大的，比如最后一条高可用，Apollo配置中心客户端应用加载配置后本地会生成缓存文件，即使配置中心所有的服务都挂掉，只是配置无法更新，但是不影响你的服务启动。

而这Spring Cloud Config是无法做到的，有人会说我们可以在应用classpath下添加应用配置文件作为「兜底使用」，这样做首先配置不会自动同步，而且也不是Spring Cloud Config自身的功能。

另外还有一个原因是因为现阶段项目中也使用了一些自研的配置中心，但都差强人意，有的配置中心仅支持xml格式的，无法支持KV形式；还有的配置中心是基于JMX开发的，但只支持属性配置推送。

所以经过对Apollo配置中心的调研和使用发现这款产品不仅适用于微服务配置管理场景，同时也支持多种配置格式，如xml、json、yml，还支持多语言客户端的接入，在配置服务治理方面也是很完善的，在携程内部已经支撑10万+的实例运行，成熟又稳定！

开源配置中心对比

下面这个图详细的开源配置中心对比图：

在上述几个开源配置中心里，Apollo社区是非常活跃的，不断更新迭代。

在Apollo出现之前百度开源的disconf配置中心使用的更多些，disconf最新代码更新时间还是2年前的，且与Apollo的对比社区活跃度有所下降。

Apollo配置中心介绍&架构

Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

服务端基于Spring Boot和Spring Cloud开发，不依赖外部容器，便于部署。

Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有额外支持。

原生支持Java和.Net客户端，同时也支持其他语言客户端，目前已支持Go、PHP、Python、NodeJS、C++。

主要功能特性：

• 统一管理不同环境、不同集群的配置

• 配置修改实时生效（热发布）

• 版本发布管理

• 灰度发布

• 权限管理、发布审核、操作审计

• 客户端配置信息监控

• 提供Java和.Net原生客户端

• 提供开放平台API

• 部署简单，依赖少

Apollo总体架构设计：

各组件作用说明：

Apollo HA高可用设计：

Apollo客户端架构：

客户端架构原理：

1.推拉结合方式

• 客户端与配置中心保持一个长连接，配置实时推送

• 定时拉配置(默认5分钟)

2.本地缓存

• 配置缓存在内存

• 本地缓存一份配置文件

3.应用程序

• 通过Apollo客户端获取最新配置

• 订阅配置更新通知

Apollo核心概念：

application (应用)

每个应用都需要有唯一的身份标识 -- appId

environment (环境)

Apollo客户端通过不同环境获取对应配置

cluster (集群)

一个应用下不同实例的分组，不同的cluster，可以有不同的配置。

比如北京机房和天津机房可以有不一样的kafka或zk地址配置。

namespace (命名空间)

一个应用下不同配置的分组，不同的namespace的类似于不同的文件。

如：数据库配置，RPC配置等。支持继承公共组件的配置。

配置分类

• 私有类型（private）：只能被所属应用获取

• 公共类型（public）：必须全局唯一。使用场景：部门/小组级别共享配置，中间件客户端配置。
  关联类型（继承类型）：私有继承公有配置并覆盖；定制公共组件配置场景。

配置项(Item)

默认和公共配置使用properties格式；私有配置支持properties/json/xml/yaml/yml格式。
定位方式：app+cluster+namespace+item_key

权限管理

• 系统管理员拥有所有的权限

• 创建者可以代为创建项目，责任人默认是项目管理员，一般创建者=责任人

• 项目管理员可创建集群，Namespace，管理项目和Namespace权限

• 编辑权限只能编辑不能发布

• 发布权限只能发布不能编辑

• 普通用户可以搜索查看所有项目配置，但没有相关操作权限

Apollo配置中使用及扩展

使用Apollo配置中心后，做了进一步的功能开发扩展，接入公司的SSO和邮件通知接入。

基于Spring Cloud Config微服务架构体系中，如果之前使用了Spring Cloud Config配置中心，也可以通过下列方式平滑的迁移到Apollo配置中心。

Spring Cloud微服务项目在pom.xml中引入如下依赖：

1.  
   <dependency>
2.  
        <groupId>com.letv.micro.apollo</groupId>
3.  
       <artifactId>micro-apollo-spring-boot-starter</artifactId>
4.  
       <version>1.0-SNAPSHOT</version>
5.  
   </dependency>

该源码参考Github：

★

https://github.com/david1228/micro-apollo-spring-boot-starter

”

需要自行编译打成jar包使用。

这个jar包对Spring Cloud配置刷新机制集成Apollo客户端做了进一步封装，实现的主要功能如下：

1、在Apollo配置中心发布配置后，微服务应用客户端监听配置变更，包括默认的配置和公共的配置，通过ContextRefresher中的refresh()方法完成应用环境上下文的配置刷新。

2、支持对日志级别和日志路径文件的动态配置变更。[Apollo Client无法很好的支持日志级别和日志路径文件的变更，因日志的LoggingApplicationListener加载优先级高，Apollo配置加载滞后。

上述jar包已上传公司的Maven私服。具体配置使用示例可以参考「4.Apollo配置中心使用示例」

引入micro-apollo-spring-boot-starter之后，可以将spring-cloud-stater-config依赖从pom.xml中去掉了。

Apollo配置中心公共配置命名规范:

公共配置建议统一放到新创建的项目中，该项目中存放Spring Cloud相关的公共组件的配置，比如Eureka、Zipkin、Stream等配置，比如Eureka地址可能是多个微服务应用共用的，便于在该项目中统一对配置进行管理。

创建项目时，选择的部门如为「微服务公共平台(dpms)」

各微服务应用项目创建后可以添加Namespace，选择关联公共配置。

公共配置命名规则：{部门前缀}.application  或者 {部门前缀}.application-{具体的细分配置}

当Apollo配置发布后，若需让Spring Cloud配置实现动态加载，公共配置命名必须以application关键字开头，在上述依赖的jar包中会对这类命名的Namespace做配置变更监听。

例如：

• dpms.application-eureka 存放eureka相关配置

• 或 dpms.application-zipkin 存放zipkin相关配置

• 或 dpms.application  存放Spring Cloud所有的公共相关配置

• 其他微服务应用关联公共配置后，默认使用的公共配置项。

• 你也可以对公共配置所有参数做覆盖，覆盖后优先获取本项目中的配置，这个特性在Apolo的公共配置界面能够直观的展示出来。

以上就是对为什么要选择Apollo配置中心的一些介绍，相信你的项目中可能也遇到了类似的配置管理问题或痛点，强烈建议使用Apollo配置中心作为你的配置管理基础服务使用。

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
    </dependencies>
复制代码

@SpringBootApplication
@EnableConfigServer
public class ConfigServerGitApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigServerGitApplication.class, args);
    }
}
复制代码

server:
  port: 8094

spring:
  cloud:
    config:
      server:
        git:
          # git 服务器地址
          uri: https://github.com/chuli/spring-cloud-config.git
          # git 用户名
          username:
          # git 密码
          password:
          # 搜索该目录下所有满足条件的配置文件，可以添加多个目录，用逗号分隔
          search-paths: SC-DEMO-CONFIG

  application:
    name: git-config-server
复制代码

com:
  kk:
    demo:
      config: [test] this is git config demo
复制代码

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-client</artifactId>
        </dependency>
    </dependencies>
复制代码

@SpringBootApplication
public class GitConfigClientApplication {

    public static void main(String[] args) {
        SpringApplication.run(GitConfigClientApplication.class, args);
    }
}
复制代码

@RefreshScope
@Component
public class ConfigInfoProperties {

    @Value("${com.kk.demo.config}")
    private String config;

    public String getConfig() {
        return config;
    }
}
复制代码

@RefreshScope
@RestController
@RequestMapping("config")
public class ConfigClientController {

    @Autowired
    private ConfigInfoProperties configInfoProperties;

    @RequestMapping("/getConfigInfo")
    public String configInfoAction() {
        return configInfoProperties.getConfig();
    }
}
复制代码

spring:
  cloud:
    config:
      # 请求的具体分支，该demo使用master
      label: master
      # config server的地址
      uri: http://localhost:8094
      # 远程的具体配置文件，可以写多个，通过逗号隔开，
      # 该demo使用 https://github.com/chuli/spring-cloud-config/SC-DEMO-CONFIG/config-info-xx.yml
      name: config-info
      # 使用哪个环境的配置，如dev、test、stage、prod
      profile: dev
复制代码

server:
  port: 8095

spring:
  application:
    name: git-config-client

management:
  endpoints:
    web:
      exposure:
        include: '*'
      # 包含所有端点的信息，默认只打开info、health的端点
  endpoint:
    health:
      # 总是显示详细的信息
      show-details: always
复制代码