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是服务名。