接上篇《37.Spring Cloud Config的安全認證》 Spring Cloud版本為Finchley.SR2版
上兩篇我們講解了有關Spring Cloud Config的安全認證機制，其核心依賴為spring-boot-starter-security，在服務端和用戶端分别配置spring.security.user.name和spring.security.user.password，spring.cloud.config.username和spring.cloud.config.password屬性即可開啟和擷取通路認證。
本篇我們來講解Spring Cloud Config與Eureka的配合使用。
本部分官方文檔：https://cloud.spring.io/spring-cloud-static/Finchley.SR4/single/spring-cloud.html#_security
注：好像Finchley.SR2的文檔已經挂了，最新的是Finchley.SR4的文檔。
一、為什麼Spring Cloud Config需要內建Eureka
我們先來回顧一下我們目前的代碼，之前已經陸續講解了Spring Cloud Config的簡介，編寫了Config Server、Config Client，進行了Git倉庫的配置，配置的對稱和非對稱加解密，以及Spring Cloud Config的安全認證。
以Config Client為觀察對象，我們檢視其bootstrap.yml配置：
spring:
cloud:
config:
uri: http://localhost:8090
username: user
password: password123
profile: dev
label: master
可以看到我們與Config Server的互動，是配置了spring.cloud.config.uri，去指定要擷取配置的服務端的路徑。
上面的配置，其實是有弊端的。大緻有以下幾個弊端：
1、弊端1：叢集環境下，增加Config用戶端與服務端的互動成本
例如在生産環境中，Config Server需要實作高可用（即有叢集），此時Config Server有好幾個同時啟動的應用，利用Nginx進行負載均衡，輪詢通路該Config Server：
此時為了配合Config Server的高可用，在Config Clinet和Config Server之前架設了類似Nginx（或F5等負載均衡軟硬體）的負載均衡裝置，這種情況下，在原有架構的基礎上，增加了元件之間的互動代價，出現異常的幾率也随之增加。
2、弊端2：服務端位址寫死
我們當初學習Eureka的目的，實際上就是為解放用戶端，即我們無需在用戶端去寫死服務端的具體位址，轉而使用服務名這種規範來避免這種情況，這才是服務發現的優點。
目前我們通過spring.cloud.config.uri的方式配置用戶端位址，無疑是使用了寫死，不利于拓展和維護。例如Config Server遷移了伺服器，更換了ip或域名，所有的Config Client都需要更新spring.cloud.config.uri。
3、弊端3：無法享受注冊中心的福利
使用Eureka等服務注冊中心，可以進行服務發現、服務注冊、服務心跳檢測（健康監控）、服務系統資料庫同步、服務API查詢等一些列操作，而單體的Config Client和Config Server都享受不到這些。
是以，我們要将Config Client和Config Server與服務發現元件配合使用，實作Config Client端無需寫死Config Server的位址，并能享受服務發現元件的所有福利。
二、Config Server內建Eureka
我們将Config Server內建到之前的Eureka上，這裡為了好區分，我們重新建立一個Server工程。
在Eclipse中建立一個名為“microserver-config-server-eureka”的工程：
然後在pom.xml中引入Spring Cloud的父工程、config-server、eureka-client的依賴：
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<artifactId>microserver-config-server-eureka</artifactId>
<name>microserver-config-server-eureka</name>
<parent>
<groupId>com.microserver.cloud</groupId>
<artifactId>microserver-spring-cloud</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
</dependencies>
</project>
注意，這裡為了便于版本統一管理，該工程的parent父工程和我們User、Movie工程一樣，均依賴于microserver-spring-cloud工程（此父工程統一引入了spring-cloud-dependencies的Finchley.SR2版，這個在前面的章節已經講過）。
然後我們建立啟動類，與之前沒有差别：
package com.microserver.cloud;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;
@SpringBootApplication
@EnableConfigServer
public class ConfigServerEurekaApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerEurekaApplication.class, args);
}
}
注：Finchley.RELEASE版本的SpringCloud不需要@EnableEurekaClient注解就可以啟用Eureka注冊功能。在SpringBoot的自動配置類裡啟用了注冊功能，隻要引了eureka-client的依賴就會進行注冊。緊接着就是我們的配置檔案，除了Spring Cloud Config配置倉庫的配置，還添加了application-name應用名以及eureka的注冊配置：
server:
port: 8090
cloud:
config:
server:
git:
uri: https://gitee.com/jackzhucoder/Spring-Cloud-Config-Test
application:
name: microserver-config-server-eureka
eureka:
client:
serviceUrl:
defaultZone: http://user:password[email protected]:8761/eureka
instance:
prefer-ip-address: true
注：這裡的eureka1是我們在host配置的127.0.0.1的映射。
然後我們重新開機Config Server服務，以及之前的Eureka服務：
重新開機後我們通路Eureka的服務首頁，可以看到我們的Config Server已經注冊進去了：
到這裡，我們的Config Server內建Eureka就完成了。
三、Config Client內建Eureka
上面對Config Server內建了Eureka，那麼我們的Config Client也要內建Eureka，并且需要通過Eureka通路到Config Server，并擷取相應的遠端配置資訊。
同理我們也建立一個名為“microserver-config-client-eureka”的工程，這裡我們不再贅述建立過程，基本和之前一樣，隻說修改了哪些地方。
pom.xml在原有的基礎上，新增了eureka-client的依賴：
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<artifactId>microserver-config-client-erueka</artifactId>
<name>microserver-config-client-erueka</name>
<parent>
<groupId>com.microserver.cloud</groupId>
<artifactId>microserver-spring-cloud</artifactId>
<version>0.0.1-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-client</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
</dependencies>
</project>
啟動類：
package com.microserver.cloud;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class ConfigClientEurekaApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigClientEurekaApplication.class, args);
}
}
application.yml中的配置不變：
server:
port: 8091
spring:
application:
name: microserver-config-client
type: abcd
bootstrap.yml原本的配置為：
spring:
cloud:
config:
uri: http://localhost:8090
profile: dev
label: master #如果ConfigServer的後端存儲是Git，預設就為master
現在修改為：
spring:
cloud:
config:
profile: dev
discovery:
enabled: true
service-id: MICROSERVER-CONFIG-SERVER-EUREKA
eureka:
client:
serviceUrl:
defaultZone: http://user:password[email protected]:8761/eureka
instance:
prefer-ip-address: true
下面很清楚，是為了注冊eureka。上面我們把之前的spring.cloud.config.uri等寫死去除了，添加了spring.cloud.config.discovery.enabled和spring.cloud.config.discovery.service-id，其中spring.cloud.config.discovery.enabled的意思是辨別Config Server的服務發現是允許的（即允許從注冊中心發現Config Server的uri），spring.cloud.config.discovery.service-id即需要發現的Config Server在Eureka上的注冊名。這裡我們開啟服務發現，并指定擷取的Config Server的注冊名。
此時我們在啟動上面兩個工程的基礎上，啟動Config Client工程：
然後在Config Client啟動的過程中，我們可以在控制台上看到“Fetching config from server at : http://192.168.3.1:8090/”的日志：
這個位址其實就是Config Server在Eureka上注冊時的ip位址：
Config Client通過Eureka注冊中心，發現并擷取了應用名為“MICROSERVER-CONFIG-SERVER-EUREKA”的服務的真實ip，并從中擷取了相應的配置資訊。
我們通過Config Client來通路"/profileType"服務，看看能否成功：
可看到，通過我們配置檔案中配置的“profile: dev”，從遠端倉庫擷取到了microserver-config-client-dev.yml”配置檔案的内容。
以上就是Config Server與Config Client與Eureka配合使用的所有操作。
注：還記得上一章我們為Config Server和Config Client添加了安全認證的配置，有兩種，一種是将username和password直接配置在spring.cloud.config.uri上，一種是添加spring.cloud.config.username和spring.cloud.config.password屬性，我們現在就明白了，如果內建了Eureka時，沒有spring.cloud.config.uri時，我們就可以使用第二種方式配置了。
參考：《51CTO學院Spring Cloud進階視訊》
轉載請注明出處：https://blog.csdn.net/acmman/article/details/106032406