课程内容
-
SpringCloudGateway网关
-
SpringCloudConfig的使用
一.服务网关SpringCloudGateway
1.基本概念
1.1.Zuul与Gateway
Zuul是Netflix的开源项目，Spring Cloud将其收纳成为自己的一个子组件。zuul用的是多线程阻塞模型，它本质上就是一个同步 Servlet，这样的模型比较简单，他都问题是多线程之间上下文切换是有开销的，线程越多开销就越大。线程池数量固定意味着能力接受的请求数固定，当后台请求变慢，面对大量的请求，线程池中的线程容易被耗尽，后续的请求会被拒绝。
在Zuul 2.0中它采用了 Netty 实现异步非阻塞编程模型，异步非阻塞模式对线程的消耗比较少，对线程上线文切换的消耗也比较小，并且可以接受更多的请求。它的问题就是线程模型比较复杂，要求深究底层原理需要花一些功夫。
Spring Cloud Gateway是Spring Cloud自己的产物，基于Spring 5 和Spring Boot 2.0 开发，Spring Cloud Gateway的出现是为了代替zuul,在Spring Cloud 高版本中没有对zuul 2.0进行集成，SpringCloud Gateway使用了高性能的Reactor模式通信框架Netty。
Spring Cloud Gateway 的目标，不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/指标，和限流。
所以说其实Gateway和zuul 2.0差别不是特别大，都是采用Netty高性能通信框架，性能都挺不错。
1.2.Spring Cloud Gataway的特点
在Spring Cloud官方定义了SpringCloud Gateway 的如下特点：
-
基于 Spring 5，Project Reactor , Spring Boot 2.0
-
默认集成 Hystrix 断路器
-
默认集成 Spring Cloud DiscoveryClient
-
Predicates 和 Filters 作用于特定路由，易于编写的 Predicates 和 Filters
-
支持动态路由、限流、路径重写
1.3.Spring Cloud Gataway的核心概念
Spring Cloud Gataway有几个核心组成：
-
Filter（过滤器）：
Spring Cloud Gateway的Filter和Zuul的过滤器类似，可以在请求发出前后进行一些业务上的处理 ,这里分为两种类型的Filter，分别是Gateway Filter网关filter和Global Filter全局Filter, 他们的区别在后续会讲到。
-
Route（路由）：
网关配置的基本组成模块，和Zuul的路由配置模块类似。一个Route模块由一个 ID，一个目标 URI，一组断言和一组过滤器定义。如果断言为真，则路由匹配，目标URI会被访问。说白了就是把url请求路由到对应的资源(服务)，或者说是一个请求过来Gateway应该怎么把这个请求转发给下游的微服务，转发给谁。
-
Predicate（断言）：
这是一个 Java 8 的 Predicate，可以使用它来匹配来自 HTTP 请求的任何内容，例如 headers 或参数。断言的输入类型是一个 ServerWebExchange。简单理解就是处理HTTP请求的匹配规则，在什么样的请情况下才能命中资源继续访问。
1.4.Spring Cloud Gateway的工作方式
Spring Cloud Gateway 的工作原理跟 Zuul 的差不多，最大的区别就是 Gateway 的 Filter 只有 pre 和 post 两种，下面是官方的执行流程图：
客户端向Spring Cloud Gateway发出请求。如果网关处理程序映射确定请求与路由匹配，则将其发送到网关Web处理程序。该处理程序通过特定于请求的过滤器链来运行请求。筛选器由虚线分隔的原因是，筛选器可以在发送代理请求之前和之后运行逻辑。所有“前置”过滤器逻辑均被执行。然后发出代理请求。发出代理请求后，将运行“后”过滤器逻辑。
2. Spring Cloud Gataway入门
2.1.创建工程导入依赖
工程名：springcloud-gateway-server-1110 ，导入gataway基础依赖
<!--服务注册与发现--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId> </dependency>
2.2.主配置类
//服务注册与发现
@SpringBootApplication
@EnableDiscoveryClient
public class GatewayServerApplication1110 {
public static void main(String[] args) {
SpringApplication.run(GatewayServerApplication1110 .class);
}
}
2.3.yml配置
eureka: client: serviceUrl: defaultZone: http://peer1:1010/eureka/ instance: prefer-ip-address: true #使用ip注册到Eureka instance-id: gateway-server:1110 #指定客户端实例的ID spring: application: name: gateway-server cloud: gateway: discovery: locator: enabled: false #开放服务名访问方式 lower-case-service-id: true #服务名小写 routes: - id : application-user #指定服务名 uri: lb://user-server #去注册中心找这个服务名 predicates: #断言，匹配访问的路径 - Path=/user/** #服务访问路径 filters: - StripPrefix=1 #请求转发的时候会去掉 /user访问路径 server: port: 1110
这里除了要注册到Eureak以外，还需要配置Gataway的路由
-
spring.cloud.gateway.discovery.locator.enabled=false: 不开放服务名访问方式 -
spring.cloud.gateway.discovery.locator.lower-case-service-id: true忽略服务名大小写，大写小写都可以匹配 -
spring.cloud.gateway.routes.id: 指定了路由的服务名，可以自己定义 -
spring.cloud.gateway.routes.uri=lb://user-server: 去注册中心找服务，采用负载均衡的方式请求。其实就是找要调用的服务。 -
spring.cloud.gateway.routes.predicates: 断言，这里使用的Path=/user/**，即匹配访问的路径如果匹配/user/就可以将请求路由(分发)到user-server这个服务上。 -
spring.cloud.gateway.routes.filters:这里使用StripPrefix=1主要是处理前缀 /user ,访问目标服务的时候会去掉前缀访问。这个需要根据url情况来定义。
2.5.访问测试
启动注册中心，启动用户服务，启动网关访问：http://localhost:1110/user/user/1,请求将会打到用户服务上，并返回用户数据。
3. Predicate断言工厂
3.1.什么是断言工厂
什么是断言工程，在Spring Cloud Gateway官方文档有如下解释：
Spring Cloud Gateway将路由作为Spring WebFlux HandlerMapping基础架构的一部分进行匹配。Spring Cloud Gateway包括许多内置的路由断言工厂。所有这些断言都与HTTP请求的不同属性匹配。您可以将多个路由断言工厂与逻辑and语句结合使用。
这里不难理解，其实断言工厂就是用来判断http请求的匹配方式。比如我们再上面案例中配置的：“Path=/user/**” ，就是使用的是 “Path Route Predicate Factory” 路径匹配工厂，意思是http请求的资源地址必须是 /user 才会被匹配到对应的路由，然后继续执行对应的服务获取资源。
在Spring Cloud Gateway中，针对不同的场景内置的路由断言工厂，比如
-
Query Route Predicate Factory：根据查询参数来做路由匹配 -
RemoteAddr Route Predicate Factory：根据ip来做路由匹配 -
Header Route Predicate Factory：根据请求头中的参数来路由匹配 -
Host Route Predicate Factory：根据主机名来进行路由匹配 -
Method Route Predicate Factory：根据方法来路由匹配 -
Cookie Route Predicate Factory：根据cookie中的属性值来匹配 -
Before Route Predicate Factory：指定时间之间才能匹配 -
After Route Predicate Factory： 指定时间之前才能匹配 -
Weight Route Predicate Factory： 根据权重把流量分发到不同的主机
3.2.根据查询参数断言- Query Route Predicate Factory
spring: cloud: gateway: routes: - id: query_route uri: https://example.org predicates: - Query=green
上面配置表达的试试是如果请求参数中包含了 green，那么就会断言成功，从而执行uri后面的地址。
3.3.根据path断言-Path Route Predicate Factory(重要)
spring:
cloud:
gateway:
routes:
- id: path_route
uri: https://example.org
predicates:
- Path=/red/{segment},/blue/{segment}
请求路径如: /red/1或/red/blue或/blue/green 就可以断言成功
3.4.根据权重比例断言-Weight Route Predicate Factory
spring: cloud: gateway: routes: - id: weight_high uri: https://weighthigh.org predicates: - Weight=group1, 8 - id: weight_low uri: https://weightlow.org predicates: - Weight=group1, 2
大约80％的请求转发到weighthigh.org，将大约20％的流量转发到weightlow.org。
3.5.根据远程ip断言 - RemoteAddr Route Predicate Factory
spring: cloud: gateway: routes: - id: remoteaddr_route uri: https://example.org predicates: - RemoteAddr=192.168.1.1/24
如果请求的远程地址为 192.168.1.1到192.168.1.24之间，则此路由匹配
3.6.指定时间之后断言-After Route Predicate Factory
spring: cloud: gateway: routes: - id: after_route uri: https://example.org predicates: - After=2017-01-20T17:42:47.789-07:00[America/Denver]
在atfer配置的时间之后才能访问
3.7.在指定时间之前断言-Before Route Predicate Factory
spring: cloud: gateway: routes: - id: before_route uri: https://example.org predicates: - Before=2017-01-20T17:42:47.789-07:00[America/Denver]
在before配置的时间之前才能访问
3.8.在指定时间段之间断言-Between Route Predicate Factory
spring: cloud: gateway: routes: - id: between_route uri: https://example.org predicates: - Between=2017-01-20T17:42:47.789-07:00[America/Denver], 2017-01-21T17:42:47.789-07:00[America/Denver]
请求时间在两个时间之内者允许访问
3.9.根据cookie断言-Cookie Route Predicate Factory
spring: cloud: gateway: routes: - id: cookie_route uri: https://example.org predicates: - Cookie=chocolate, ch.p
cookies中必须有Cookie配置的属性才能匹配
3.10.根据请求头断言-Header Route Predicate Factory
spring: cloud: gateway: routes: - id: header_route uri: https://example.org predicates: - Header=X-Request-Id, \d+
请求头必须出现 X-Request-Id 才可以访问
3.11.根据主机断言-Host Route Predicate Factory
spring: cloud: gateway: routes: - id: host_route uri: https://example.org predicates: - Host=**.somehost.org,**.anotherhost.org
如果请求的主机头具有值.somehost.org,或者.anotherhost.org这匹配路由
3.12.根据请求方式断言-Method Route Predicate Factory
spring: cloud: gateway: routes: - id: method_route uri: https://example.org predicates: - Method=GET,POST
只允许 GET和POST请求
4.Gateway 的 Filter 过滤器（重要）
Gateway的Filter的zuul的Filter有相似之处，与zuul不同的是，Gateway的filter从生命周期上可以为“pre”和“post”类型。根据作用范围可分为针对于单个路由的gateway filter，和针对于所有路由的Global Filer。
4.1. 内置的Gateway filter
针对单个路由的Filter, 它允许以某种方式修改HTTP请求或HTTP响应。过滤器可以作用在某些特定的请求路径上。Gateway内置了很多的GatewayFilter工厂。如果要使用这些Filter只需要在配置文件配置GatewayFilter Factory的名称。下面拿一个内置的Gateway Filter举例：
AddRequestHeader GatewayFilter Factory该Filter是Gateway内置的，它的作用是在请求头加上指定的属性。配置如下：
spring: cloud: gateway: routes: - id: add_request_header_route uri: https://example.org filters: - AddRequestHeader=X-Request-red, blue
在spring.cloud.gateway.routes.filters配置项配置了一个AddRequestHeader ,他是“AddRequestHeader GatewayFilter Factory”的名称，意思是在请求头中添加一个“X-Request-red”的属性，值为blue 。
其他的Filter可以去看 AbstractGatewayFilterFactory 的实现类。
更多的内置的Filter，见 官网文档
4.2.自定义Gateway Filter
在Spring Cloud Gateway自定义过滤器，过滤器需要实现GatewayFilter和Ordered这两个接口。我们下面来演示自定义filter计算请求的耗时。
public class RequestTimeFilter implements GatewayFilter, Ordered {
private static final Log log = LogFactory.getLog(GatewayFilter.class);
private static final String COUNT_Start_TIME = "countStartTime";
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
//开始时间
exchange.getAttributes().put(COUNT_Start_TIME, System.currentTimeMillis());
//执行完成之后
return chain.filter(exchange).then(
Mono.fromRunnable(() -> {
//开始时间
Long startTime = exchange.getAttribute(COUNT_Start_TIME);
//结束时间
Long endTime=(System.currentTimeMillis() - startTime);
if (startTime != null) {
log.info(exchange.getRequest().getURI().getRawPath() + ": " + endTime + "ms");
}
})
);
}
@Override
public int getOrder() {
return Ordered.LOWEST_PRECEDENCE;
}
}
提示： getOrder返回filter的优先级，越大的值优先级越低 ， 在filterI方法中计算了请求的开始时间和结束时间
最后我们还需要把该Filter配置在对应的路由上，配置如下：
@Configuration
public class FilterConfig {
//配置Filter作用于那个访问规则上
@Bean
public RouteLocator customerRouteLocator(RouteLocatorBuilder builder) {
return builder.routes().route(r -> r.path("/services/user/**")
//去掉2个前缀
.filters(f -> f.stripPrefix(2)
.filter(new RequestTimeFilter())
.addResponseHeader("X-Response-test", "test"))
.uri("lb://service-user")
.order(0)
.id("test-RequestTimeFilter")
).build();
}
}
}
提示：这里将 RequestTimeFilter 添加到 “/user/**”这里路由上，当请求包含/user就会触发Filter的执行。
4.3.自定义GlobalFilter
GlobalFilter:全局过滤器，不需要在配置文件中配置，作用在所有的路由上，最终通过GatewayFilterAdapter包装成GatewayFilterChain可识别的过滤器，它为请求业务以及路由的URI转换为真实业务服务的请求地址的核心过滤器，不需要配置，系统初始化时加载，并作用在每个路由上。这里我们模拟了一个登陆检查的Filter.
@Component
@Slf4j
public class TimeGlobleFilter implements GlobalFilter , Ordered {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
List<String> token = exchange.getRequest().getHeaders().get("token");
log.info("检查 TOKEN = {}" ,token);
if(token == null || token.isEmpty()){
//响应对象
ServerHttpResponse response = exchange.getResponse();
//构建错误结果
HashMap<String,Object> data = new HashMap<>();
data.put("code",401);
data.put("message","未登录");
DataBuffer buffer = null;
try {
byte[] bytes = JSON.toJSONString(data).getBytes("utf-8");
buffer = response.bufferFactory().wrap(bytes);
//设置完成相应，不会继续执行后面的filter
//response.setComplete();
response.setStatusCode(HttpStatus.UNAUTHORIZED);
response.getHeaders().add("Content-Type","application/json;charset=UTF-8");
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
//把结果写给客户端
return response.writeWith(Mono.just(buffer));
}
log.info("Token不为空 ，放行");
return chain.filter(exchange);
}
@Override
public int getOrder() {
return 0;
}
}
如果请求头中没有 token ，就返回咩有权限的状态吗。
使用 buffer = response.bufferFactory().wrap(bytes) 构建响应内容，通过response.writeWith(Mono.just(buffer)); 把内容写给客户端。
5.Gateway跨域配置
所谓的跨域是因为浏览器的同源(同一个域)策略限制，其实就是同源策略会阻止一个域的javascript脚本和另外一个域的内容进行交互 ，在前后端分离的项目架构中就会出现跨域问题，因为Gateway 网关是微服务的访问入口，所以我们只需要在Gateway配置跨域即可：官方文档
spring: cloud: globalcors: #跨域配置 cors-configurations: '[/**]': allowedOrigins: "https://docs.spring.io" #允许的站点 allowedMethods: #允许的请求方式 - GET - POST - DELETE - PUT - HEAD - CONNECT - TRACE - OPTIONS allowHeaders: #允许的请求头 - Content-Type
提示：运行跨域访问的站点：Spring | Home ，同时把常见的请求方式都开放。
6.Gateway超时
超时配置在微服务调用和数据读取的时候显得尤为重要，下面演示Gateway中的全局超时设置：
spring: cloud: gateway: httpclient: connect-timeout: 1000 response-timeout: 5s
指定路由超时配置：
spring:
cloud:
gateway:
routes:
- id: per_route_timeouts
uri: https://example.org
predicates:
- name: Path
args:
pattern: /delay/{timeout}
metadata:
response-timeout: 200
connect-timeout: 200
二.配置中心Spring Cloud Config
1.理解配置中心
1.1.什么是配置中心
在分布式系统中，由于服务数量很多，为了方便服务配置文件统一管理我们需要用到置中心组件。在Spring Cloud中，分布式配置中心组件spring cloud config 它可以帮我们集中管理配置文件，修改配置无需重启服务 等，它支持配置文件放在配置服务的本地，也支持放在远程如Git仓库中集中管理。在spring cloud config 分为了服务端 config server和客户端config client 两个角色。
1.2.配置中心工作流程
使用spring cloud config管理配置文件，我们需要把微服务的配置文件上传到Git仓库 ， 然后搭建独立的ConfigServer服务，ConfigServer除了要从Git仓库拉取配置之外，还要注册到EurekaServer中，我们把ConfigServer本身也当做是一个微服务(当然ConfigServer可以脱离注册中心使用，但是如果客户端使用服务发现的方式指向配置中心就需要注册到注册中心了)，至于ConfigClient这需要集成到具体的微服务中，如支付服务，订单服务等。其工作流程是，微服务通过ConfigClient向配置中心ConfigServer发起请求获取配置文件，配置中心从GIT仓库获取配置，然后再一路返回给微服务。
需要注意是，EurekaServer的配置不能交给ConfigServer管理，因为必须要先启动EurekaServer才能启动ConfigServer，试问EurekaServer都没配置怎么启动？
1.3.解决方案
根据上图我们知道，如果要实现配置文件统一管理，我们需要创建自己的远程仓库(当然也可以本地，或者其他仓库)，我这里选择“码云”，然后将配置文件上传上去 ，然后我们需要搭建自己的配置中心服务ConfigServer，配置上码云的仓库地址和相关账号，最后我们需要去修改我们的微服务如：zuul网关，支付服务等集成ConfigClient 。
2.Git仓库管理配置
2.1.使用码云创建远程仓库
我们用码云作为git仓库 ，创建码云仓库
我这里以zuul网关服务做演示 。 创建zuul配置 在仓库中创建文件 ，我们先将zuul的配置文件复制到码云上 ， 并负责好仓库地址以备用。
注意复制好仓库地址，在克隆中取拷贝 ， 待会搭建配置中心的时候会用到
3.搭建配置中心
3.1.搭建项目
搭建工程 springcloud-config-server-1070 ,作为配置中心服务端，搭建好项目结构如下
springcloud-parent
pom.xml
springcloud-config-server-1070 //配置中心服务
springcloud-eureka-server-1010
springcloud-order-server-1030
springcloud-pay-server-1040
springcloud-user-common
springcloud-user-server-1020
springcloud-zuul-server-1060 //网关服务
3.2.导入依赖
这里导入了Eureka Client基础依赖 ，和config server服务端依赖已经web依赖
<dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-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-config-server</artifactId> </dependency> </dependencies>
3.3.开启配置中心
在主配置类通过打@EnableConfigServer标签开启配置中心
package cn.itsource.springboot;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
/**
* 配置中心的启动类
* @EnableConfigServer：开启配置中心
*/
@SpringBootApplication
@EnableEurekaClient
@EnableConfigServer
public class ConfigServerApplication1070
{
public static void main( String[] args )
{
SpringApplication.run(ConfigServerApplication1070.class);
}
}
3.4.配置文件
ConfigServer的配置文件做两个事情，1.注册到EurekaServer，2.配置码云地址
eureka:
client:
serviceUrl:
defaultZone: http://peer1:1010/eureka/,http://peer2:1011/eureka/,http://peer3:1012/eureka/ #注册中心地址
instance:
prefer-ip-address: true #使用ip地址注册
instance-id: config-server:1070 #指定服务的id
server:
port: 1070
spring:
application:
name: config-server
cloud:
config:
server:
git:
#配置远程仓库地址，去仓库中复制
uri: https://gitee.com/little_wolf/springcloud-config-1010.git
username: 1462163787@qq.com #仓库是私有的需要账号
password: 你的密码
#search-paths: 路径 #如果配置文件不再仓库的根目录，需要配置查找路径
方式二：在本地管理配置文件
通常情况下，我们会通过 srping.cloud.config.server.git.uri配置远程的Git仓库地址,（如上配置），配置中心服务从git仓库中拉取配置文件，而其它微服务再从配置中心服务获取配置 ，但有的时候因为网络故障等原因我们没办法连接到git仓库，那整个微服务的配置文件都可能会拉取失败，针对于这种情况我们可以把配置文件统一管理在本地磁盘中，如下配置：
spring: application: name: config-server cloud: config: server: git: native: search-locations: classpath:config,file:D:/config #从d:/config 和 classpath:config加载 #配置远程仓库地址 #uri: https://gitee.com/little_wolf/springcloud-config-1010.git #username: 1462163787@qq.com #仓库是私有的需要账号 #password: 你的密码 #search-paths: 路径 #如果配置文件不再仓库的根目录，需要配置查找路径 profiles: active: native #基于本地的配置
3.5.测试配置中心
浏览器访问：
4.Zuul集成ConfigClient
上一步骤我们已经可以通过ConfigServer从码云上获取到配置文件，我们的最终目的是能够让我们的微服务，zuul-server，order-server等都可以从ConfigServer拉取到配置文件，这里功能我们需要给微服务集成ConfigClient来实现。修改“springcloud-zuul-server-1060” zuul工程如下：
4.1.导入依赖
config client基础依赖
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-config-client</artifactId> </dependency>
4.2.创建bootstrap.yml配置文件
需要特别说明一下，虽然我们把zuul的配置文件搬到了码云上面，但是zuul本地依然需要一些基础的配置 ，在ConfigClient需要使用bootstrap.yml来作为基础配置文件，这是因为bootstrap.yml的优先级高于application.yml或者其他配置来源，我们得让微服务优先从码云上拉取配置文件后才能做其他的事情。
创建配置文件 resources/bootstrap.yml,添加如下内容
#配置中心的地址 spring: cloud: config: uri: http://localhost:1070 #zuul要从配置中心拉取文件 #你要拉取具体的哪个配置文件 name: application-zuul #配置文件名字 dev是环境 profile: dev #环境 组成完整的文件名：application-zuul-dev.yml label: master #主分支
提示：我们的Zuul需要从ConfigServer拉取配置文件，所以这里通过…config.uri指向配置中心地址，name属性值得是配置文件的名字 ，profile是环境名字 ， name的值和profile的值合在一起组成完整的配置文件名,好处是可以修改profile的值来切换配置环境，label是git的分支，默认是master。
方式二：使用服务名方式发现配置中心
上面的配置文件中通过uri指向配置中心地址获取配置文件，我们也可以通过服务发现的方式指向配置中心，该方式需要屏蔽掉 uri ，使用 discovery.service-id 来指定配置中心的服务名 ，使用discovery.enabled=true来开启服务发现。需要注意的是：如果使用服务发现的方式来指向配置中心，那么EurekaServer的注册地址需要在本地配置文件中指定。具体配置如下：
spring: cloud: config: #uri: http://localhost:1030 name: application-zuul profile: dev label: master discovery: service-id: config-server #配置中心服务名 enabled: true #使用服务名访问配置中心 eureka: client: serviceUrl: defaultZone: http://peer1:1010/eureka/,http://peer2:1011/eureka/,http://peer3:1012/eureka/ #注册中心地址,需要从注册中心使用服务名发现配置中心
提示：如果ConfigServer配置中心做了集群，那么建议配置中心客户端使用服务名的方式发现配置中心
4.3.测试zuul
启动zuul，观察启动的端口如果是1060说明已经从Git仓库拉取到了配置文件了，如果启动的端口是8080，说明配置文件拉取失败，这个时候需要检查你的集成步骤。
5.配置中心集群【扩展】
5.1.为什么要做集群
Spring Cloud Config配置中心组件帮我们实现了配置文件的统一管理 ，但是在单节点的配置中心情况下暴露的问题也比较明显，即当配置中心服务宕机，那么整个微服务都没有办法再获取到配置文件，为了解决单节点问题，我们需要对配置中心做集群实现高可用。
5.2.集群方案
方式一：客户端指向多个服务端地址 启动多个配置中心服务，他们可以各自独立，在配置中心客户端通过spring.cloud.config.uri指向多个配置中心服务的地址，使用逗号分隔。如启动了两个配置中心：localhost:1070 , localhost:1070,那么zuul(config client)需要修改配置文件:
#配置中心的地址 spring: cloud: config: uri: http://localhost:1070,http://localhost:1071 #zuul要从配置中心拉取文件 #你要拉取具体的哪个配置文件 name: application-zuul #配置文件名字 dev是环境 profile: dev #环境 组成完整的文件名：application-zuul-dev.yml label: master #主分支
这种方式比较简单，我们着重演示一下第二种方式
方案二：服务发现方式：把配置中心作为普通微服务实现集群，即多个配置中心的spring.application.name应用名相同，并注册到注册中心。
配置中心客户端(Config Client)使用 spring.cloud.config.discovery.enable=true 开启配置中心服务发现功能，
使用spring.cloud.config.discovery.service-id指定配置中心服务名，客户端会从EurekaServer根据配置的服务名去发现配置中心。
配置中心客户端微服务会从多个配置中心服务选择一个拉取配置文件，如果优先被选中的配置中心服务挂了，会尝试从下一个配置中心服务拉取配置。
5.3.配置中心集群实战
修改配置中心服务修改springcloud-config-server-1070 配置文件，这里做了两个配置中心配置
eureka:
client:
serviceUrl:
defaultZone: http://peer1:1010/eureka/,http://peer2:1011/eureka/,http://peer3:1012/eureka/ #注册中心地址
spring:
application:
name: config-server
cloud:
config:
server:
git:
uri: https://gitee.com/little_wolf/springcloud-config-1010.git #配置远程仓库地址，去仓库中复制
username: 1462163787@qq.com #仓库是私有的需要账号
password: 你的密码
spring:
profiles:
active: config1 #指定配置文件
---
spring:
profiles: config1
eureka:
instance:
prefer-ip-address: true #使用ip地址注册
instance-id: config-server:1070 #指定服务的id
server:
port: 1070
---
spring:
profiles: config2
eureka:
instance:
prefer-ip-address: true #使用ip地址注册
instance-id: config-server:1071 #指定服务的id
server:
port: 1071
启动两个配置中心，观察Eureak监控面板应该在 config-server服务下挂了两个节点
修改配置中心客户端zuul修改springcloud-zuul-server-1060 配置文件，使用服务发现方式拉取配置
spring: cloud: config: name: application-zuul #要拉取的配置 profile: dev label: master discovery: enabled: true #开启服务发现 service-id: config-server #配置中心服务名 eureka: client: serviceUrl: defaultZone: http://peer1:1010/eureka/,http://peer2:1011/eureka/,http://peer3:1012/eureka/ #注册中心地址
这样一来，即使其中一个配置中心挂了也有另外一个配置中心做支撑。
测试配置中心集群
启动两个配置中心，启动zuul ， 观察端口是否正常获取到 ，如果关闭其中一个配置中心，zuul重启也应该能正常启动和使用。
6.配置中心出错的问题解决
如果发现你的客户端微服务启动不成功，有哪些问题造成：
1.配置文件拉取不到
2.配置文件拉取到了，但是配置内容有错
3.项目其他地方错误 - 不是配置文件的问题
如何判断是配置拉取不到？
观察启动的端口是不是以8080启动的，如果是，一定是配置文件拉取不到（除非你真的就配置的是8080）排查方式：
检查配置中心服务端是否有问题
-
检查ConfigServer启动没有，端口，地址对不对
-
打开浏览器访问一下配置文件看能不能拉取到配置文件,如下：
http://localhost:1070/application-zuul-dev.yml
如果配置中心能获取到配置文件，那么错误一定在ConfigClient ，或者是内容有问题
-
如果配置中心拉取不到配置，有两种情况，1是git地址配置错误，2.内容编码错误,格式错误导致拉取不到
-
检查配置中心的git地址，用户名，密码是否有问题
-
打开码云确认一下内容是否有问题，格式，编码
如果服务端没问题检查客户端
-
对比你的 spring.cloud.config.name 和 profile是否和码云上的配置文件一样，以及 label分支是否一致
-
检查你的 spring.cloud.config.uri 写对了没有，是不是你的配置中心服务的地址
-
检查你的依赖：spring-cloud-config-client导入没有，导入成功么有，按ctrl去点击一下你的依赖(或者删除本地厂库中的依赖重新下载)
配置文件拉取到也报错
如果配置文件拉取到了，服务启动的端口应该就是你配置文件的端口，但是如果启动日志还是有异常，那应该不是配置文件拉取不到的问题了 ，可以把配文件配置成本地方式来排除错误：
-
注释掉 spring-cloud-config-client包
-
恢复本地配置文件
如果配置文件改成本地配置还是启动不能，那就是其他问题，可能是配置文件内容的问题，也可能是代码问题，根据错误日志排查
扫一扫
413
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
