1.统一配置中心概述
1.1 为什么需要统一配置中心
之前我们写的order微服务和product微服务其实是不足的,有以下几个原因:
- 1.不方便维护:(每个人负责单独的模块,有一个人把配置修改后,push到远程,然后另一个人pull后修改代码,测试相同功能,此时配置文件已经改的面目全非了。)
- 2.配置内容安全与权限:一个公司线上的配置不会对开发者进行开发公开的,特别熟数据库账号密码,按理说只有运维才知道。我们需要把数据库信息隔离,不放到数据库密码里面去。
- 3.更新配置项目需重启:每次更新项目都要重启,线上有可能修改一些配置,比如更改项目发送短信接口次数,我们怎样做到不重启。
1.2 统一配置中心
我们到时候会专门做一个项目:config-server单独的微服务,他也有server端和client端。server端,这些配置我们为了方便管理都把他放到git上,这样子版本控制起来比较方便,他会从远端git把配置给拉取下来,以下图的箭头表示配置信息流的流动方向,最开始我们把他放到远端git,远端git的话,有gitlab,github,config-server把配置拉取下来之后,会把其配置放置到本地git上,注意config<->本地git之前是双向流动的,他既会把远端git放到本地git去,也可以假如远端git不能使用了,被墙了,那么他会把本地的git拿出来,后面给product和order服务使用(两个服务都会集成config-server的客户端)
2.统一配置中心server端(config-server)
新建一个项目:
- 1.Spring Initializr
- 2.填写Project Metadata
- 3.添加依赖(本身是个微服务,需要注册到Eureka上去,所以添加Cloud Discovery中的Eureka Discovery和本身是一个配置类:作为config的server端 添加Cloud Config依赖)
- 4.创建完毕之后,删除不必要的文件
- 5.更改pom使各个微服务版本号统一
- 6.在启动类中添加注解:将其注册到Eureka中去
- 7.修改其配置文件application.yml文件
- 8.启用Eureka服务,再启用config服务,一下出现config服务,说明启用成功。
- 9.要成功config-server端,需要添加对应注解
此时启动报错
|
|
我们在远程github仓库创建配置文件:
在远程仓库的config-repo下添加order服务的配置信息:
输入一下信息回车:
配置信息的username和password没有配置因为config-repo是公开仓库
然后重启项目完之后,校验我们的配置文件是否被config-server从github仓库中拉取下来了。然后我们在浏览器输入:
为什么需要多写一个a呢?:http://localhost:8083/order-a.yml,http://localhost:8083/order-b.yml也是可以访问的,但是http://localhost:8083/order.yml不可以访问。
我们查看config-server启动时候的日志如下:
上面是支持properties,yml,json格式见转换的,如下:
具体的访问配置文件格式说明:
查看config-server把远程的文件:order.yml拉取到了本地的哪个文件:如下:
当然我们自己也可以自定义这个配置文件路径:浏览器访问:http://localhost:8083/order-a.yml然后再配置的文件下:
如下:
2.统一配置中心client端
我们以order服务为例集成config-client,按理来说我们把order的全部配置已经放到git上了,不应该放在order的appliaction.yml文件中了,那我们要如何使用了?老套路来了。
1.引入依赖 2.启动类上不需要加注解 3.添加配置
2.1 引入依赖
2.2 启动类上不需要加注解
不加注解
2.3 添加配置
我们需要找到github上的通过config-server拉取到本地的一个配置,那么就需要服务名(配置文件中应用名)加开启环境(dev)找到此配置。
启动应用:报错:
思路:我们的期望启动流程是:1.通过配置文件的service-id:CONFIG找到,config-server,然后config-server把这些配置拉取到本地 2.order服务拿到配置之后才能进行数据库的初始化
现在我们把所有信息都写在applaction.yml文件里面,SpringBoot项目不知道哪个在前,哪个在后面,他直接找数据库相关的,那么就启动失败了。
我们希望config-client的配置先加载,先启动。SpringBoot提供了bootstrap.yml(启动引导的文件),我们把application..yml改成bootstrap.yml
测试是否加载了order-dev.yml里面的配置信息:
我们看能不能拿去到env: dev信息
浏览器访问:http://localhost:8082/env/dev
结果如下:
2.4 统一配置中心的高可用
关于统一配置中心的高可用,我们可以以后在服务器上部署多个,多个服务注册在EurekaServer时候,我们通过Order服务连接CONFIG自动可以实现负载均衡,下面我们以开启多个启动端口为例
1.config-server配置多个启动类
然后启用ConfigApplication、ConfigApplication(1)、ConfigApplication(2)三个应用。在EurekaServer端可以看到3个服务已经启动:
2.我们多次启动Order服务,可以看到其连接的地址多次变动。
第一次启动出现:
2019-05-25 16:38:58.471 INFO 11424 — [ main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : http://JSKJ-PC:9002/
第二次启动出现:
2019-05-25 16:40:01.977 INFO 10640 — [ main] c.c.c.ConfigServicePropertySourceLocator : Fetching config from server at : http://JSKJ-PC:8083/
可以看出他是获取的不同配置。
2.5 统一配置中心和EurekaServer的注意点
Eureka注册中心默认的端口是8761,如果我们将8761改成8762,我们再来看一下情况。
- 1.修改eureka注册中心的端口为:8762,重启
- 2.修改config服务注册中心地址端口为:8762,重启
3.修改config服务对应的远程配置文件的信息:打开http://localhost:8083/order-dev.yml发现配置中心的远程配置已经修改并加载到本地
4.启动Order服务,加载Order服务的配置
我们发现我们的Oder服务已经连接不上config服务
这是什么原因呢?我们理一下流程:Order服务首先要做的其实首先是访问eureka,只有通过访问eureka,才能找到eureka下注册的config服务
现在是根本获取不到,获取不到的时候默认就会访问:http://localhost:8888,这是由于eureka地址没有配置对。但是我们不是在order-dev.yml中已经配置了这个地址吗?还是一个顺序的原因,之前8761之所以可以,是因为:8761是默认的一个地址。访问不到微服务就会默认访问8761注册中心,所以是没有问题的。所以当eureka不是默认端口:8761的是时候,我们把eureka的配置信息放到github远程配置上是不合理的。所以我们需要把这个配置拿出来放到Order服务里面的配置文件里面来,Order服务首先加载本地的bootstrap.yml,然后找到注册中心,从注册中心中找到config服务。
做法:远程去掉eureka注册配置,将其保存到order服务的bootstrap.yml中。
5.在启动Order服务前,我们看一下config下访问的远程配置文件order-dev.yml文件是否已经已经加载到本地
发现配置信息并没有加载正确到本地,这个是为什么呢?我们先清空config的控制台,然后再浏览器端访问那个配置:http://localhost:8083/order-dev.yml。发现
说明:会拿到两份配置,并会合并,我们之前的order.yml文件里面配置了eureka注册信息。这个时候是不是应该把order.yml删除了,其实不是的,既然,不管加载哪个配置都需要加载order.yml配置文件,那麽我们就应该把通用的配置信息加载到order.yml文件。这里我们先把order.yml文件里面信息先注释掉。
然后重新访问就可以了。
2.6 统一配置中心延伸
我们想用统一配置中心的原因是:更新配置项目需重启,但是我们现在也没有达到。我们修改github上面的配置时候,我们还是没有变化。那么如何做到统一配置的的动态刷新呢?下节我们再学习。
3.SpringCloud Bus自动刷新配置
3.1 引言
Bus就是想上就上的公共汽车。他还有信息通路,总线,这里就是总线的意思。
以下是之前统一配置的架构图:
我们修改远程git配置,order服务、product服务不会更新修改的配置,原因是我们修改远端git配置后没有及时通知order、product微服务。消息的传递需要载体-消息队列。消息的通知SpringCloud中推荐使用消息队列。要操作消息和操作数据库一样,肯定要使用组件、引入依赖。SpringCloud Bus就是用来操作消息队列的。config-server和order通过消息队列传递信息。config-server使用SpringCloud Bus之后会对外提供一个http接口叫做/bus-refresh,访问这个接口,config-server就会把远程git的配置信息发送到mq里面,那谁来访问这个接口呢?自然是远端git访问这个接口最合适。git服务器基本会提供WebHooks功能,你只要把web服务器配置上就好了。
3.2 实战
1.config服务配置
- 1.修改config中pom.xml中SpringBoot版本
由于其他版本有bug,我们引入:2.0.0.BUILD-SNAPSHOT
- 2.引入SpringCloud Bus组件
- 3.启动config服务
提前安装好RabbitMQ。
安装请参考:
可以参考:http://www.chinacion.cn/article/1700.html
https://www.cnblogs.com/cvol/p/8818823.html
启动服务后我们登录RabbitMQ发现了以下队列。
2.order服务配置
- 1.引入Bus依赖
- 2.启动服务
启动服务我们发现了其他一个mq执行了
3.测试修改github上配置看config服务是否不重启可以获取到
我们修改github上的order-dev.yml文件的env值为:dev11 然后刷新http://localhost:8083/order-dev.yml获取到的env为:dev111 但是order服务获取到的值:http://localhost:8082/env/dev中的值还是dev。说明order服务动态获取不到远程修改的配置。
现在config服务和order服务都已经跟消息队列RabbitMQ打通了,还差的是访问config的http接口:/bus-refresh
我们访问:发现报404错误,我们重启config发现重启日志中确实没有/bus-refresh的接口。
解决,我们需要配置一下,让 /bus-refresh接口暴露出来。在config服务的application.yml文件中添加:
重启后我们发现有相关日志打出:
我们使用postman请求一下:看对应的队列是否已经收到消息:
然后再消息队列中查看下消息是否有:
然后再刷新:http://localhost:8082/env/dev
还是dev 为什么没有变成:dev111呢?
其实通过查看本地日志 发现order服务已经加载了此配置。
这个时候我们通过注解@RequestScope实现
再次请求:http://localhost:8082/env/dev 发现已经变化了。
4.集成WebHooks实现动态更新
我们每次修改了github上的配置信息后,都需要在Order服务中通过http调用此接口才能让Order服务获取到对应的信息。我们现在需要把它做成自动实现。我们可以通过webhooks实现,
4.1 github上绑定webhooks
在github上绑定对应的请求:
注意:github上配置url地址不是:http://yyv7tg.natappfree.cc/actuator/bus-refresh
config组件专门提供了一个用于webhooks的路由,叫做monitor
我们需要把config-server对应的本地服务映射到公网
我们使用ngrok 也可以使用natapp.cn:使用说明:https://blog.csdn.net/weixin_38959210/article/details/80401208
我们在github上的webhooks更新地址:
修改远程的配置:env: dev11111
访问项目后:
说明成功。