微服务之间的拦截器令牌传递问题

微服务之间的认证(令牌传递)

在使用拦截器进行微服务之间的令牌传递时,我在获取当前线程所有的request属性数据时遇到了 attributes始终为空的情况,经过反复检查代码排查逻辑,仍找不到问题所在。
最终我在琢磨hystrix时发现:如果使用Feign并开启熔断,则默认会采取线程池隔离,而feign调用和请求的线程不属于同一个线程,无法获取请求的线程数据,最终会导致无法获取请求的线程数据,会造成空指针异常。

我们知道微服务与微服务之间实现认证,只需要将用户传递的令牌Authorization传递给其他微服务即可。如果微服务之间相互调用采用的是Feign模式,可以创建一个拦截器(RequestInterceptor ),每次执行请求之间,将令牌添加到头文件中即可传递给其他微服务,代码如下

public class FeignInterceptor implements RequestInterceptor {

    @Override
    public void apply(RequestTemplate requestTemplate) {
        try {
            //使用RequestContextHolder工具获取request相关变量
            ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
            if (attributes != null) {
                //取出request
                HttpServletRequest request = attributes.getRequest();
                //获取所有头文件信息的key
                Enumeration<String> headerNames = request.getHeaderNames();
                if (headerNames != null) {
                    while (headerNames.hasMoreElements()) {
                        //头文件的key
                        String name = headerNames.nextElement();
                        //头文件的value
                        String values = request.getHeader(name);
                        //将令牌数据添加到头文件中
                        requestTemplate.header(name, values);
                    }
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

那么如果微服务之间如果开启了熔断限流,此时则会出现空指针异常

在这里插入图片描述

解决方案:hystrix隔离策略换为SEMAPHORE(信号量隔离)

对比一下两种隔离策略的区别:
在这里插入图片描述

### 若依微服务框架中的Token过滤器实现与配置 #### 配置全局Token过滤器 为了在若依微服务架构中实施全局的Token验证机制,可以通过定义自定义过滤器来完成这一目标。此过程涉及创建一个继承`GatewayFilter`类并重写其方法的新类[^1]。 对于组件注册而言,在Spring环境中存在两种主要的方式: - **通过注解方式**:利用`@Component`标记自定义过滤器类,使其成为Spring容器管理下的bean实例。 - **通过Java Config方式**:编写带有`@Configuration`标注的配置类,并在其内部声明返回特定类型的@Bean方法,这里是指向`TokenFilter`对象的方法。 ```java @Configuration public class FilterConfig { @Bean public TokenFilter tokenFilter() { return new TokenFilter(); } } ``` 上述代码片段展示了如何使用Java Config模式将`TokenFilter`注入到IoC容器内。 #### 解析Token逻辑 当请求到达网关层时,由预先设定好的过滤器负责拦截这些HTTP调用并对其中携带的身份令牌进行解析操作。具体来说就是读取Authorization头部字段里的JWT字符串内容,接着依据预设密钥对其进行解码处理以获取载荷信息(payload),进而决定是否允许访问下游资源API接口[^3]。 如果解析成功且有效,则继续执行后续业务逻辑;反之则立即终止当前事务并向客户端反馈相应的错误提示消息,比如401 Unauthorized状态码表示未经身份验证无法获得授权。 #### 多模块协作案例 考虑到实际应用场景可能会更加复杂多变,例如后端生成图形验证码的功能被放置于gateway入口处,而具体的校验工作却是在独立的安全认证子系统(auth service)里完成。此时就需要确保两个不同位置上的filter能够协同作业——即先经过一次初步筛选后再传递给专门负责安全性的中间件去做进一步审核[^2]。 另外值得注意的是,在整个过程中还可能涉及到其他辅助性质的过滤单元参与进来形成一条完整的责任链结构,像白名单路径匹配(`AuthFilter`)以及图片验证码有效性确认(`ValidateCodeFilter`)都是常见的例子[^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值