十年老IT知识分享 – spring cloud gateway

这是什么

在单体应用的架构中, 我们都习惯用Nginx 作为反向代理, 以实现高可用架构. 架构图类似这样:

image.png

gateway作用类似这样. 通过设计一层gateway, 后面就可以挂n多个微服务, 不用考虑调用的是哪个微服务, gateway 都会帮你做好.

那么它和Nginx 有啥区别呢? 区别主要在:

  • 它是spring cloud生态的产品, 和spring 天然契合
  • 它的功能比Nginx 更多, 神马安全,监控/指标,和限流基本都是配置式实现. 而Nginx 要自己写脚本.
  • 它的性能比Nginx 稍弱. 如果只是路由到微服务, 用它更好. 如果需要提供静态资源, 那么还是Nginx更好.
  • 在前后端分离的架构设计中, 一般都会把他们共用. 例如我司用Vue做前端, 那么就是Vue -> Nginx -> Gateway -> 微服务 这样子的设计架构.

如下图:

image.png

(图形来自于网络, 感谢作者: [https://lzyz.fun/bloglist/nginxs-

gateway/](https://links.jianshu.com/go?to=https%3A%2F%2Flzyz.fun%2Fbloglist%2Fnginxs-

gateway%2F) )

关于更多的功能介绍会在代码里体现.

gateway 工程主要代码介绍

工程在这里: [https://gitee.com/xiaofeipapa/spring-cloud-

demo](https://links.jianshu.com/go?to=https%3A%2F%2Fgitee.com%2Fxiaofeipapa%2Fspring-

cloud-demo)

本章工程目录是: gateway-demo

代码结构图如下:

image.png

启动类代码

package org.xiaofeipapa.feimall.backGateway;

import org.springframework.boot.SpringApplication;

import org.springframework.boot.autoconfigure.EnableAutoConfiguration;

import org.springframework.boot.autoconfigure.SpringBootApplication;

import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;

import org.springframework.cloud.client.discovery.EnableDiscoveryClient;

@SpringBootApplication

@EnableAutoConfiguration(exclude={DataSourceAutoConfiguration.class})

@EnableDiscoveryClient

public class BackGatewayApplication

{

    public static void main( String[] args )

    {

        SpringApplication.run(BackGatewayApplication.class, args);

    }

}

可以看到启动类代码和普通spring boot 工程的启动类代码区别不大, 也就是加了 @EnableDiscoveryClient 这个注解.

主要的实现功能在配置文件

注册到 Consul

打开 bootstrap.yml , 这是注册到Consul的配置文件. 和其他工程没什么区别

spring:

  application:

    name: back-gateway

  cloud:

    consul:

      host: localhost

      port: 8500

      discovery:

        # 健康检查 一定要配置 结合 spring-boot-starter-actuator 使用

        health-check-path: /actuator/health

        health-check-interval: 10s

实现路由功能

打开 application.yaml, 可以看到:

spring:

  profiles:

    active: dev

  cloud:

    gateway:

      routes:

        - id: user_route
          uri: lb://user-api
          predicates:
            - Path=/api/user/**
          filters:
            - RewritePath=/api/user/(?<segment>.*),/$\{segment}

        - id: order_route
          uri: lb://order-api
          predicates:
            - Path=/api/order/**
          filters:
            - RewritePath=/api/order/(?<segment>.*),/$\{segment}

        #...省略其他配置项

别看配置文件花里花哨, 其实很好理解:

  • -id: 表示一个唯一的名称. 不同service 的id 必须不同.
  • uri: lb 表示 Load balance 的意思. user-api 是我们之前在Consul 注册的服务名称(并且该服务可能有多个实例). 这一整段表示: gateway 会自动查找可用的实例以提供服务, 不用你操心.
  • predicates: 表示 uri的路径. 如果符合这个uri, 才会进行上述调用
  • filters : gateway 会有一系列的filter 对url 进行操作. 这里是一个简单操作: 将uri 重写. 这些概念如果熟悉springmvc 就会很熟悉, 不再赘述.

刚开始的时候不熟悉, 其实用久了也就是复制粘贴. 慢慢再理解加深下印象.

启动测试

现在, 在idea里启动 orderApi工程, 并且在命令行里启动另一个实例(实例命令如下):

# 请记得将maven/bin配置到环境路径

mvn package 

java -jar -Dspring.profiles.active=inst2  target/orderApi-0.0.1-SNAPSHOT.jar

启动 gateway 工程. 启动完毕之后, 你应该在Consul 里看到这样的服务:

image.png

用浏览器访问 localhost:10000/api/order/hello , 你就会看到如下字样:

image.png

如果你再次敲击浏览器的回车, 就会看到这样:

image.png

多次敲击浏览器的回车, 你会发现 11000 和 11003 交替出现. 这是很正常的, spring cloud 集成了 ribbon,

默认的负载均衡策略就是轮询. 如果你想了解更多的策略, 查手册改写这个工程即可.

正文完