SpringCloud GateWay 微服务网关

简介

Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0,Spring Boot 2.0 和 Project Reactor 等技术开 发的网关,旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式,统一访问接口。Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关,目标是替代 Netflix ZUUL,其不仅提供统一的路 由方式,并且基于 Filter 链的方式提供了网关基本的功能,例如:安全,监控/埋点,和限流等。它是基 于Nttey的响应式开发模式。

网关搭建案例

创建工程导入依赖

在项目中添加新的模块 shop_gateway_server ,并导入依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
注意SpringCloud Gateway使用的web框架为webflux,和SpringMVC不兼容。引入的限流组件是 hystrix。redis底层不再使用jedis,而是lettuce。

配置启动类

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

编写配置文件

创建application.yml配置文件

server:
  port: 8045

spring:
  application:
    name: shop_gateway_server
  cloud:
    gateway:
      routes:
        - id: shop-service-order
          uri: http://127.0.0.1:9002
          predicates:
            - path=/product/**
  • id:我们自定义的路由 ID,保持唯一
  • uri:目标服务地址
  • predicates:路由条件,Predicate 接受一个输入参数,返回一个布尔值结果。该接口包含多种默认方法来将 Predicate 组合成其他复杂的逻辑(比如:与,或,非)。
  • filters:过滤规则

上面这段配置的意思是,配置了一个 id 为 shop-service-order 的路由规则,当访问网关请求地址以 order 开头时,会自动转发到地址: http://127.0.0.1:9002/

路由规则

Spring Cloud Gateway 的功能很强大,上面案例只是使用了 predicates 进行了简单的条件匹配,其实 Spring Cloud Gataway 帮我们内置了很多 Predicates 功能。在 Spring Cloud Gateway 中 Spring 利用 Predicate 的特性实现了各种路由匹配规则,有通过 Header、请求参数等不同的条件来进行作为条件 匹配到对应的路由。

After

这个Predicate工厂的实现类是AfterRoutePredicateFactory,使用一个时间参数,如果当前请求的时间在配置的该时间之后,此断言才会返回true。在application.yml中如下配置所示:

spring:
  cloud:
    gateway:
      routes:
        - id: after_route
          uri: http://127.0.0.1:9002
          predicates:
            - After=2018-03-18T17:32:58.129+08:00[Asia/Shanghai]

注意这个类使用的时间类是ZonedDateTime,表示ISO-8601日历系统中具有时区的日期时间,所以在application.yml中的时间配置格式只能是:2017-01-20T17:42:47.789-07:00[America/Denver],字符串的时间格式转化为ZonedDateTime使用的是StringToZonedDateTimeConverter类

Before

这个Predicate工厂的实现类是BeforeRoutePredicateFactory,它和AfterRoutePredicateFactory的实现基本上是一致的,在application.yml中的配置如下所示:

spring:
  cloud:
    gateway:
      routes:
        - id: before_route
          uri: http://127.0.0.1:9002 
          predicates:
            - Before=2018-03-18T17:32:58.129+08:00[Asia/Shanghai]

如果当前请求的时间在配置的时间之前,此断言返回true,网关将请求路由到http://127.0.0.1:9002网站。否则,返回404。

Between

这个Predicate的工厂实现类是BetweenRoutePredicateFactory,它有两个参数,datatime1,datetime2,在application.yml中的配置如下:

spring:
  cloud:
    gateway:
      routes:
        - id: between_route
          uri: http://127.0.0.1:9002
          predicates:
            - Between=2017-01-20T17:42:47.789-07:00[America/Denver], 2017-01-21T17:42:47.789-07:00[America/Denver]

当请求网关的时间在datatime1之后,在datetim2之前时,这个断言返回true,会将请求路由到http://127.0.0.1:9002。这个断言对于维护一个时间窗口很有用。比如限制在基某段时间内开启的活动,非这个时间段不可以访问等。

Cookie

这个Predicate工厂的实现类是CookieRoutePredicateFactory,它有两个参数,一个是name,另一个是正则表达式。在application.,yml中的配置如下所示:

spring:
  cloud:
    gateway:
      routes:
        - id: cookie_route
          uri: http://127.0.0.1:9002
          predicates:
            - Cookie=username, wgslcuky
            

如果请求的Cookie中有name的值,并且根据name取出的值都匹配配置的正则表达式,这个断方就返回true,会将请求路由到http://127.0.0.1:9002。上面的配置就是表示Cookie中username的值是wgslucky时,断言返回true.

Header

这个Predicate工厂的实现类是HeaderRoutePredicateFactory,它有两个参数,一个是name,另一个是正则表达式。在application.yml中的配置如下所示:

spring:
  cloud:
    gateway:
      routes:
        - id: header_route
          uri: http://127.0.0.1:9002 
          predicates:
            - Header=X-Request-Id, \d+
            

如果请求的Header里面有name的值,并且它的值与配置的正则表达式匹配,则断言返回true,如果没有配置正则表达式的值,断言也是返回true(断方只检测带正则表达式的配置),将会把请求路由到http://127.0.0.1:9002。上面的配置示例表示Header中必须有X-Request-Id,且它的值必须是数字。

Host

这个Predicate的工厂的实现类是HostRoutePredicateFactory,这有一个参数,这个参数是一人List列表,它可以包含多个主机名字匹配的样式。它遵循Ant的样式风格,以点(.)分隔。在application.yml中的配置如下所示:

spring:
  cloud:
    gateway:
      routes:
      - id: host_route
        uri: http://127.0.0.1:9002 
        predicates:
        - Host=*.xxxx.cn,{sub}.nzblog.cn

上面示例中Host对应的URI模板变量同样也支持{sub}.nzblog.cn格式的配置
如果请求的host是以xxxx.cn、nzblog.cn结尾,那么断言返回true,将请求路由到http://127.0.0.1:9002

在断方工厂中会提取上面配置中Host对应的URI模板变量,(比如上面的sub),把匹配的URI放到一个Map中,这个Map会被添加到ServerWebExchange.getAttributes(ServerWebExchangeUtils.URI_TEMPLATE_VARIABLES_ATTRIBUTE)的属性集中。可以在后面的Gateway Filter工厂类使用。

有一个方法可以方便的访问这些值,如下面代码所示:

Map<String, String> uriVariables = ServerWebExchangeUtils.getPathPredicateVariables(exchange);
String segment = uriVariables.get("sub");

Method

Rest请求风格的接口内往往会存在多种请求方式的接口,如果我们的接口只允许POST请求访问,那么配置如下所示:

spring:
  cloud:
    gateway:
      routes:
      - id: method_route
        uri: http://127.0.0.1:9002 
        predicates:
        - Method=POST

如果请求的访问方式是以POST访问的,那么断言返回true,将请求路由到http://127.0.0.1:9002

Path

Spring Cloud Gateway提供了请求路径变量方式匹配转发,如下所示:

spring:
  cloud:
    gateway:
      routes:
      - id: path_route
        uri: http://127.0.0.1:9002
        predicates:
        - Path=/foo/{segment},/bar/{segment}

在上面配置中{articleId}是一个路径变量,可以是任意值,匹配/article/1/article/abc

Query

这个是参数路由断言工厂,它的实现类是QueryRoutePredicateFactory,它有两个参数,一个是参数(param),这个是必须的,另一个是可选参数,是一个正则表达式

spring:
  cloud:
    gateway:
      routes:
      - id: query_route
        uri: http://127.0.0.1:9002
        predicates:
        - Query=baz,ba

如果请求的参数中包含baz参数且它的值为ba,断言将返回true,并将请求路由到http://127.0.0.1:9002网站

RemoteAddr

这个是远程地址路由断言工厂,它的实现类是RemoteAddrRoutePredicateFactory,它有一个List列表的参数,这些参数是CIDR-notation(IPv4和IPv6)的地址字符串,比如192.168.0.1/16(192.168.0.1是ip地址,16是一个子网掩码)

spring:
  cloud:
    gateway:
      routes:
      - id: remoteaddr_route
        uri: http://127.0.0.1:9002
        predicates:
        - RemoteAddr=192.168.0.1/24

如果请求的客户端的ip地址是192.168.0.1192.168.0.24的范围,此断言返回true,并将请求路由到http://127.0.0.1:9002网站。比如192.168.0.6。

动态路由

和zuul网关类似,在SpringCloud GateWay中也支持动态路由:即自动的从注册中心中获取服务列表并 访问。

添加注册中心依赖

在工程的pom文件中添加注册中心的客户端依赖(这里以Eureka为例)

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

配置动态路由

修改 application.yml 配置文件,添加eureka注册中心的相关配置,并修改访问映射的URL为服务名称

server:
  port: 8046

spring:
  application:
    name: shop_gateway_server
  cloud:
    gateway:
      routes:
        - id: shop-service-order
          uri: lb://shop-service-order #服务名称
          predicates:
            - Path=/order/**

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka/
  instance:
    prefer-ip-address: true #使用ip注册
    instance-id: ${spring.cloud.client.ip-address}:${server.port} #向注册中心中注册的服务id
uri : uri以 lb: //开头(lb代表从注册中心获取服务),后面接的就是你需要转发到的服务名称

转发路径重写

在SpringCloud Gateway中,路由转发是直接将匹配的路由path直接拼接到映射路径(URI)之后,那 么在微服务开发中往往没有那么便利。这里就可以通过RewritePath机制来进行路径重写。

添加RewritePath

修改 application.yml ,添加重写规则。

spring:
  application:
    name: shop_gateway_server
  cloud:
    gateway:
      routes:
        - id: shop-service-order
          uri: lb://shop-service-order
          predicates:
            - Path=/order-api/**
          filters:
            - RewritePath=/order-api/(?<segment>.*), /$\{segment}

通过RewritePath配置重写转发的url,将/order-api/(?.*),重写为{segment},然后转发到订单微服务。比如在网页上请求http://127.0.0.1:8046/order-api/order/buy/1,此时会将请求转发到http://127.0.0.1:8046/order/buy/1
这样一来就可以定义一个前缀

过滤器

Spring Cloud Gateway除了具备请求路由功能之外,也支持对请求的过滤。和Zuul网关类似,也是通过过滤器的形式来实现的。

过滤器的生命周期

Spring Cloud Gateway 的 Filter 的生命周期不像 Zuul 的那么丰富,它只有两个:“pre” 和 “post”。

  • PRE: 这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择 请求的微服务、记录调试信息等。
  • POST:这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的 HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。

过滤器类型

Spring Cloud Gateway 的 Filter 从作用范围可分为另外两种 GatewayFilterGlobalFilter

  • GatewayFilter :应用到单个路由或者一个分组的路由上。
  • GlobalFilter :应用到所有的路由上。

局部过滤器

局部过滤器(GatewayFilter),是针对单个路由的过滤器。可以对访问的URL过滤,进行切面处理。在 Gateway中通过GatewayFilter的形式内置了很多不同类型的局部过滤器。
官方文档地址:https://cloud.spring.io/spring-cloud-static/Greenwich.SR2/single/spring-cloud.html#_gatewayfilter_factories

全局过滤器

全局过滤器(GlobalFilter)作用于所有路由,Spring Cloud Gateway 定义了Global Filter接口,用户可以自定义实现自己的Global Filter。通过全局过滤器可以实现对权限的统一校验,安全性验证等功能,并且全局过滤器也是程序员使用比较多的过滤器。

统一鉴权

开发中的鉴权逻辑:
当客户端第一次请求服务时,服务端对用户进行信息认证(登录)
认证通过,将用户信息进行加密形成 token,返回给客户端,作为登录凭证
以后每次请求,客户端都携带认证的 token 服务端对 token进行解密,判断是否有效。

代码实现

自定义一个GlobalFilter,去校验所有请求的请求参数中是否包含“token”,如何不包含请求 参数“token”则不转发路由,否则执行正常的逻辑。

@Component
public class AuthorizeFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String token = exchange.getRequest().getQueryParams().getFirst("token");
        if (StringUtils.isBlank(token)) {
            System.out.println("token is empty ...");
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
        return chain.filter(exchange);
    }

    //优先级,返回值越小优先级越高
    @Override
    public int getOrder() {
        return 0;
    }
}

网关限流

常见的限流算法

计数器

计数器限流算法是最简单的一种限流实现方式。其本质是通过维护一个单位时间内的计数器,每次请求 计数器加1,当单位时间内计数器累加到大于设定的阈值,则之后的请求都被拒绝,直到单位时间已经 过去,再将计数器重置为零

漏桶算法

漏桶算法可以很好地限制容量池的大小,从而防止流量暴增。漏桶可以看作是一个带有常量服务时间的 单服务器队列,如果漏桶(包缓存)溢出,那么数据包会被丢弃。 在网络中,漏桶算法可以控制端口的 流量输出速率,平滑网络上的突发流量,实现流量整形,从而为网络提供一个稳定的流量。
为了更好的控制流量,漏桶算法需要通过两个变量进行控制:一个是桶的大小,支持流量突发增多时可 以存多少的水(burst),另一个是水桶漏洞的大小(rate)。

令牌桶算法

令牌桶算法是对漏桶算法的一种改进,桶算法能够限制请求调用的速率,而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。在令牌桶算法中,存在一个桶,用来存放固定数量的令牌。算法中存在一种机制,以一定的速率往桶中放令牌。每次请求调用需要先获取令牌,只有拿到令牌,才可以继续执行,否则选择选择等待可用的令牌、或者直接拒绝。放令牌这个动作是持续不断的 进行,如果桶中令牌数达到上限,就丢弃令牌,所以就存在这种情况,桶中一直有大量的可用令牌,这 时进来的请求就可以直接拿到令牌执行,比如设置qps为100,那么限流器初始化完成一秒后,桶中就 已经有100个令牌了,这时服务还没完全启动好,等启动完成对外提供服务时,该限流器可以抵挡瞬时 的100个请求。所以,只有桶中没有令牌时,请求才会进行等待,最后相当于以一定的速率执行。

基于GateWayFilter的限流

SpringCloudGateway官方就提供了基于令牌桶的限流支持。基于其内置的过滤器工厂 RequestRateLimiterGatewayFilterFactory 实现。在过滤器工厂中是通过Redis和lua脚本结合的方 式进行流量控制。

导入依赖

首先在工程的pom文件中引入gateway的起步依赖和redis的reactive依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>

修改yml配置文件

在application.yml配置文件中加入限流的配置,配置如下:

spring:
  application:
    name: shop_gateway_server
  cloud:
    gateway:
      routes:
        - id: shop-service-order
          uri: lb://shop-service-order
          predicates:
            - Path=/order-api/**
          filters:
            - RewritePath=/order-api/(?<segment>.*), /$\{segment}
            - name: RequestRateLimiter
              args:
                # 使用SpEL从容器中获取对象
                key-resolver: '#{@pathKeyResolver}'
                # 令牌桶每秒填充平均速率
                redis-rate-limiter.replenishRate: 1
                # 令牌桶的总容量
                redis-rate-limiter.burstCapacity: 3

redis:
  host: localhost
  port: 6379

配置pathKeyResolver

为了达到不同的限流效果和规则,可以通过实现 KeyResolver 接口,定义不同请求类型的限流键。

@Configuration
public class KeyResolverConfiguration {

    /**
     * 基于路径的限流
     * @return
     */
    @Bean
    public KeyResolver pathKeyResolver(){
        return exchange -> Mono.just(
                exchange.getRequest().getPath().toString()
        );
    }

    /**
     * 基于请求ip地址的限流
     * @return
     */
    @Bean
    public KeyResolver ipKeyResolver(){
        return exchange -> Mono.just(
                exchange.getRequest().getHeaders().getFirst("X-Forwarded-For")
        );
    }

    /**
     * 基于用户的限流
     * @return
     */
    @Bean
    public KeyResolver userKeyResolver(){
        return exchange -> Mono.just(
                exchange.getRequest().getQueryParams().getFirst("user")
        );
    }

}

基于Sentinel的限流

Sentinel 支持对 Spring Cloud Gateway、Zuul 等主流的 API Gateway 进行限流。
从 1.6.0 版本开始,Sentinel 提供了 Spring Cloud Gateway 的适配模块,可以提供两种资源维度的限流:

  • route 维度:即在 Spring 配置文件中配置的路由条目,资源名为对应的
  • routeId 自定义 API 维度:用户可以利用 Sentinel 提供的 API 来自定义一些 API 分组

环境搭建

导入Sentinel 的响应依赖

<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-spring-cloud-gateway-adapter</artifactId>
    <version>1.6.3</version>
</dependency>

基本限流配置

@Configuration
public class GatewayConfiguration {

    private final List<ViewResolver> viewResolvers;

    private final ServerCodecConfigurer serverCodecConfigurer;

    public GatewayConfiguration(
            ObjectProvider<List<ViewResolver>> viewResolversProvider,
            ServerCodecConfigurer serverCodecConfigurer) {
        this.viewResolvers = viewResolversProvider.getIfAvailable(Collections::emptyList);
        this.serverCodecConfigurer = serverCodecConfigurer;
    }

    /**
     * 配置限流的异常处理器:SentinelGatewayBlockExceptionHandler
     */
    @Bean
    @Order(Ordered.HIGHEST_PRECEDENCE)
    public SentinelGatewayBlockExceptionHandler sentinelGatewayBlockExceptionHandler() {
        return new SentinelGatewayBlockExceptionHandler(viewResolvers, serverCodecConfigurer);
    }

    /**
     * 配置限流过滤器
     */
    @Bean
    @Order(Ordered.HIGHEST_PRECEDENCE)
    public GlobalFilter sentinelGatewayFilter() {
        return new SentinelGatewayFilter();
    }

    /**
     * 配置初始化的限流参数
     */
    @PostConstruct
    public void initGatewayRules() {
        Set<GatewayFlowRule> rules = new HashSet<>();
        rules.add(new GatewayFlowRule("shop-service-order") //路由id
                .setCount(1) //单位时间内限流阈值
                .setIntervalSec(1) //统计时间
        );
        GatewayRuleManager.loadRules(rules);
    }
}
  • 基于Sentinel 的Gateway限流是通过其提供的Filter来完成的,使用时只需注入对应的 SentinelGatewayFilter 实例以及 SentinelGatewayBlockExceptionHandler 实例即可。
  • @PostConstruct定义初始化的加载方法,用于指定资源的限流规则

网关配置

spring:
  application:
    name: shop_gateway_server
  cloud:
    gateway:
      routes:
        - id: shop-service-order
          uri: lb://shop-service-order
          predicates:
            - Path=/order-api/**
          filters:
            - RewritePath=/order-api/(?<segment>.*), /$\{segment}

到现在就配置完了,我们可以访问 http://127.0.0.1:8046/order-api/order/buy/1 一秒钟刷新多次,就可以看到效果提示 Blocked by Sentinel: ParamFlowException

自定义异常提示

当触发限流后页面显示的是 Blocked by Sentinel: FlowException。为了展示更加友好的限流提示,Sentinel支持自定义异常处理。
您可以在 GatewayCallbackManager 注册回调进行定制:
setBlockHandler :注册函数用于实现自定义的逻辑处理被限流的请求,对应接口为 BlockRequestHandler
默认实现为 DefaultBlockRequestHandler ,当被限流时会返回类似 于下面的错误信息: Blocked by Sentinel: FlowException 。

@PostConstruct
public void initBlockHandlers() {
    BlockRequestHandler blockRequestHandler = new BlockRequestHandler() {
        @Override
        public Mono<ServerResponse> handleRequest(ServerWebExchange serverWebExchange, Throwable throwable) {
            Map map = new HashMap<>();
            map.put("code", 001);
            map.put("message", "对不起,接口限流了");
            return ServerResponse.status(HttpStatus.OK).
                    contentType(MediaType.APPLICATION_JSON_UTF8).
                    body(BodyInserters.fromObject(map));
        }
    };
    GatewayCallbackManager.setBlockHandler(blockRequestHandler);
}

添加后重启项目,访问接口测试效果如下:

参数限流

上面的配置是针对整个路由来限流的,如果我们只想对某个路由的参数做限流,那么可以使用参数限流方式:

@PostConstruct
public void initGatewayRules() {
    Set<GatewayFlowRule> rules = new HashSet<>();
    rules.add(new GatewayFlowRule("shop-service-order") //路由id
            .setCount(1) //单位时间内限流阈值
            .setIntervalSec(1) //统计时间
            .setParamItem(new GatewayParamFlowItem()
                    .setParseStrategy(SentinelGatewayConstants.PARAM_PARSE_STRATEGY_URL_PARAM)
                    .setFieldName("id")
            )
    );
    GatewayRuleManager.loadRules(rules);
}

通过指定PARAM_PARSE_STRATEGY_URL_PARAM表示从url中获取参数,setFieldName指定参数名称,如果访问请求携带了指定参数(id)那么就会进行限流

自定义API分组限流

前面我们都是针对服务或者参数等,进行限流,我们还可以自定义API分组进行限流控制

@PostConstruct
private void initCustomizedApis() {
    Set<ApiDefinition> definitions = new HashSet<>();
    ApiDefinition api1 = new ApiDefinition("order-api")
            .setPredicateItems(new HashSet<ApiPredicateItem>() {{
                add(new ApiPathPredicateItem().setPattern("/order-api/order/buy/**").
                        setMatchStrategy(SentinelGatewayConstants.URL_MATCH_STRATEGY_PREFIX));
            }});
    definitions.add(api1);
    GatewayApiDefinitionManager.loadApiDefinitions(definitions);
}

请求以/order-api/order/buy/开头的都进行限流拦截
自定义API分组完成后我们需要在initGatewayRules方法内进行加载

    @PostConstruct
    public void initGatewayRules() {
        Set<GatewayFlowRule> rules = new HashSet<>();
        rules.add(new GatewayFlowRule("order-api") //这里是刚才我们自定义的API分组名称
                .setCount(1) //单位时间内限流阈值
                .setIntervalSec(1) //统计时间
        );
        GatewayRuleManager.loadRules(rules);
    }

网关高可用

高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计 减少系统不能提供服务的时间。我们都知道,单点是系统高可用的大敌,单点往往是系统高可用最大的 风险和敌人,应该尽量在系统设计的过程中避免单点。方法论上,高可用保证的原则是“集群化”,或者 叫“冗余”:只有一个单点,挂了服务会受影响;如果有冗余备份,挂了还有其他backup能够顶上。

我们实际使用 Spring Cloud Gateway 的方式如上图,不同的客户端使用不同的负载将请求分发到后端 的 Gateway,Gateway 再通过HTTP调用后端服务,最后对外输出。因此为了保证 Gateway 的高可用 性,前端可以同时启动多个 Gateway 实例进行负载,在 Gateway 的前端使用 Nginx 或者 F5 进行负载 转发以达到高可用性。

准备多个GateWay工程

我们这里是本地测试所以需要修改配置文件,修改启动端口,生产环境都是部署在不同的服务器中
修改 shop_gateway_server 的 application.yml。添加如下配置

spring:
  application:
    name: shop_gateway_server
  cloud:
    gateway:
      routes:
        - id: shop-service-order
          uri: lb://shop-service-order
          predicates:
            - Path=/order-api/**
          filters:
            - RewritePath=/order-api/(?<segment>.*), /$\{segment}
            
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/,http://localhost:8762/eureka/
  instance:
    prefer-ip-address: true #使用ip注册
    instance-id: ${spring.cloud.client.ip-address}:${server.port} #向注册中心中注册的服务id
    
---
server:
  port: 8046
spring:
  profiles: gateway01
---
server:
  port: 8047
spring:
  profiles: gateway02

通过不同的profiles配置启动两个网关服务,请求端口分别为8046和8047。

配置nginx

找到nginx.conf文件添加负载均衡配置

#配置多台服务器(这里只在一台服务器上的不同端口) 
upstream gateway {
    server 127.0.0.1:8081;
    server 127.0.0.1:8080; 
} 
#请求转向mysvr 定义的服务器列表 
location / {
    proxy_pass http://gateway; 
}

添加新评论

评论列表