1. 程式人生 > >springcloud-config配置中心的使用

springcloud-config配置中心的使用

最近這兩天在學習springcloud config的一些東西,學習這個最原始的動力是想要了解為什麼要使用配置中心,而springcloud config就是現成的配置中心的實現的方案。至於搭建的過程,config的搭建的過程可以參考程式猿DD的部落格,這裡主要是把重要的點總結一下,順便記錄一下程式猿DD部落格中沒有的東西。配置中心提供了一箇中心化的外部配置,預設使用git儲存配置資訊,這樣就可以對配置資訊進行版本管理,下邊配置中心的搭建就是以git為基礎進行的。配置中心是單獨作為一個服務執行的,搭建這個服務需要引入以下jar包。
<dependencies>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-test</artifactId>
		<scope>test</scope>
	</dependency>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-config-server</artifactId>
	</dependency>
</dependencies>
<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-dependencies</artifactId>
			<version>Brixton.RELEASE</version>
			<type>pom</type>
			<scope>import</scope>
		</dependency>
	</dependencies>
</dependencyManagement>
並在這個的主類上新增@EnableConfigServer註解,開啟配置中心的服務,下一步就是在application.properties配置檔案中新增配置中心的服務資訊和git的資訊,如下
spring.application.name=config-server
server.port=8089
# git管理配置
spring.cloud.config.server.git.uri=https://gitee.com/txxs/springcloud/
spring.cloud.config.server.git.searchPaths=config/config-repo
spring.cloud.config.server.git.username=username
spring.cloud.config.server.git.password=password
這是配置檔案,應該是沒有任何問題的,但是隻限於GitHub和碼雲上,自己或公司搭建的gitlab則需要加上.git尾綴,否則會連線不上。需要重點說明的是spring.cloud.config.server.git.searchPaths這個屬性,她定義了配置檔案搜尋的位置,可以配置多個,多個之間用逗號分隔,這樣多個微服務就可以在配置中心有自己的配置檔案,比如:spring.cloud.config.server.git.searchPaths=config/config-repo,config/config-repo/asset,至此配置中心的服務端便搭建完成,下一步就是在https://gitee.com/txxs/springcloud/的搜尋路徑中新增配置檔案
common.properties 新增內容為common_service_config = common_test
common-dev.properties  新增內容為common_service_config = common_test_dev
common-test.properties  新增內容為common_service_config = common_test_test
common-prod .properties  新增內容為common_service_config = common_test_prod
訪問這些配置資訊有很多方式,個人認為最好的是/{application}/{profile}[/{label}],這種方式將分支label和應用名稱application以及使用環境profile(dev、test以及prod)都表示了,更符合我的習慣,當然這個問題就看各自的選擇了
通過http://localhost:8089/common/prod/master請求即可獲得prod中的資料以及基本檔案中的資料,如下圖所示:

可以看到name為common,profile是prod,分支是master,資料為兩個檔案的資料,一個基本檔案一個生產環境的檔案的配置,在這種情況下就可以對配置中心的檔案進行訪問了。但是配置中心的客戶端訪問時需要引入jar包等操作
    <dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-web</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-starter-config</artifactId>
	</dependency>
然後在客戶端建立bootstrap.properties檔案,並在檔案中新增以下內容,至於為什麼使用bootstrap.properties檔案,給出的解釋是這樣的:config的相關配置會先於application.properties,而bootstrap.properties的載入也是先於application.properties
#對應前配置檔案中的{application}部分
spring.application.name=common
#對應前配置檔案中的{profile}部分
spring.cloud.config.profile=prod
#對應前配置檔案的git分支
spring.cloud.config.label=master
#配置中心的地址
spring.cloud.config.uri=http://localhost:8089/
新建Java的controller類之後就可以看到使用的情況了,重點的是@Refresh註解
@RefreshScope
@RestController
public class TestController {

    @Value("${common_service_config}")
    private String common_service_config;

    @RequestMapping("/service")
    public String from() {
        return this.common_service_config ;
    }
}
訪問結果如下圖所示:

至此客戶端的就可以訪問配置中心的配置資訊了,但是還有一個問題是,如何實現動態重新整理的問題,一個場景是在配置中心修改了配置檔案的內容,相應的客戶端也應該在無感知的情況下獲取到相關的最新內容,有兩種方案,一種是客戶端手動重新整理,另一種是配置中心服務端呼叫重新整理,客戶端無感知,首先說第一種
首先在客戶端新增spring-boot-starter-actuator模組,其中包含了/refresh 端點的實現,該端點將用於實現客戶端應用配置資訊的重新獲取與重新整理。
		<dependency>
			<groupid>org.springframework.boot</groupid>
			<artifactid>spring-boot-starter-actuator</artifactid>
		</dependency>
jar包新增完成之後,重啟客戶端就可以實現手動重新整理的功能了,流程是:
第一、呼叫http://localhost:8090/service,返回common_test_prod
第二、修改配置中心的common-prod配置檔案中的common_service_config屬性為common_test_prod add refresh
第三、呼叫http://localhost:8090/service,依舊返回common_test_prod
第四、呼叫http://localhost:8090/refresh,注意這裡是POST方法
第五、呼叫http://localhost:8090/service,返回common_test_prod add refresh
至此手動重新整理的流程就可以實現了,但是這明顯不是我們想要的內容,配置中心修改內容,客戶端需要手動重新整理這樣不對,那就是第二種方案,再在客戶端新增以下jar包
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-bus-amqp</artifactId>
		</dependency>
		#在配置檔案中新增以下內容
		spring.rabbitmq.host=訊息佇列地址
		spring.rabbitmq.port=5672
		spring.rabbitmq.username=test
		spring.rabbitmq.password=test
然後在碼雲上使用webhooks 傳送 http://你的公網IP:8090/bus/refresh,返回的內容如下內容common_test_prod add refresh send to one client,客戶端就可以在無感知的情況將值更新了,至於為什麼這樣,應該是refresh請求將更新的內容傳送到匯流排佇列上去,然後客戶端獲取到相關的值後將@RefreshScope有關的值更新了,但是這只是更新了一個客戶端,那怎麼才能發一個請求更新所有客戶端呢,答案是將匯流排佇列放在配置中心的服務端,同樣要在服務端新增以下內容
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-bus-amqp</artifactId>
		</dependency>
		#在配置檔案中新增以下內容
		spring.rabbitmq.host=訊息佇列地址
		spring.rabbitmq.port=5672
		spring.rabbitmq.username=test
		spring.rabbitmq.password=test
然後在碼雲上使用webhooks 傳送 http://你的公網IP:8089/bus/refresh,那麼你的公網的服務和本地的服務都可以獲取到最新的值為common_test_prod add refresh send to all client,這樣就可以實現一下將所有值都重新整理的目的,這樣可以有一個非常好的用途,那就是在memcached等服務地址變化頻繁的情況下不用重啟服務而重新整理memcached的地址配置地址,並重新整理相應的bean,當然這個bean上應該有@RefreshScope註解,感覺這是一個非常強大的功能。
為了提高配置中心的可用性,還可以將配置中心註冊在服務中心。服務中心使用的是Eureka,將配置中心註冊在服務中心的需要修改配置中心的客戶端和服務端兩個部分,服務端修改內容為,新增服務中心jar包
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-eureka</artifactId>
		</dependency>
並在配置檔案中新增以下配置檔案
eureka.client.serviceOrl.defaultZone=http://localhost:8080/eureka/
在啟動類上新增以下註解
@EnableDiscoveryClient
@EnableConfigServer
@SpringBootApplication
這樣配置中心的服務端就算配置完成了,配置中心的客戶端配置內容需要,新增jar包
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-eureka</artifactId>
		</dependency>
配置檔案,由原來的
spring.application.name=common
spring.cloud.config.profile=prod
spring.cloud.config.label=master
spring.cloud.config.uri=http://localhost:8089/
server.port=8090
修改為
spring.application.name=common
eureka.client.serviceUrl.defaultZone=http://localhost:8080/eureka/
spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.serviceid=config-server
spring.cloud.config.profile=prod
然後就可以像服務直接呼叫配置中心資料那些呼叫服務中心配置的資訊了,這樣就提高了配置中心的可用性,將配置中心服務化,個人認為這是非常好的用法,微服務中配置檔案的內容也會進一步簡化。在服務註冊和發現過程中出現問題的時候,可以先去服務的註冊地址http://localhost:8080/看看服務有沒有註冊,如果註冊了再看呼叫端問題。