在issues#6899中,在2.7.11版本中的dubbo-cluster/src/main/java/org/apache/dubbo/rpc/cluster/support/ClusterUtils.java 增加了以下代码
if (map.containsKey(GENERIC_KEY)) { copyOfLocalMap.remove(GENERIC_KEY); }
关于改动的解释无法理解: GenericKey should as GROUP_KEY, VERSION_KEY, If provider side contains it, use provider side's.
该改动导致当providerURL的generic为false时,URL的generic会被设为为false(在改动前,URL的generic会被设置为true) 不太理解这个改动是正常行为还是BUG。
经过这个fix,如果provider url里面generic=false, 但是consumer端是泛化调用generic=true, 但最终merge之后generic以服务端为准,会=false,好像跟实际情况不符合了,这个是by design吗?
原提问者GitHub用户18205097282
这里的 generic 需要区分几个场景。 generic 是泛化调用的 key,分为消费端泛化调用和服务端泛化实现两种。
消费端泛化的场景是消费端不依赖具体实现接口,而服务端拥有具体接口实现。这个时候消费端可以使用 GerenicService 进行请求,Dubbo 会在服务端将请求信息进行反序列化为具体实现接口的参数。 服务端泛化的场景是服务端不依赖具体具体实现接口,服务端在业务侧实现 GerenicService 接口,消费端可选依赖具体实现接口。这个时候,如果消费端是使用 GerenicService 进行请求的会直接把请求参数发送给服务端,而如果消费端使用的是具体业务的实现接口,那么消费度端会将参数转换为 GerenicService 接口的参数以发送给服务端处理。
provider url 中的 generic 参数是指的服务端泛化的场景,这个时候消费端需要感知到服务端是否是泛化实现的,以便预先处理参数(具体实现接口的参数直接发送给服务端,服务端会报类找不到的异常)。
consumer 端配置的泛化是对应的消费端泛化的场景,主要是控制生成的代理类是否为 GerenicService。实际上即使消费端配置 generic 为 false,生成的代理类也会实现 GerenicService 接口,业务可以直接强制转型使用。
原回答者GitHub用户AlbumenJ
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践,通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式,助力制造业企业高效上云,实现系统稳定、应用敏捷智能。拥抱云原生,让创新无处不在。