当前位置： 首页>后端>正文

第2篇-使用spring cloud gateway

后端2024-05-03 11:55:53

spring cloud gateway 基础知识

这是什么

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


第2篇-使用spring cloud gateway,第1张

gateway作用类似这样. 通过设计一层gateway, 后面就可以挂n多个微服务, 不用考虑调用的是哪个微服务, gateway 都会帮你做好. 那么它和Nginx 有啥区别呢区别主要在:

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

如下图:

第2篇-使用spring cloud gateway,第2张

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

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

gateway 工程主要代码介绍

工程在这里: https://gitee.com/xiaofeipapa/spring-cloud-demo
本章工程目录是: gateway-demo

代码结构图如下:


第2篇-使用spring cloud gateway,第3张

启动类代码

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 里看到这样的服务:


第2篇-使用spring cloud gateway,第4张

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


第2篇-使用spring cloud gateway,第5张

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


第2篇-使用spring cloud gateway,第6张

多次敲击浏览器的回车, 你会发现 11000 和 11003 交替出现. 这是很正常的, spring cloud 集成了 ribbon, 默认的负载均衡策略就是轮询. 如果你想了解更多的策略, 查手册改写这个工程即可.

测试性能

(如果你是windows 系统, 请自行安装 apache ab )

ab -n50000 -c5000 http://localhost:10000/api/order/hello

在我的电脑上, 第一次访问平均用时 3900 ms 左右, 第二次及以后的访问都在900ms. 这说明两个问题. 一, gateway 需要预热. 二, 预热完成之后, 性能还是不错的. (看了一下内存占用, 好家伙, 短时间增加了500m)

基础的gateway 教程就结束了. 下一章开始总结限流, 熔断这些高级知识.


https://www.xamrdz.com/backend/3m51941278.html

相关文章：