接上篇《40.Spring Cloud Config配置属性刷新之自动刷新》 Spring Cloud版本为Finchley.SR2版
一、Spring Cloud Config配置属性刷新之自动刷新补充
上一篇我们讲解了有关Spring Cloud Config配置属性的自动刷新功能，我们使用了“Spring Cloud Bus”来实现自动刷新（利用消息中间件），凡是接入了Spring Cloud Bus的客户端，有任意一个客户端微服务执行了actuator/bus-refresh”节点服务，该更新事件就会发送到消息中间件，而其他接入消息中间件的客户端会获取该事件，进而也执行该配置更新动作。
下面这幅图就说明了使用Spring Cloud Bus”来实现自动刷新的整个机制：
仔细观察这种机制，实际上会有一些问题。例如：
（1）刷新机制不优雅
微服务A的实例1、实例 2和实例 3其实是同等级别的微服务，那现在实例1却承担了刷新配置的责任，那么实例1的站位就要比实例2和实例3来的高，而我们实际上也可以通过实例2和实例3的任何一个来触发刷新，也就是说刷新的动作可以在任何一个微服务上执行，这种没有规范的操作，实际上是不优雅的。
（2）刷新节点不易维护
各个微服务重新上线的时候，它的ip和端口可能会发生变化，此时如果我们使用的是类似WebHook的远程自动调用刷新机制，在没有更新实例1的ip和端口的情况下，进行刷新操作，就会出现异常。而只要实例1的ip和端口发生变化，WebHook的调用地址就要进行变更，很麻烦，不易维护。
那么如何解决上面的问题，使得自动刷新配置的操作，既能够优雅的执行，又便于维护呢？
其实很简单，我们之前只给Config Client加上了Spring Cloud Bus的依赖，来实现刷新事件的自动传播功能，现在我们为Config Server服务端也添加Spring Cloud Bus的依赖（spring-cloud-starter-bus-amqp），然后配置上rabbitmq的配置，然后每次刷新的时候，统一使用Config Server来进行刷新，机制如下：
这样我们就解决了之前刷新机制不优雅的问题，所有的刷新触发操作，由Config Server统一来执行，微服务A的实例1、实例2和实例3只需要关注自己的业务即可。
而Config Server的ip和端口更改的可能性比较小，因为微服务A的实例1、实例2和实例3都与Config Server有关联，一旦更改了Config Server的ip和端口，微服务A的实例1、实例2和实例3也都需要更改（配置中使用了uri），所以一般会保持Config Server有一个固定的访问地址。
二、Config Server的高可用
Config Server的高可用需要满足几点，一个是Git仓库的高可用、MQ消息中间件的高可用，以及Config Server本身的高可用
1、Git仓库的高可用
我们知道，Config Server因为需要从数据仓库中获取配置信息，所以必须依赖Git等远端文本仓库服务的，所以首先要保证Git仓库的高可用。
Git仓库的高可用有两种机制：
（1）使用第三方的Git仓库的高可用
使用GitHub、GitLab、Gitee、Git@OSC、Coding等第三方仓库，他们自身都已经部署了高可用的架构，所以可以直接享受其带来的服务。
（2）自己搭建的私服仓库的高可用
例如只在公司内网的环境下，部署自己的私服仓库，如GitLab的私服，则需要根据实际使用的私服仓库提供的高可用方案来进行部署私服，下面的例子就是部署GitLab私服的高可用方案：
https://www.cnblogs.com/wangshuyang/p/10946099.html
感兴趣的童鞋可以额外进行学习。
2、MQ消息中间件的高可用
在保证Git仓库的高可用的情况下，由于Config Server与Config Client之间要通过MQ消息中间件来实现配置刷新动作的传播，所以也要保证MQ消息中间件的高可用。
我们这里举一下使用的RabbitMQ的例子，这里也是分两种情况：
（1）自己搭建的RabbitMQ的集群
自己使用RabbitMQ搭建集群，我们可以参考官方网站的高可用架构方案，来进行实施：
https://www.rabbitmq.com/ha.html
亦或是参考国内一些高手提供的高可用配置教程来实现，例如下文：
https://www.cnblogs.com/xishuai/p/centos-rabbitmq-cluster-and-haproxy.html
（2）使用云服务
像阿里云等云服务厂商，一般都会提供完整的MQ的集群和高可用机制，我们直接拿来用即可。
3、Config Server本身的高可用
这里分两种情况：
（1）Config Server未注册到Eureka Server上
此时Config Server可以借助一个负载均衡器来实现高可用：
如上图，各个微服务将请求发送到负载均衡器，负载均衡器将请求转发到其代理的其中一个Config Server节点。这样就可以实现Config Server的高可用。
（2）Config Server已注册到Eureka Server上
此时Config Server的高可用相对比较简单，只需要将多个Config Server节点注册到Eureka Server上，利用Eureka Server自身的心跳检测、服务刷新、负载均衡等策略，来实现Config Server高可用。
具体的架构如下图：
以上就是Config Server高可用的实现机制。
参考：《51CTO学院Spring Cloud高级视频》
转载请注明出处：https://blog.csdn.net/acmman/article/details/106585866