Gateway 转发请求至注册中心Nacos中的服务404问题
问题描述
一次练手项目中,原本没问题并且测试过的gateway,再次转发链接的时候返回404状态码。gateway和被调用模块的日志信息中均无报错信息。
其中网关最后给出的信息是:Flipping property: login-module.ribbon.ActiveConnectionsLimit to use NEXT property: niws.loadbalancer.availabilityFilteringRule.activeConnectionsLimit = 2147483647
问题排查
网关访问出现404状态码的情况无非从这三个方面去排查:
1.网关问题
将gateway的配置转发文件改为:
server:
port: 8000
spring:
application:
name: gateway-module
cloud:
nacos:
discovery:
server-addr: localhost:8848
username: nacos
password: nacos
gateway:
httpclient:
connect-timeout: 1000
response-timeout: 5s
discovery:
locator:
enabled: false #启用DiscoveryClient网关集成的标志,可以实现服务的发现
#gateway 定义路由转发规则
routes:
#一份设定
- id: baidu #唯一标识
uri: http://www.baidu.com #访问的路径,lb://负载均衡访问固定写法,通过负载均衡调取所有设定中的一份
predicates: #谓词,判断,是否匹配。用户请求的路径是否与...进行匹配,如果匹配则可以访问,否则就404
- Path=/**
接着访问:localhost:8000 。发现跳转百度页面成功。因此转发并没有问题。于是网关端可能出现的问题还剩下 路径匹配问题。
下面是我配置的网关转发(部分):
spring:
application:
name: gateway-module
cloud:
nacos:
discovery:
server-addr: localhost:8848
username: nacos
password: nacos
gateway:
httpclient:
connect-timeout: 1000
response-timeout: 5s
discovery:
locator:
enabled: true #启用DiscoveryClient网关集成的标志,可以实现服务的发现
#gateway 定义路由转发规则
routes:
#一份设定
- id: login-module #唯一标识
uri: lb://login-module #访问的路径,lb://负载均衡访问固定写法,通过负载均衡调取所有设定中的一份
predicates: #谓词,判断,是否匹配。用户请求的路径是否与...进行匹配,如果匹配则可以访问,否则就404
- Path=/login/**
与之匹配的是注册中心Nacos中的服务下的测试api (我这边就从简了):
@RestController
public class TestController {
@RequestMapping("/login/sout")
public String sout(){
return "success";
}
}
请求的路径是:http://127.0.0.1:8000/login/sout (gateway端口是:8000,服务模块的端口是:8081)
通过比对发现,路径匹配没有问题。
2. 服务注册失败
也就是说因为服务模块向服务注册中心注册失败,导致网关查询服务中心中的服务时,并没有查找到其中含有你匹配的模块服务名称,从而导致匹配失败,返回404状态码。
于是,查看Nacos中服务发现列表(这里同样从简,只开了两个需要观测的模块):
可以看出,服务注册没有问题。
3.服务模块调用问题
也就是说,是因为服务模块中的提供的请求路径本来就返回404,访问不通。因为原先在这个模块中进行了Sa-Token的分布式鉴权,所以将Maven依赖中的Sa-Token部分全部注释,进行访问,发现访问失败。
最终排查
经过业务部分和Controller部分代码检测过后,发现并无问题。于是开始考虑是否是依赖间的冲突或者其他问题导致。此时,我注意到服务模块启动后日志中仍有Sa-Token的Logo:
这说明,依赖中的Sa-Token并没有完全去除。于是我反复再次查看依赖,发现这里的Sa-Token是由工具类中的。
在这里,我将项目中的一些工具类和实体类全部抽离,作为了一个工具模块,此工具模块中的pom文件中,因为偷懒,所以将其他模块中的pom文件中的依赖项进行拷贝复制到了工具模块的pom文件中(切记每个模块引入的依赖复制后需要仔细核对一遍)。因此其中也带有Sa-Token的相关依赖。于是在服务模块中将工具模块中的Sa-Token的相关依赖去除:
<dependency>
<groupId>com.utils</groupId>
<artifactId>utils</artifactId>
<version>0.0.1-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>cn.dev33</groupId>
<artifactId>sa-token-dao-redis-jackson</artifactId>
</exclusion>
<exclusion>
<groupId>cn.dev33</groupId>
<artifactId>sa-token-spring-boot-starter</artifactId>
</exclusion>
<exclusion>
<groupId>cn.dev33</groupId>
<artifactId>sa-token-alone-redis</artifactId>
</exclusion>
<exclusion>
<groupId>cn.dev33</groupId>
<artifactId>sa-token-core</artifactId>
</exclusion>
</exclusions>
</dependency>
再次进行测试,发现仍然访问为404异常。
于是将所有业务与Controller代码全部注释,最后只剩一个测试api返回success的字符串。进行测试后,发现仍然访问不通。
因此,想到是包没有被扫描到。于是查看启动类,找到了原因:
因为提取工具类时,参照网上的博客中的做法,在启动类上引入了:
@ComponentScan(basePackages = "com.utils")
至此原因排查结束。因为@ComponentScan 如果不设置basePackage的话 默认会扫描包的所有类,如果设置了basePackage的话,只会扫描设置路径下的包。从而导致了我们原来项目模块中的包并不会被扫描到。
改正
将启动类上的
@ComponentScan(basePackages = "com.utils")
去除即可。再次进行测试:访问 http://127.0.0.1:8000/login/sout
跳转成功!!!
总结
@ComponentScan 如果不设置basePackage的话 默认会扫描包的所有类,如果设置了basePackage的话,只会扫描设置路径下的包。从而导致了我们原来项目模块中的包并不会被扫描到。
因此以后写的时候注意一下,当然正式生产场景并不推荐你不写从而扫描所有的包,而是应该将所有需要扫描的包全部写上去。
@ComponentScan(basePackages = {})填String数组 或者 用逗号隔开的String 都可以。为了idea显示兼容一点,还是改成了 String数组