config分布式配置中心和服务总线bus

为什莫会引入config呢?看下图:

 config含有客户端和服务端:

服务3344就是配置中心服务服务端:

创建3344服务步骤: 

 pom.xml:

启动类:config服务端要添加开启@EnableConfigServer 

 

application.yml: 

 

配置文件读取规则:下图

 config客户端配置:服务3355

 

 

controller: 

 理解:3344服务作为config的服务端,3344连接github;3355作为config的客户端连接3355;通过上述3355服务的测试接口,和3344服务调用结果一样。  关系就是3344找github,3355找3344

问题随之而来,分布式配置的动态刷新问题?

 手动动态刷新的修改如下:步骤如下图一,然后需要运维人员再发送POST请求来刷新3355,即可:

 

 运维人员post请求:

到这里,就避免了客户端服务重启! 但是还不是最优化的最完美的方案,如果微服务有100个,岂不是要运维发送100次请求?

所以需要自动刷新,非上面的手动刷新:

 到这块就需要引入服务总线的概念了:

 自动刷新总共有两种方案:看下图,但是1不怎么靠谱,所以采用方案2:

 下面分别是方案1和2的思路流程图:

 

开始改造:config服务端和客户端都需要引入RabbitMQ:

 服务端3344改造: 

 

客户端改造3355和3366一样:

 

 

运维人员在github中如果修改或者变更了配置文件,首先3344是直接连接github的,3344会自动变更对应的配置文件,此时经过上面的配置之后,只需要发送一次POST请求刷新3344就ok,3355和3366也会自动刷新过来最新的配置文件。 

还可以自定义进行刷新:下图

 第一个是全局通知,3355、3366都会刷新配置文件;第二个是局部刷新,只刷新了3355,其中config-client是服务名。

猜你喜欢

转载自blog.csdn.net/zhangleiyes123/article/details/106907750