- 在前一篇博客中,我们分别创建了两个子model:springcould-config-server-3344和springcould-config-client-3355用来作为spring cloud config分布式配置中心的服务端和客户端,我们已经实现了通过服务端连接远程仓库,通过客户端连接服务端实现读取远程仓库中配置文件的功能
- 但是在实际的开发中,我们应该将我们编写的服务提供者、消费者和注册中心的配置放在远程仓库,并将它们作为config的客户端去访问远程仓库中的配置文件,这样就实现了配置和编码的解耦,所以这一篇博客要做的就是对原来我们写的微服务模块进行改造,将它们的配置文件放在远程仓库,而不是模块中
1.注册中心和服务提供者的配置文件改造
- 首先去本地仓库中创建一个eureka注册中心的配置文件
spring: profiles: active: dev --- spring: profiles: dev application: name: springcloud-config-eureka server: port: 7001 #eureka配置 eureka: instance: hostname: eureka7001.com #eureka server运行的主机名,所以访问eureka监控页面的url为http://localhost:7001/ client: register-with-eureka: false #表示是否向eureka注册中心注册自己,但是由于这个子model本来就是用来充当eureka服务器/注册中心的,所以设置为false #这个属性设为false同时也就表明了这个微服务是eureka服务器程序 fetch-registry: false #fetch-registry为false表示这个微服务为eureka注册中心 service-url: #单机:defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #集群(关联/挂载 其他的注册中心的url): defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/ #微服务提供者向注册中心的注册服务的地址,它有默认的url,为"http://localhost:8761/eureka/" #但是我们自己配置了eureka运行的主机名和端口号,所以我们在配置的时候不会将配置写死,而是获取上面我们的配置,这样后面更改的时候就只需要更改上面的显式配置,而不需要更改引用处的值 --- spring: profiles: dev application: name: springcloud-config-eureka server: port: 7001 eureka: instance: hostname: eureka7001.com client: register-with-eureka: false fetch-registry: false service-url: defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/ ```
- 再写一个服务提供者的配置文件
spring: profiles: active: dev --- server: port: 8001 #端口号 #mybatis配置 mybatis: type-aliases-package: com.thhh.springcould.pojo #mybatis的别名扫描 mapper-locations: classpath:mybatis/mapper/*.xml #mybatis去哪里读取pojo对应的mapper接口的mapper.xml文件 config-location: classpath:mybatis/mybatis-config.xml #mybatis核心配置文件,可要可不要,不要就把配置写在spring配置中 #spring配置 spring: profiles: dev application: name: springcould-config-provider-dept datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.jdbc.Driver url: jdbc:mysql://localhost:3306/db01?useSSL=false&useUnicode=true&characterEncoding=utf-8 username: root password: 123 #eureka的配置 eureka: client: service-url: defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/ instance: instance-id: springcould-provider-dept-8001 #配置注册的服务的描述信息 prefer-ip-address: true #完善监控信息展示 info: app.name: dept服务者1 #服务的名称 company.name: com.thhh --- server: port: 8001 #端口号 #mybatis配置 mybatis: type-aliases-package: com.thhh.springcould.pojo #mybatis的别名扫描 mapper-locations: classpath:mybatis/mapper/*.xml #mybatis去哪里读取pojo对应的mapper接口的mapper.xml文件 config-location: classpath:mybatis/mybatis-config.xml #mybatis核心配置文件,可要可不要,不要就把配置写在spring配置中 #spring配置 spring: profiles: test application: name: springcould-config-provider-dept datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.jdbc.Driver url: jdbc:mysql://localhost:3306/db02?useSSL=false&useUnicode=true&characterEncoding=utf-8 username: root password: 123 #eureka的配置 eureka: client: service-url: defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/ instance: instance-id: springcould-config-provider-dept-8001 #配置注册的服务的描述信息 prefer-ip-address: true #完善监控信息展示 info: app.name: dept服务者1 #服务的名称 company.name: com.thhh
- 注意:上面的两个配置文件看起来很多,其实我们只是去原来的模块中复制粘贴了配置文件,在每一个配置文件中,如果这个文件已经配置了spring.application.name属性,那么我们就为它多配置一个profiles属性,属性值为当前这个环境要使用的环境名称(比如dev或test等);如果没有配置spring.application.name属性,我们就给他配置上,并且连同profiles属性一起配置
#spring配置 spring: profiles: dev application: name: name属性的值
- 一个配置文件我们就通过复制粘贴并修改profiles属性,实现配置两套环境;并在文件的上方加上以下配置实现选择当前选择哪一套环境激活使用
spring: profiles: active: 要激活的环境的profiles属性的值
- 虽然看起来很多,其实就是有一套配置好的环境,下面的直接复制粘贴,并修改profiles属性值就可以变成一套新环境了,只是上面选择激活哪一套环境需要我们自己写
- 配置好了一个注册中心的两套环境的配置文件,一个服务提供者的两套环境的配置文件,我们就可以将新创建的两个配置文件push到远程仓库中去了
- 接下来就是去7001注册中心和8001服务提供者中使用远程配置文件,首先我们需要删除原来的配置文件中的内容,并创建一个bootstrap.yml配置一些系统级别的配置,主要还是配置当前这个微服务要使用远程仓库中的哪一个配置文件
- 我们需要配置name(配置文件名称)、profile(这个配置文件中的哪一个环境下的配置)、label(配置文件所在分支)、uri(config服务端的地址[IP+端口])共4个属性
- 但是为了实现原来本地配置和现在远程配置的对比,我们还是直接创建两个新的model,一个为7001注册中心使用远程仓库中的配置文件的model:springcould-config-eureka-7001,一个为8001服务提供者使用远程仓库中的配置文件的model:springcould-config-provider-dept-8001;然后将这4个model进行对应的文件拷贝
- 注意:拷贝完了之后还需要为这两个新创建的model导入config客户端的依赖
<!--config--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> <version>2.1.1.RELEASE</version> </dependency>
- 对两个新创建的model进行config客户端改造,首先改造7001,我们需要将原来application中的配置删除,因为已经在远程配置好了;然后创建一个新的配置文件bootstrap.yml
spring: cloud: config: name: config-client-eureka #配置要加载的远程仓库中配置文件的名称,注意:不要后缀 profile: dev #配置获取这个配置文件在哪一种环境下的配置 label: master #配置从哪一个分支获取配置文件 uri: http://localhost:3344 #连接config服务端
- 对应配置8001模块的配置文件
spring: cloud: config: name: config-client-Dept-Provider #配置要加载的远程仓库中配置文件的名称,注意:不要后缀 profile: dev #配置获取这个配置文件在哪一种环境下的配置 label: master #配置从哪一个分支获取配置文件 uri: http://localhost:3344 #连接config服务端
- 注意:在创建了bootstrap.yml文件之后原来的application.yml还是应该保留,它可以在公共的远程仓库读取的配置文件的配置中加上一些这个模块独特的application配置,即它可以在远程仓库的配置文件基础上增加一些配置,所以保留它还是有用处的
- 两个模块都准备好的之后就准备启动测试效果
- 注意启动顺序,先启动config服务端3344,再启动注册中心7001,最后启动服务提供者8001
- 我们还可以进一步的通过服务提供者的API消费服务进行测试
- 我们还可以直接在远程仓库上对配置文件进行在线的修改
2.小结
- 通过上面的例子我们就知道子spring cloud config分布式配置在平时开发的微服务中怎么使用了
- 我们甚至可以将所有的配置文件都变成远程托管,在编写微服务的时候直接去远程获取即可,这样做除了实现了编码和配置的解耦,也提高了配置文件的重用性,我们可以将一些公用的配置都写在远程仓库的配置文件中,而对于本微服务特别的配置就在这个微服务的配置文件中写上,这样配置文件就能简化很多重复的配置
- 在前面没有使用spring cloud config分布式配置的时候,我们都是写一个微服务就必须为它编写一个完整的配置文件,现在有了远程仓库,我们就直接从远程拿过来就使用,需要覆盖的我们可以将配置修在bootstrap.yml中,远程仓库配置文件没有的我们可以直接写在application.yml或bootstrap.yml中
- 在团队协作开发的时候一个人写好了的配置文件上次到远程仓库,所有人就都可以使用了