接上篇《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