聊聊 dubbo 协议 2
在《聊聊dubbo协议》中介绍了 attachments 在 consumer 和 provider 间的传递情况,有个疑问没有给出答案。
为什么 2.7.x 版本的 dubbo 不支持 provider 端向 consumer 端回传隐式参数呢?今天的续集将揭晓答案。
抓包确定是 provider 没发还是 consumer 丢掉
以下测试基于 dubbo 2.7.6 版本
在 provider 端加入下面的代码
运行 provider,并用 consumer 不断地调用,同时进行抓包
可以看到 provider 端将我们的参数回传了回去,说明是 consumer 端将数据“弄丢了”
分析 2.6.x 与 2.7.x 代码的差别
consumer 在收到 provider 的请求返回时,处理流程如下:
DecodeableRpcResult
->decode
->case DubboCodec.RESPONSE_VALUE_WITH_ATTACHMENTS->handleAttachment
断点调试能看到,在DecodeableRpcResult
中是存在隐式参数的。
看下 2.6.x 的实现
RpcResultt 的 attachments 通过 filter 塞到 RpcContext 中去,这样我们就能拿到隐式参数了。
而在 2.7.x 中,Result 的 attachments 没有被使用到
虽然参数传了过来,但 consumer 端没有将它放入 RpcContext 中,就没法使用。
为什么 2.7.x 不处理呢?
在 2.6.x 中,dubbo 的请求返回对象只有 RpcResult
而在 2.7.x 中,RpcResult 没了,新增了 AsyncRpcResult 和 AppResponse,AppResponse 是真实的返回数据,它的 attachments 是存在隐式参数的,但它会被包装在 AsyncRpcResult 中,invoke 拿到的是 AsyncRpcResult,此时从 AppResponse 中解出数据时丢了 attachments。
2.7.x 中有一个重要的提升是对异步的支持更加友好,这里对 RpcResult 的重构应该就是丢失隐式参数的原因。
dubbo 协议如何处理协议的兼容的?
从RmiProtocol
类中能看到 dubbo 针对2.7.0
、2.6.3
两个边界进行了版本兼容
版本信息从哪里来呢?从代码中看到,从 provider 的 url 中获取参数release
(优先)、dubbo
来判断 provider 的 dubbo 版本,
dubbo://127.0.0.1:20880/com.newbooo.basic.api.SampleService?anyhost=true&application=ddog-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=com.newbooo.basic.api.SampleService&methods=getByUid&owner=roshilikang&pid=96150&release=2.7.6&retries=7&side=provider×tamp=1614235399505
这里面有些历史原因,看 dubbo 2.6.x 的源码会发现,在 2.6.3 版本之前,url 中 dubbo 参数代表的是 dubbo 的版本,而在 2.6.3 及以后的版本中,dubbo 参数代表的是 dubbo 协议的版本。
[2.5.3, 2.6.3)
版本中,dubbo 版本与 dubbo 协议没有分开,都是用 url 上的 dubbo 参数,值是对应的版本号,取值范围是>=2.0.0 && <=2.6.2
[2.6.3, 2.7.0)
版本,无法从 provider 注册的 url 上看出 dubbo 版本,dubbo 协议版本是从 url 的 dubbo 参数获取,固定为2.0.2
2.7.0
之后的版本,dubbo 版本在 provider 的 url release 参数上,dubbo 协议版本在 dubbo 参数上,目前还是 2.0.2
最后
通过这次分析知道了 2.7.x 的 dubbo 为什么 provider 不能带回隐式参数了,这应该是个 bug。
关于作者:专注后端的中间件开发,公众号"捉虫大师"作者,关注我,给你最纯粹的技术干货
版权声明: 本文为 InfoQ 作者【捉虫大师】的原创文章。
原文链接:【http://xie.infoq.cn/article/889cd0c5163e876d6b2d4d2c3】。文章转载请联系作者。
评论