SpringCloud微服务系列- 分布式能力建设之配置中心

SpringCloud微服务系列- 分布式能力建设之配置中心

   概要

   配置中心,顾名思义就是用来统一管理项目中所有配置的系统。

   微服务里面,配置中心的思路就是把项目中各种配置、各种参数、各种开关,全部都放到一个集中的地方进行统一管理,并提供一套标准的接口。当各个服务需要获取配置的时候,就来配置中心的接口拉取。当配置中心中的各种参数有更新的时候,也能通知到各个服务实时的过来同步最新的信息,使之动态更新。

   一、Spring Cloud Config 初识

   1. 分布式系统面临问题

   在分布式系统中,由于服务数量巨多,为了方便服务配置文件统一管理,实时更新,所以需要分布式配置中心组件。

   2. 什么是Spring Cloud Config

   Spring Cloud Config 项目是一个解决分布式系统的配置管理方案。

   3. 整体结构

   整个结构包括三个部分,客户端(各个微服务应用),服务端(中介者), 配置仓库(可以是本地文件系统或者远端仓库,包括git、svn等)。

   二、Spring Cloud Config 使用

   1. Config配置总控中心搭建

   分布式配置中心服务端:

<!--引入config依赖-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactIdspring-cloud-config-server</artifactId>
</dependency>

   3. Config配置读取规则

   客户端如何通过配置中心服务端,来获取远端仓库属于自己微服务的配置 

   1. Config支持的请求的参数规则

1 /{application)/{profile}[/label}]
2 /{application}-(profile}.yml
3 /{label}/application)-{profile}.yml
4 /{application}-(profile}.properties
5 /{label}/{application}-{profile}.properties
6 
7 application 应用名
8 profile 环境名
9 label Git分支

   注意:

   1) {application} 就是应用名称,对应到配置文件上来,就是配置文件的名称部分,例如我上面创建的配置文件。

   2) {profile}就是配置文件的版本,我们的项目有开发版本、测试环境版本、生产环境版本,对应到配置文件上来就是以application-{profile).yml加以区分,
例如application-dev.yml,application-test.yml,application-prod.yml.

   3) {label}表示git分支,默认是master分支,如果项目是以分支做区分也是可以的,
那就可以通过不同的label来控制访问不同的配置文件了。

   最推荐使用方式:

   /{分支名}/{应用名}-{环境名}.yml

   比如:gitee中 master分支中的config-dev.yml 这里面  application为config  profile为dev  label为master

   2. Config客户端配置与测试

   注意:
   applicaiton.yml: 是用户级的资源配置项
   bootstrap.yml: 是系统级的,优先级更加高
   bootstrap.yml 优先级高于application.yml

   为什么要引入bootstrap?

   注意:要将Client模块下的application.yml文件改为pootstrap.yml,这是很关键的,因为bootstrap.yml是比application.yml先加载的。bootstrap.yml优先级高于application.yml

1 <!--  引入依赖  -->
2 
3 
4 <dependency>
5    <groupId>org.springframework.cloud</groupId>
6    <artifactId>spring-cloud-starter-bootstrap</artifactId>
7 </dependency>

   bootstrap.yml文件

 1 server:
 2   port: 3355
 3 eureka:
 4   client:
 5     service-url:
 6       # 指定单机eureka 服务 地址
 7       defaultZone: http://localhost:7001/eureka/
 8   instance:
 9     # 实例名字
10     instance-id: cloud-config-client3355
11 spring:
12   application:
13     # 设置应用名字
14     name: cloud-config-client
15   cloud:
16     config:
17       # 分支名字
18       label: master
19       # 应用名字
20       name: config
21       # 环境名
22       profile: dev
23       # config server地址
24       uri: http://localhost:3344
25 management:
26    endpoints:
27      web:
28       exposure:
29         include: "*"

   4. Config客户端之动态刷新

   为了让客户端读取到最新的配置文件,在每次运维修改配置文件后,就需要重启客户端。但是这种做法太麻烦了,我们可以采用动态刷新的方式来实现。

1 <!--引入依赖-->
2 
3 
4 <dependency>
5   <groupId>org.springframework.boot</groupId>
6   <artifactId>spring-boot-starter-actuator</artifactId>
7 </dependency>

   手动刷新配置:
   POST请求: http://localhost:3355/actuator/refresh

   然后再到客户端读取配置,如下图:

   三、Spring Cloud Bus

   Spring Cloud Bus微服务中必备的组件,通过它来解决分布式配置中心所遇到的问题

   1.  Config配置中心遇到的问题

   当我们在更新码云上面的配置以后,如果想要获取到最新的配置,需要手动刷新机制,每次提交代码发送请求来刷新客户端,客户端越来越多的时候,需要每个客户端都执行一遍,这种方案就不太适合了。

   Spring Cloud作为微服务架构的一个综合解决方案,也提供了对应的解决方案Spring Cloud Bus,即消息总线。

   2.  什么是Spring Cloud Bus

   Spring Cloud Bus通过建立多个应用之间的通信频道管理和传播应用间的消息,从技术角度来说,应用了AMQP消息代理作为通道,通过MQ的广播机制实现消息的发送和接收。Bus支持两种消息代理:RabbitMQ和Kafka

   3.  Spring Cloud Bus做配置更新的步骤

   1) 修改配置文件,提交代码触发post给客户端A发送bus/refresh

   2) 客户端A接收到请求从Server端更新配置并且发送给Spring Cloud Bus

   3) Spring Cloud bus接到消息并通知给其它客户端

   4) 其它客户端接收到通知,请求Server端获取最新配置

   5) 全部客户端均获取到最新的配置

   4.  Spring Cloud Bus使用

   1) pom文件中引入依赖

1 <!--消息总线BUS依赖-->
2 
3 
4 <dependency>
5    <groupId>org.springframework.cloud</groupId>
6    <artifactId>spring-cloud-starter-bus-amqp</artifactId>
7 </dependency>

   2.  yml文件中添加配置

 1 spring:
 2 
 3   rabbitmq:
 4     #主机地址
 5     host:192,168.66.101
 6     #端口
 7     port:5672
 8     #用户名
 9     username:guest
10     #密码
11     password:guest

   3. 手动更新方式

   1)一次发送处处生效

   POST:http://localhost:3355/actuator/busrefresh

   2)Bus动态刷新定点通知

   说明:指具体某个实例生效而不是全部

   POST: http://localhost:3355/actuator/busrefresh/cloud-config-client:3355

   四、各个主流配置中心对比

   1.  Apollo和Nacos相对于Spring Cloud Config的生态支持更广,在配置管理流程上做的更好。

   2. Apollo相对于Nacos在配置管理做的更加全面,不过使用起来也要麻烦一些。

   3. Apollo容器化较困难,Nacos有官网的镜像可以直接部署,总体来说,Nacos比apollo更符合KISS原则。

   4. Nacos部署和使用起来相对比较简洁,在对性能要求比较高的大规模场景更适合。

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

posted @ 2024-06-29 14:40  欢乐豆123  阅读(57)  评论(0编辑  收藏  举报