未来的开发场景

我们在创建项目的时候，为每个项目都配置了一个或者多个配置文件。通过修改配置文件中的参数我们可以创建出不同的服务环境。

• 首先，服务拆分越多，配置项也就越多。而一旦有某项服务进行了调整，其他服务也需要相应调整。如果配置项都在每个项目的配置文件中配置，那么可想而知，只要一有改变，就得改配置文件，重新部署项目。

  • 比如：假如说3个微服务中关于数据库的配置项是完全一样的，倘若某天MySQL数据库迁移了，那么这3个微服务的配置文件也要全部修改；

• 当修改了配置之后，必须重启服务，否则配置无法生效；

• 其次，运维安全。如果我们将一些数据库信息直接配置在配置文件中，那么对于运维的同学来说，显然带来了更大的挑战与风险。因为项目极有可能是多人协作开发，而多人都可以直接连接数据库将会具有不小的风险（删库跑路了解一下）

为什么需要配置中心

配置实时生效

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

配置管理流程

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

开源配置中心基本介绍

Disconf

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

Spring Cloud Config

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

Apollo

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

Nacos

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

Spring Cloud Config

介绍

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

• Spring Cloud Config 是一个解决分布式系统的配置管理方案的项目。它包含了 Client 和 Server 两个部分，Server 端提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client 端通过接口获取数据、并依据此数据初始化自己的应用。

• Spring Cloud Config 是一个基于 http 协议的远程配置实现方式，通过统一的配置管理服务器进行配置管理，客户端通过 https 协议主动的拉取服务的的配置信息，完成配置获取

• 分布式环境中，很多的服务都是集群部署，那就意味着这些集群部署的服务都需要相同的配置文件。所以，这时候就引入了 Spring Cloud Config 这个组件，使用该组件来进行众多的配置文件的统一管理。

配置管理工具

• 本地存储
• Subversion
• Git

体系

1. Config Server
2. Config Client

案例

需求

• 在Git仓库中创建分支
• 在指定分支下创建文件夹
• 在第2步创建文件夹下创建配置文件
• 在配置文件中填充配置数据信息
• 通过Config Server获取线上Git仓库中的配置信息
• 通过Config Client从Config Server获取配置信息

编写 Config Server

1.创建配置文件

• 在码云/GitEE中创建项目env-project

• 在env-project项目中创建dev分支

• 在dev分支下创建config-file文件夹

• 在config-file下创建文件client-dev.properties

• 在client-dev.properties填入以下内容

  eureka.port=19015
  spring.dataSource.username=root
  

  

2.创建项目

指定artifactId为demo-config-server

3.添加依赖

        <dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-config-server</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency>

4.添加注解

• @EnableConfigServer
• @EnableDiscoveryClient

@SpringBootApplication
@EnableDiscoveryClient
@EnableConfigServer
public class DemoConfigServerApplication {public static void main(String[] args) {SpringApplication.run(DemoConfigServerApplication.class, args);}}

5.修改配置文件

application.yml

server:port: 7600
spring:application:name: demo-config-servercloud:config:server:git:uri: https://gitee.com/xxxxxx/env_project.git # 刚才创建的gitee位置search-paths: config-file
eureka:client:service-url:defaultZone: http:192.168.2.220:7776/eureka

映射规则解析

• /client/dev/dev，即：/{application}/{profile}/{label}
  • {application}：Git仓库中文件名的前缀, 通常使用微服务名称
  • {profile}：{application}-后面的数值
    • 在同一个分支下可以有多个{application}名称相同的文件
  • {label}：Git仓库的分支名，默认为master

6.启动服务

7.访问端点

访问：http://localhost:7900/client/dev/dev，确保能够读取到gitee上的内容

8.为Config Client准备配置环境

在gitee上刚才的仓库的dev分支下创建配置文件：demo-gateway-dev.properties，内容如下：

eureka.port=18080

编写 Config Client

1.给demo-gateway项目添加依赖

        <dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-config</artifactId></dependency>

2.创建配置文件

bootstrap.yml

在demo-gateway项目中创建文件 bootstrap.yml，内容如下：

spring:application:name: demo-gatewaycloud:config:uri: http://localhost:7600label: devprofile: dev
eureka:client:service-url:defaultZone: http://192.168.2.220:7776/eureka

这里为什么{profile}和{label}都指定了，不用指定{application}，因为sprng.application.name就是{application}

application.yml

server:port: 7900

3.获取配置

@RestController
public class InfoController {@Value("${eureka.port}")private String port;@GetMapping("/port")public String getPort(){return "配置文件中的端口为："+this.port;}
}

4.验证测试

访问地址：http://localhost:8085/port

加密解密

• 数据在配置文件中明文保存，有安全隐患
• 数据存储加密，使用时解密
  • Spring Cloud Config
  • JCE
    • JRE中自带
    • 默认有长度限制
    • 可以安装不限制长度版本

开启加密

启动Config Server

访问路径：

• /encrypt/status：查看加密功能状态的端点
• /key：查看密钥的端点
• /encrypt：对请求的Body内容进行加密的端点
• /decrypt：对请求的Body内容进行解密的端点

添加配置

在bootstrap.yml中添加密钥配置

encrypt:key: demo

验证

访问：http://localhost:7900/encrypt/status

发送加密请求

• 请求地址：http://localhost:7900/encrypt
• POST请求
  需加密的内容通过请求体发送
  

发送解密请求

• 请求地址：http://localhost:7900/decrypt
• POST请求
• 密文通过请求体发送
  

存储和解析加密数据

1.添加配置

• 在demo-gateway-dev.properties中添加加密后的配置

eureka.port={cipher} bfa028c0a382074d58bb315b00f5ffde4660d7e92977fe223cac2f9e430b1a9c

• {cipher}代表当前数据为加密值

• 配置文件如果是yml文件，tokenValidation的值必须加单引号，如果是properties文件，则不能有单引号，否则不能正常解析

• 即使是相同的值，每次加密后的结果也可能不一样，以实际加密结果为准

2.代码解析加密

在demo-gateway项目解析加密数据

@RestController
public class InfoController {@Value("${eureka.port}")private String port;@GetMapping("/port")public String getPort() {return "配置文件中的端口为：" + this.port;}
}

思维导图

补充：bootstrap.yml和application.yml的区别

大家都知道，SpringBoot默认支持properties(.properties)和YAML(.yml .yaml )两种格式的配置文件。

加载顺序

1. 若application.yml 和bootStrap.yml 在同一目录下 :bootstrap.yml先加载 application.yml后加载。

2. bootstrap.yml 用于应用程序上下文的引导阶段。bootstrap.yml 由父Spring ApplicationContext加载。

3. 父ApplicationContext 被加载到使用 application.yml 的之前。

如果resource里面同时有application.properties 和 application.yml，且存在相同的配置，则application.properties会覆盖application.yml里面的属性，因为application.properties 会后加载，也就是说哪个文件被最后加载，哪个才具有最高级。（application会覆盖bootstrap中的非引导配置）

配置区别

1. bootstrap.yml 和application.yml 都可以用来配置参数。

2. bootstrap.yml 用来程序引导时执行，应用于更加早期配置信息读取. 可以理解成系统级别的一些参数配置，这些参数一般是不会变动的。

3. application.yml 可以用来定义应用级别的， 应用程序特有配置信息，可以用来配置后续各个模块中需使用的公共参数等.如果加载的application.yml的内容标签与bootstrap的标签一致，application会覆盖bootstrap, 而application.yml 里面的内容可以动态替换。

典型的应用场景如下：

1. 当使用 Spring Cloud Config Server 的时候，你应该在 bootstrap.yml 里面指定 spring.application.name 和 spring.cloud.config.server.git.uri
2. 和一些加密/解密的信息

为何需要把 config server 的信息放在 bootstrap.yml 里？

• 当使用 Spring Cloud 的时候，配置信息一般是从 config server 加载的，为了取得配置信息（比如密码等），你需要一些提早的或引导配置。因此，把 config server 信息放在 bootstrap.yml，用来加载真正需要的配置信息。

• 当然，在一些情况上不用那么区分这两个文件，你只需要使用application文件即可，把全部选项都写在这里，效果基本是一致的，在不考虑上面的加载顺序覆盖的问题上。