参考

SC接入 配置中心简单版本
http://www.ityouknow.com/springcloud/2017/05/22/springcloud-config-git.html

SC接入配置中心 Eureka注册Server
http://www.ityouknow.com/springcloud/2017/05/25/springcloud-config-eureka.html

自己的一个demo源码（配置中心server + 配置中心 client +EurekaServer)
https://github.com/huangzhenshi/eureka2.x_auth_demo

配置中心要解决的问题

1. 集中管理多个微服务项目的配置文件（查看、修改、通知客户端)

2. 配置文件的分层

• 按照环境分层： Test/Dev/Uat
• 按照业务分层： 内部集成 / 外部基础 / 微信相关

3. 安全性：因为有所有项目的配置，虽然运维管理很方便，但是安全性就很重要（比方说 某个项目只允许某某人修改，谁都能改而且没有修改脚印的话，都没法追溯了 、设置只读账户）

• 权限控制（比如 配置仓库 可以做权限控制 （代码仓库天生的 支持只读模式、修改模式），配置仓库可以设置访问密码 + 用户授权)
• 敏感信息加密（数据库的账号密码 不要使用明文)

4. 易用性：

• 集成和使用要方便简洁：比如Springcloud config可以使用注册中心

5. 其它

• 支持集群

SpringCloud config反思

1. 设计的理念特别好，安全性的问题，没有重复造轮子，而是交给了天生就是擅长做这件事的 代码仓库（权限控制、修改历史和修改人），而不是像nacos一样，自己全包了。
2. 安全性上对于代码仓库的不足，比如敏感信息的加密解密，自己扩展了这一方面的功能。

作用

1. 多个微服务的不同环境的配置文件都放在一个git里面，方面管理分散的配置文件。（也可以按照 dev、test、uat、product分为4个git配置项目)
2. 多个微服务公用相同的配置，这样方便管理（统一修改)（也就是一个项目可以同时引入多个 配置文件，比如自己项目的配置文件+多项目统一的配置文件)
3. 结合 actuator（或者bus） 可以实现配置文件的热加载 /refresh ，不需要重启应用就可以加载最新的配置
4. 因为也支持url的形式，所以简单的springboot项目也可以使用配置中心的功能。

项目依赖

• 配置文件仓库：代码托管的项目（github、gitlab、svn、也支持本地文件存储 都可以)，用来保存不同项目（不同profile）的配置文件
• server端：springCloud配置中心的server项目：client通过API调用server端，间接读取代码托管里面的配置。server端的作用暂时还不清楚，有待研究
• client端：通过调用server端，获取到对应profile的配置文件

配置文件仓库

config-repo/
            -- neo-config-dev.properties
            -- neo-config-pro.properties
            -- neo-config-test.properties

配置 server端 指定 searchPath

spring:
  application:
    name: spring-cloud-config-server
  cloud:
    config:
      server:
        git:
          uri: https://github.com/huangzhenshi/config-test/     # 配置git仓库的地址
          search-paths: config-repo    

配置文件的搜索逻辑

先通过eureka找到 config.server，再在 search-paths里面遍历 config.name-config.profile.properties文件

精简的客户端的配置

spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.serviceId=spring-cloud-config-server
eureka.client.serviceUrl.defaultZone=http://huangzs:123456@localhost:8762/eureka/
spring.application.name=spring-cloud-config-client
server.port=8002
spring.profiles.active=test

注意事项：

1. 配置文件修改之后，server端是动态获取的，所以配置的修改对server端是立即生效的。但是client端只有在启动的时候，才会调用server端，启动之后就算配置文件变更了，也不会感知到。

2. 可以通过server端的url直接获取到配置文件信息

仓库中的配置文件会被转换成web接口，访问可以参照以下的规则（lable指的是 配置文件的分支名称）：

/{application}/{profile}[/{label}]
/{application}-{profile}.yml
/{label}/{application}-{profile}.yml
/{application}-{profile}.properties
/{label}/{application}-{profile}.properties

以neo-config-dev.properties为例子，它的application是neo-config，profile是dev。client会根据填写的参数来选择读取对应的配置。

http://localhost:8001/neo-config/test
http://localhost:8001/neo-config-test.properties
http://localhost:8001/neo-config-test.yml
http://localhost:8001/master/neo-config-test.yml

3. 上面这些与spring-cloud相关的属性必须配置在bootstrap.properties（bootstrap.yml）中，config部分内容才能被正确加载。
   因为config的相关配置会先于application.properties，而bootstrap.properties的加载也是先于application.properties。

spring.cloud.config.name=neo-config
spring.cloud.config.profile=dev
spring.cloud.config.label=master
spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.serviceId=spring-cloud-config-server

4. 其它细节

• label可以不配置默认就是master
• spring.cloud.config.name可以不配置，默认就是取spring.application.name
• spring.cloud.config.profile可以不配置，默认就是取spring.profiles.active=test

5. 加载顺序
   bootstrap.properties 第一个加载 ， 然后再是 本地的application.properties ，最后是远程的配置。所以如果本地配置了一个属性，远程配置中心也配置了，会被配置中心所覆盖
   注意是在远程的配置文件中添加，在本地添加没有用的

#不覆盖本地配置文件
spring.cloud.config.override-none=true

6. 引入多个配置文件,直接在 config.name 用逗号拼接

spring.cloud.config.name=spring-cloud-config-client,common-config

敏感信息加密解密

比如数据库的相关信息，或者其它的比较敏感的信息，可以集成 encrypt功能

原生Config 和 nacos

简单的项目，对安全性要求不高的话，nacos是个不错的选择，毕竟后来者，有一些特性还是很棒的，比如web界面、动态更新属性无需重启、还兼具注册中心的功能
但是从远期来看，特别是安全性上来看，原生的config才是Prod 大规模级别、规范的配置中心

典型的使用场景

• 可以gitlab上创建一个 config的 项目group，按照环境不同区分项目，然后项目里面根据业务类型划分多个文件夹（search paths)
• 使用加密，对数据库的用户名和密码进行加密解密