导读:最近的一个项目,要将springboot更改为dubbo
但出现了上下文信息的问题,获取不到用户信息,弄了很多办法都不成功,经过n个小时后还是用一个备用方案给解决了
项目结构
这个项目分为两个很简单的目录,就是提供者(provider)和消费者(consume)两个文件夹, 这边引用dubbo官方文档的例子: provider放入service结构,consumer放入Controller结构(这个重点)
问题现场😨及原因
这个项目造成的问题有一个前提,就是它的登录逻辑是在consumer里,其它业务逻辑在provider的service目录里(是有点离谱)。
所以问题就来了。在接口处,能获取到信息:
但是一旦进行rpc调用到service层,ok直接变为null
原因就是上面我说的前提,反过来的话,就是controller没值,而service有值。
好家伙,这个项目有几十处地方,都因为这个崩掉了,必须整改!
如何解决😕
网上看了一堆帖子,有说xml的,有说写bean的,试了好多次都是失败的,弄得人都傻了😭😭
于是只能转换思路,没想到还想到个偏方:既然consumer有数据,能不能在rpc调用的时候,把这个参数传到provider呢?于是看到官网有个上下文配置+filter过滤器的特性,刚好可以解决
文章: dubbo-上下文
先说明一下什么是上下文:这里引用官方说法
上下文信息是一次 RPC 调用过程中附带的环境信息,如方法名、参数类型、真实参数、本端/对端地址等。这些数据仅属于一次调用,作用于 Consumer 到 Provider 调用的整个流程。
至于过滤器filter,实际类似aop,需要的直接看链接吧。
所以思路是这样的: 在进行rpc调用前,实现dubbo的Filter类,在其中设置上下文信息,这样provider就可以直接接到上下文的信息,即用户信息了
好,开搞!以下流程直接复用官方文档即可,这边贴出一份
实战😠
Maven 项目结构:
java
src
|-main
|-java
|-com
|-xxx
|-XxxFilter.java (实现Filter接口)
|-resources
|-META-INF
|-dubbo
|-com.alibaba.dubbo.rpc.Filter (纯文本文件,内容为:xxx=com.xxx.XxxFilter)
XxxFilter.java:
java
@Activate(group = Constants.CONSUMER) //要求是consumer才会走这个过滤方法
public class XxxFilter implements Filter {
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
// before filter ...
Result result = invoker.invoke(invocation);
// after filter ...
return result;
}
}
META-INF/dubbo/com.alibaba.dubbo.rpc.Filter(路径要完全正确,不要txt后缀):
java
xxx=com.xxx.XxxFilter
核心来了:在XxxFilter的before filter 中,放入上下文
java
//放置用户上下文
final User user = //获取user;
if (user != null) {
invocation.getAttachments().put(
"dubboUserKey", //key
StringUtils.isBlank(userInfo)
?
JSON.toJSONString(new SysUser())
:
JSON.toJSONString(user)
);
}
这几个文件编写完,provider就可以根据RpcContext.getContext().getAttachments()方法发现数据了
原因分析
这边贴一段在网上的分析,我觉得是很有可能的:
通过报错信息反馈可以得知,是缺失了Shiro的SecurityManager组件,通过断点debug也可以证明上述观点。然而,奇怪的是同样的业务实现类,如果直接调用服务提供者是完全正常的,但是通过消费者调用服务提供者则异常。百度类似的问题,清一色的博客转载,而且大部分的解决方案都是指向关于shiro配置中没有自定义SecurityManager组件,或者是与shiro过滤器相关的解决方案,完全是不适用的。
这里我分析原因是:Shiro的机制是通过Filter的方式,对请求进行过滤限制,这里的请求通常情况下使用的是Http请求,也就是我通过postman或者前端程序通过restful的方式发送请求,这时会根据我们自定义的shiro过滤器的规则,对请求进行访问的限制。而现在通过微服务的方式,服务调用由dubbo进行接管,请求的方式也变为了rpc方式,这样的情况也就导致了消费者的请求无法被shiro的过滤器过滤
至此是解决了,但是还有个小问题,就是这样造成的网络传输会多一点数据,不算特别完美。 如果有别的好的方法,欢迎评论区评论