SpringCloud快速入门--GateWay路由网关与Config配置中心

GateWay路由网关

一般情况下，不是所有微服务都需要直接暴露给外部调用，这时可以使用路由机制，添加一层防护，让所有请求全部通过路由来转发到各个微服务，并且转发给多个微服务实例也可以实现负载均衡。

无标题

部署网关步骤如下：

  1. 创建一个新模块，添加如下依赖：

    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

    1. 编写配置文件

      server:
  port: 8500
spring:
  application:
    name: gateway-service
eureka:
  # 修改客户端设置
  client:
    # 指向eureka服务端
    service-url:
      defaultZone: http://localhost:8801/eureka,http://localhost:8802/eureka

      1. 编写启动类

        @SpringBootApplication
public class AppGateway
{
    public static void main( String[] args )
    {
        SpringApplication.run(AppGateway.class, args);
    }
}

        这时就可以启动网关服务了。

    2. 配置路由服务：

      spring:
  application:
    name: gateway-service
  cloud:
    gateway:
      # 配置路由，这是一个列表
      routes:
      - id: borrow-service  # 路由名称
        uri: lb://borrow-service # 路由的地址，lb表示使用负载均衡到微服务。也可以使用HTTP正常转发
        predicates: # 路由规则，断言什么请求会被路由
        - Path=/borrow/** #只要是访问这个路径，一律都都被路由到上面指定的服务

      此时，当我们访问借阅服务时，可以直接访问http://localhost:8500/borrow/1 此时会通过网关访问borrow-service服务。

      而且使用原来的地址http://localhost:8301/borrow/1 也可以访问。

路由过滤器

路由过滤器支持以某种方式修改传入的HTTP请求或返回的HTTP响应，路由过滤器的范围是某一个理由，跟之前的断言一样。Spring Cloud Gateway 内置很多的路由过滤器。

比如我们希望在请求到达时，在请求头中添加一些信息再转发给我们的服务，这时候就可以使用路由过滤器来完成，只需要对配置文件进行修改：

spring:
  application:
    name: gateway-service
  cloud:
    gateway:
      # 配置路由，这是一个列表
      routes:
      - id: borrow-service  # 路由名称
        uri: lb://borrow-service # 路由的地址，lb表示使用负载均衡到微服务。也可以使用HTTP正常转发
        predicates: # 路由规则，断言什么请求会被路由
        - Path=/borrow/** #只要是访问这个路径，一律都都被路由到上面指定的服务
      # 继续添加新的路由配置，这里以书籍管理服务为例
      - id: book-service
        uri: lb://book-service
        predicates:
        - Path=/book/**
        filters: # 添加过滤器
          # 添加请求头信息
        - AddRequestHeader=Test, HelloWorld!

此时通过网关访问book-service服务，会自动给请求头添加Test=HelloWorld! 信息。

访问地址是：http://localhost:8500/book/1

除了针对某一个路由配置过滤器之外，也可以自定义全局过滤器。但是需要我们编写代码，比如要实现拦截没有携带指定请求参数的请求（在gateway网关项目中编写一个类实现GlobalFilter接口）：

@Component
public class TestFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 先获取ServerHttpRequest 对象，这里不是HttpServletRequest
        ServerHttpRequest request = exchange.getRequest();
        // 获取所有请求的参数
        MultiValueMap<String, String> queryParams = request.getQueryParams();
        // 判断是否包含test参数
        List<String> test = queryParams.get("test");
        if (test != null && test.contains("1")) {
            // 将ServerWebExchange对象传递到下一个过滤连
            return chain.filter(exchange);
        }else{
            // 不再向下传递，直接返回响应
            return exchange.getResponse().setComplete();
        }
    }
}

然后重启gateway服务即可生效。

过滤器可以存在多个，我们可以指定过滤器之间的顺序，需要编写一个类，实现Ordered接口：

@Component
public class TestFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 先获取ServerHttpRequest 对象，这里不是HttpServletRequest
        ServerHttpRequest request = exchange.getRequest();
        // 获取所有请求的参数
        MultiValueMap<String, String> queryParams = request.getQueryParams();
        // 判断是否包含test参数
        List<String> test = queryParams.get("test");
        if (test != null && test.contains("1")) {
            // 将ServerWebExchange对象传递到下一个过滤连
            return chain.filter(exchange);
        }else{
            // 不再向下传递，直接返回响应
            return exchange.getResponse().setComplete();
        }
    }

    // 指定此过滤器的优先级，值越小，优先级越高
    @Override
    public int getOrder() {
        return 0;
    }
}

order值越小，优先级越高。无论全局过滤器还是配置文件中的单个过滤器，都受到order值的影响（单个路由过滤器order值从上往下的顺序从1开始递增），最终都是按order顺序执行。当order一样是，全局过滤器优先于单独的路由过滤器。

Config配置中心

微服务项目需要部署很多个实例，每个实例都有自己的配置文件，这样手动改起来非常麻烦，这时就需要一种配置文件管理工具，集中的对配置文件进行配置。

Spring cloud Config 为分布式系统中的外部配置提供服务器端和客户端的支持。使用Config Server 集中管理所有环境中应用程序的外部配置。

无标1题

实际上 Spring Cloud Config就是一个配置中心，所有的服务都可以从配置中心取出配置，而配置中心又可以从Github远程仓库中获取云端的配置文件，这样只需要修改Github中的配置就可以对所有服务进行配置管理。

部署配置中心的步骤如下：

  1. 新建一个模块，并导入依赖：

    <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

    1. 编写启动类

      @SpringBootApplication
@EnableConfigServer
public class AppConfig
{
    public static void main( String[] args )
    {
        SpringApplication.run(AppConfig.class, args);
    }
}

      1. 编写配置文件

        server:
  port: 8700
spring:
  application:
    name: config-service
eureka:
  # 修改客户端设置
  client:
    # 指向eureka服务端
    service-url:
      defaultZone: http://localhost:8801/eureka,http://localhost:8802/eureka

  2. 创建一个git本地仓库,然后再文件夹中创建一些配置文件，名称最好是【服务名称】-【环境】.yml.

    然后将配置信息写入配置文件中，然后提交文件。

    1. 修改git配置信息

      spring:
  application:
    name: config-service
  cloud:
    config:
      server:
        git:
          # 这里是本地仓库地址，远程仓库的话直接填写远程仓库地址http://git....
          uri: file://D:/1_ali/code/springCloudConfig
          # 设置默认分支
          default-label: master

      然后启动config服务，可通过以下格式访问：

      客户端配置

      现在可以从服务器端读取配置，可以删除本地的application.yml文件（也可以不删除，这样服务器配置和本地配置都会加载），改用bootstrap.yml(在application.yml之前加载)。

      1. 先在微服务模块引入相关依赖：

        <dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>

        1. 编辑bootstrap.yml文件内容：

          spring:
  cloud:
    config:
      # 名称，其实就是文件名称
      name: book-service
      # 配置服务器的地址
      uri: http://localhost:8700
      # 环境
      profile: dev
      # 分支
      label: master

      2. 启动服务即可生效。

      微服务CAP原则

      CAP原则又称CAP定理，指在一个分布式系统中，存在Consistency（一致性）、Availability（可用性）、Partition tolerance(分区容错性)，三者不可同时保证。最多只能保证其中的两者。

      一致性（C）：分布式系统中的所有数据备份，在同一时刻都是同样的值（所有节点无论何时访问都能拿到最新的值）

      可用性（A）: 系统中非故障节点收到的每个请求都必须得到响应

      分区容错性（P）: 分布式系统中，节点之间的网络是连通的，然而可能因为一些故障（网络丢包），使节点之间不连通，导致整个网络分成了几块区域，数据就散布在了这些不联通的区域中（这样可能会导致某些分区节点的数据访问失败，我们需要容忍这些不可靠的情况）。

      总的来说，数据存放的节点越多，分区容忍性越高，但是复制更新的次数就越多，一致性就会降低。同时为了保持一致性，更新所有节点数据所需要的时间就越长，那么可用性就会降低。

      所以说，只能存在以下三种方案：

      选型 特点 典型系统 适用场景
      CP 分区时强一致，但可能拒绝请求（不可用） ZooKeeper、etcd、HBase 金融、支付、配置中心
      AP 分区时高可用，但数据可能不一致（最终一致） Cassandra、DynamoDB、Redis 集群 电商、社交、缓存
      CA 放弃 P，仅在无分区时同时满足 C 和 A 单机数据库、小型局域网 非分布式、无网络风险场景
posted @ 2026-03-20 11:51  NE_STOP  阅读(58)  评论(0)    收藏  举报