您现在的位置是:首页 > 技术教程 正文

前端根据域名发送请求通过nginx匹配转发至java网关gateway

admin 阅读: 2024-03-30
后台-插件-广告管理-内容页头部广告(手机)

1.图片请求展示:

2.流程阐述

当发起请求 https://test.parkidcode.net/api/asset/parkAccess/page 时,请求的处理流程如下:

  1. HTTPS请求:首先,通过HTTPS协议发送请求到 https://test.parkidcode.net/api/asset/parkAccess/page。由于域名配置了SSL证书,因此请求会被加密并发送到服务器。

  2. Nginx接收请求:Nginx作为反向代理服务器接收到这个HTTPS请求。由于请求路径以 /api/ 开头,它符合 location ^~/api/ 的配置,因此该请求将被转发到后端服务。

  3. 请求转发到Gateway:根据 proxy_pass http://park-gateway:9997/; 的配置,Nginx会将请求转发到 park-gateway 服务的 9997 端口。注意这里的 / 后缀意味着原始请求的URL路径(除了 /api/ 部分)将保持不变。因此,请求 https://test.parkidcode.net/api/asset/parkAccess/page 会被转发为 http://park-gateway:9997/asset/parkAccess/page。

  4. Gateway处理请求:park-gateway 服务接收到请求后,会根据其内部配置的路由规则进行处理。在这个例子中,Gateway的配置中有一个断言 Path=/v3/api-docs/**,这意味着它原本只匹配以 /v3/api-docs/ 开头的路径。由于你的请求路径是 /asset/parkAccess/page,它不符合这个断言,因此不会匹配到 predicates 中定义的 openapi 路由。

  5. 路由匹配问题:实际上,如果Gateway的配置只有上述的断言,那么请求 /asset/parkAccess/page 将不会匹配任何定义的路由规则,除非有其他未提及的路由配置。通常,Gateway应该有一个通配符路由或默认路由来处理不符合特定断言的请求。

  6. 请求处理与转发:一旦请求匹配到合适的路由规则(如果有的话),Gateway会根据路由规则中的配置对请求进行处理,这可能包括身份验证、限流、请求和响应处理等。然后,Gateway会将请求转发到相应的微服务实例。

  7. 微服务处理请求:最终,匹配的后端微服务会接收到来自Gateway的转发请求,并执行相应的业务逻辑,然后返回响应。

  8. 响应返回:微服务处理完请求后,将响应返回给Gateway,Gateway再根据需要将响应转发回Nginx,最终由Nginx将响应返回给客户端。

在案例中,由于请求的路径 /api/asset/parkAccess/page 不符合Gateway中定义的断言 Path=/v3/api-docs/**,因此你需要检查Gateway是否有其他匹配的路由规则。如果没有,你需要相应地调整路由配置以确保请求能够被正确路由和处理。

3.nginx和gateway配置文件

nginx配置文件

  server {
    # listen 80;
    # server_name localhost;

    #如果您使用Nginx 1.15.0及以上版本,请使用listen 443 ssl代替listen 443和ssl on
    listen 443 ssl;
    #listen 443;
    # 开启ssl
    ssl on;
    #替换你自己的域名
    server_name test.parkidcode.net parkidcode.net;
    # 配置ssl证书,替换你自己下载的nginx证书,可以是相对路径或绝对路径
    ssl_certificate /www/server/panel/vhost/nginx/cert/test.parkidcode.net.pem;
    # 配置证书秘钥,系统生成=》替换你自己下载的nginx密钥,手动填写=》需要你通过openssl生成密钥上传,
    ssl_certificate_key /www/server/panel/vhost/nginx/cert/test.parkidcode.net.key;
    # ssl会话cache
    ssl_session_cache shared:SSL:1m;
    # ssl会话超时时间
    ssl_session_timeout 5m;
    # 配置加密套件,写法遵循 openssl 标准
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
    #表示使用的TLS协议的类型
    ssl_prefer_server_ciphers on;

    gzip on;
    gzip_static on;     # 需要http_gzip_static_module 模块
    gzip_min_length 1k;
    gzip_comp_level 4;
    gzip_proxied any;
    gzip_types text/plain text/xml text/css;
    gzip_vary on;
    gzip_http_version   1.0; #兼容多层nginx 反代
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

    # 前端打包好的dist目录文件
    root /www/wwwroot/test_applet-ui;

    location ^~/api/ {
        proxy_pass http://park-gateway:9997/; #注意/后缀
        proxy_connect_timeout 60s;
        proxy_read_timeout 120s;
        proxy_send_timeout 120s;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto http;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
    }


    # 避免端点安全问题
    if ($request_uri ~ "/actuator"){
        return 403;
    }
}

  server {
    listen 8808;
    server_name localhost;

    gzip on;
    gzip_static on;     # 需要http_gzip_static_module 模块
    gzip_min_length 1k;
    gzip_comp_level 4;
    gzip_proxied any;
    gzip_types text/plain text/xml text/css;
    gzip_vary on;
    gzip_http_version   1.0; #兼容多层nginx 反代
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

    # 前端打包好的dist目录文件
    root /www/wwwroot/test_applet-ui;

    location ^~/api/upark/ {
        proxy_pass http://park-gateway:9997/asset/parkDevice/upark/; #注意/后缀
    }

    location ^~/api/ {
        proxy_pass http://park-gateway:9997/; #注意/后缀
        proxy_connect_timeout 60s;
        proxy_read_timeout 120s;
        proxy_send_timeout 120s;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto http;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
    }

    # 避免端点安全问题
    if ($request_uri ~ "/actuator"){
        return 403;
    }
}
 

gateway主配置文件

server: port: 9997 spring: application: name: @artifactId@ cloud: nacos: username: @nacos.username@ password: @nacos.password@ discovery: server-addr: ${NACOS_HOST:park-register}:${NACOS_PORT:8848} config: server-addr: ${spring.cloud.nacos.discovery.server-addr} config: import: - optional:nacos:application-@profiles.active@.yml - optional:nacos:${spring.application.name}-@profiles.active@.yml

 nacos配置中的gateway的yml配置文件

gateway:

encode-key: 'Park,kkTTyyPaKr6'

# 验证码相关配置参考: http://t.cn/A647jEdu

aj:

captcha:

cache-type: redis

water-mark: ""

jigsaw: classpath:images/jigsaw

pic-click: classpath:images/pic-click


 

# 固定路由转发配置 无修改

spring:

cloud:

gateway:

globalcors:

corsConfigurations:

"[/**]":

#注意这个设置只对 spring boot 2.4+ 有效, pigx v4.0+ ,低版本 使用 allowedOrigins: "*"

allowedOriginPatterns: "*"

allowed-methods: "*"

allowed-headers: "*"

allow-credentials: true

exposedHeaders: "Content-Disposition,Content-Type,Cache-Control"

routes:

- id: openapi

uri: lb://park-gateway

predicates:

- Path=/v3/api-docs/**

filters:

- RewritePath=/v3/api-docs/(?.*), /$\{path}/$\{path}/v3/api-docs

 

从上面的nacos中的gateway的yml配置文件中可以看到 

确实没有直接定义针对 /api/asset/parkAccess/page 路径的路由规则。然而,该请求能够成功访问 asset 微服务的 parkAccess/page 接口。这可能是由于以下几个原因:

  1. 默认路由:Spring Cloud Gateway 支持默认路由,即当没有匹配的路由规则时,请求会被转发到一个默认的 URI。在您的配置中,如果没有其他匹配的路由,请求可能会被转发到 lb://park-gateway,这是一个负载均衡服务,可能是 asset 微服务的上游服务。

  2. 服务注册与发现:如果 asset 微服务已经注册到服务注册中心(如 Eureka、Consul、Nacos 等),并且 park-gateway 配置了服务发现功能,那么 park-gateway 可能会动态地从服务注册中心获取 asset 微服务的地址,并将请求转发到该服务,即使配置中没有明确的路由规则。

  3. 重写逻辑:虽然配置中有一个重写路径的过滤器,但这个过滤器是针对 /v3/api-docs/** 路径的。对于 /api/asset/parkAccess/page 这个路径,该过滤器不会生效。因此,即使请求路径在转发过程中保持不变,也不会影响它到达正确的微服务。

  4. 网关内部逻辑:在某些情况下,网关可能包含额外的逻辑来处理未明确匹配的请求。这可能包括基于请求头、请求参数或其他条件的路由逻辑。

  5. 负载均衡机制:lb://park-gateway 表示一个负载均衡服务。如果 park-gateway 本身是一个代理服务,并且它知道如何将请求路由到 asset 微服务,那么请求可能会被转发到正确的服务实例。

为了确切了解为什么请求能够成功访问 asset 微服务,可能需要检查 park-gateway 的其他配置或实现逻辑,包括它是否配置了默认路由、服务发现功能,以及是否有额外的路由逻辑。此外,查看 park-gateway 的日志也可能提供有关请求处理过程的更多信息。

总结来说,尽管网关配置中没有明确针对 /api/asset/parkAccess/page 路径的路由规则,但由于上述原因之一或多个,请求仍然能够成功转发到 asset 微服务。

 

标签:
声明

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

在线投稿:投稿 站长QQ:1888636

后台-插件-广告管理-内容页尾部广告(手机)
关注我们

扫一扫关注我们,了解最新精彩内容

搜索