面臨的問題

在分布式微服務架構系統中，業務和系統功能被拆分成了幾十甚至上百個服務實例。每個服務實例就是以往單體應用時代的一個獨立部署的工程。每個工程都需要自己獨立的啟動加載和運行時配置文件。

在項目開發的過程中，我們不可避免的會涉及到配置文件的修改，例如調整一下數據庫的IP地址，修改某個功能的啟用開關狀態等等。如果系統結構中的微服務節點較少，那么常規的代碼+配置的開發方式足以解決問題。

當系統逐步迭代，其微服務會越來越復雜，慢慢演化成網狀依賴結構，這個時候常規的代碼+配置的開發方式就并不合適了，因為還要考慮整體系統的擴展性、伸縮性和耦合性等。這些問題中，配置的管理也是非常麻煩的。

解決方案

工程化帶來的問題需要用工程化的方案來解決。為了方便的解決配置復雜繁瑣的問題，我們在微服務架構系統中引入配置中心（Spring Cloud Config）。通過它來統一管理微服務架構系統中的配置文件內容修改與分發，配置自動同步的問題，為項目的部署與運維提供便利。

Spring Cloud Config采用集中式管理每個微服務的配置信息，并使用GIT等版本倉庫統一存儲配置內容，實現版本化管理控制。微服務與配置中心使用REST方式交互來實現可擴展的配置服務。

Spring Cloud Config配置中心解決了微服務系統的配置中心化、配置版本控制、平臺獨立、語言獨立等問題，其特性如下：

• 提供服務端和客戶端支持(Spring Cloud Config Server和Spring Cloud Config Client)；
• 集中式管理分布式環境中的配置信息；
• 基于spring環境提供配置管理，與Spring系列框架無縫結合；
• 可用于任何語言開發環境；
• 默認基于GIT倉庫實現版本控制；

如何做到

配置中心(Config Server)本身作為一個微服務注冊到服務注冊中心中(通常可以是Eureka，Consul，Dubbo等提供的注冊中心服務)，配置中心會根據spring.cloud.config.server.git.uri來找到配置數據(它可以是git存儲庫的位置，也可以是本地文件)，配置了正確的uri之后，Config Server就可以從遠程Git服務拉取資源配置。

在項目中，基本上所有的基礎微服務都是Config Client，它們都通過Config Server做外部配置集中管理和動態環境切換。每個Client會在啟動時通過Server來拉取相應的配置資源信息，同時還會通過消息總線（Spring Cloud Bus），以發布-訂閱的方法監聽在運行時由Server端動態發布的配置變更信息。

當我們有配置資源的變更需要時，通過GIT或SVN，將配置資源信息提交到資源倉庫中。提交后觸發對應的Hook調用Server來拉取最新的資源。如此便實現了：資源 -> GIT/SVN -> 配置中心Config Server -> 消息總線Bus -> Config Client 的整個鏈條動態變更。

如何使用

基于spring cloud 2.x版本Spring Cloud Config主要為系統中的服務實例提供外部配置，這些配置通常是可變的，默認是使用git存放配置信息。Spring Cloud Config分為服務端和客戶端兩種角色，服務端用于統一管理配置中心并為客戶端提供配置信息，客戶端用于指定配置中心并在服務啟動時向配置中心拉取資源初始化本地服務，客戶端的配置通常是不變的。這樣就能做到配置與交付分離，當項目部署到不同環境時，不需要去修改客戶端的配置文件，只需要指定其運行配置中心中的哪種環境。

Spring Cloud Config的服務端也是一個服務實例，需要導入服務端依賴。

<!--Spring Cloud Config 服務端依賴-->

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-config-server</artifactId>

</dependency>

特別強調的是，如果使用svn進行代碼管理，還需要導入指定svn的依賴，如果使用git則不用。

<!-- svn依賴 -->

<dependency>

<groupId>org.tmatesoft.svnkit</groupId>

<artifactId>svnkit</artifactId>

</dependency>

在服務端的配置文件中，需要指定配置文件的存放地址，如果使用svn，需要指定spring.profiles.active: subversion，如果不指定項目啟動則會報錯。

要想實現服務端的高可用，可以將服務端注冊到服務中心，當客戶端指定配置中心時從服務中心獲取即可。

服務端的搭建已經介紹完，下面是客戶端是如何與服務端建立關系的。

在客戶端中也需要導入指定依賴

<!-- Spring Cloud Config 客戶端依賴 -->

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-config</artifactId>

</dependency>

注意，客戶端的配置文件使用bootstrap.yml，其加載優先級高于application,yml，所以項目啟動時會預先加載bootstrap.yml中的內容，并且這些內容通常是不可變的，比如指定配置中心，監控配置，快速失敗響應等配置可以放在bootstrap.yml文件中。

到此，客戶端已經能夠通過服務端去加載配置文件，但是大家更關心的是，如果配置文件修改了，怎么及時的獲取最新的配置信息，畢竟每次如果都需要重啟的話成本太大，接下來我們介紹Spring Cloud Config如何實現配置文件的自動刷新機制。

修改客戶端pom.xml文件，添加如下依賴

<!--Spring Boot Actuator 監控-->

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-actuator</artifactId>

</dependency>

<!--spring-cloud-bus 消息總線-->

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-bus-amqp</artifactId>

</dependency>

在bootstrap.yml中添加actuator 監控配置:

啟用監控management.endpoints.enabled-by-default=true

暴露刷新接口

management.endpoints.web.exposure.include='*'（用*可以包含全部端點）

在bootstrap.yml配置rabbitmq的地址以及用戶密碼：

spring.rabbitmq.host=xxx

spring.rabbitmq.port=xxx

spring.rabbitmq.username=xxx

spring.rabbitmq.password=xxx

除了以上的修改，注意還要在需要實現自動刷新的類上添加@RefreshScope注解。

接著解釋一下為什么要做這樣的修改，這些新加的配置是如何相互合作實現動態刷新的，首先actuator是用于感知及監測服務器端的變化，在不啟用消息總線之前其與@RefreshScope結合能夠實現單個端口的刷新，即調用/refresh接口實現，這種屬于手動刷新。顯然這種刷新方式并不是最優的，分布式系統中實例那么多，我們不能每一個服務實例都調用一遍接口，我們希望達到的效果是調用一次即可所有實例都生效，所以引入消息總線spring cloud bus，其實本質是利用了MQ的廣播機制在分布式的系統中傳播消息，當有一個客戶端觸發了配置更新事件（注意這時調用/bus-refresh接口），即會向總線傳達這個消息，總線接到消息并通知給其它客戶端，其它客戶端接收到通知，請求Server端獲取最新配置，至此所有客戶端都得到最新配置。

到此為止，配置中心的動態刷新機制還差一步，就是上述我們需要手動去觸發一個客戶端調用/bus-refresh接口，這個動作可以使用我們的代碼版本管理系統來實現，當配置文件有更新時自動觸發接口，可以與github的webhook進行配合，svn也有類似的hook機制。

總結

關于Spring Cloud Config的使用就為大家介紹到這里，其實Spring Cloud Config還能實現的功能有很多，主要看系統自身需求進行配置，這里我們為大家介紹的是服務搭建及配置資源的動態刷新，這也是運用Spring Cloud Config最核心要解決的問題，想了解關于Spring Cloud Config的更多內容大家可以去網上查找資源，但是要注意的是目前網上的許多教程都是spring cloud 1.5.x版本的，使用spring cloud 2.x需要注意版本升級帶來的改動。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的svn如何取消某个文件的版本管理_微服务架构如何统一管理工程配置文件的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。