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除了提供配置中心的功能，还提供了动态服务发现、服务共享与管理的功能，降低了服务化改造过程中的难度。
