微服务 fegin 404

背景

今天上班手头没有什么事情,自己又搭建了一次微服务框架,采用eureka zuul 在搭建上遇到了几个问题,在此记录一下。

问题一 fegin rpc调用不成功

我模拟搭建了一个订单服务和会员服务。
在两个服务的application.yml 文件中我都添加了服务的上下文路径
在这里插入图片描述

在这里插入图片描述
模拟订单服务向会员服务获取会员信息。

会员服务
在这里插入图片描述
订单服务
在这里插入图片描述

在这里插入图片描述

依次 启动eureka member 和order服务。访问eureka
在这里插入图片描述
说明两个服务搭建没有问题。
然后访问订单服务 http://127.0.0.1:8200/yangyang-order/getMemberByOrder
这时发现报错了
在这里插入图片描述
订单服务控制台打印错误404提示
在这里插入图片描述

分析

说明fegin 没有找到。看看会员服务getMember这个接口是否能够访问。
http://127.0.0.1:8100/yangyang-member/getMember
在这里插入图片描述
接口是没有问题的为什么fegin 访问不了呢。
报错404 说明访问路径有问题 访问会员接口路径http://127.0.0.1:8100/yangyang-member/getMember 猜想是不是上下文路径影响的,
去掉会员服务配置文件的上下文路径 重启
在这里插入图片描述
在此访问http://127.0.0.1:8200/yangyang-order/getMemberByOrder
在这里插入图片描述
ok了,果然是上下文引起的。 虽然问题解决了,但是这不是我想要的,因为服务多了难免接口名会起重复,虽然端口或者ip 可以区分,但是区分是哪个服务的接口还是不是很方便,有没有上下文路径存在fegin还是可以访问呢?
然后看一下@FeignClient
在这里插入图片描述
猜测一下这里表述的前缀是否可以放上下文名称呢,心动不如行动,尝试一下

打开注释
在这里插入图片描述
** 在订单服务的@FeignClient 中添加path属性**
在这里插入图片描述
** 重启 在次访问**
在这里插入图片描述
完美解决!!。

Fegin Token统一认证是一种将微服务架构中的认证流程整合和统一管理的解决方案。在微服务架构中,每个服务都需要进行认证和授权操作,传统的方式是在每个服务中都嵌入认证流程,这样会导致代码重复和维护困难。Fegin Token统一认证提供了一种解决方案,通过将认证和授权流程独立出来,让每个微服务只需要调用认证服务获取令牌即可。 Fegin Token统一认证的核心概念是令牌。在整个认证流程中,首先用户提供用户名和密码,认证服务对用户进行验证,并生成一个令牌。然后,其他微服务调用时只需要携带该令牌,认证服务会对令牌进行验证,并返回结果。这样,每个微服务都可以通过令牌来确认用户的身份和权限。 Fegin Token统一认证的优点首先是减少了重复代码的编写和维护工作量。由于整个认证流程被独立出来,每个微服务不再需要自己实现认证逻辑,只需要调用认证服务即可。其次,这种统一的认证方式提高了系统的灵活性和可扩展性。如果有新的认证方式需要添加,只需要在认证服务中进行修改,而不需要修改每个微服务。 当然,Fegin Token统一认证也存在一些挑战和注意事项。首先,认证服务的性能和可用性对整个系统至关重要,如果认证服务出现故障或性能瓶颈,将影响到所有微服务的正常运行。因此,认证服务的设计和部署需要特别关注。另外,令牌的生成和验证过程需要进行一定程度的加密和安全保护,以防止令牌被窃取或篡改。 综上所述,Fegin Token统一认证是一种将微服务架构中认证流程统一管理的解决方案,通过将认证和授权流程独立出来,提供了代码复用和灵活性的优势。但是,在实际应用中需要注意保证认证服务的性能和安全性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值