本身框架底层的所有RPC使用的dubbo interface都是同一个,有好的方案进行自定义熔断吗,目前只支持interface和method配置
好的,感谢回复哦。 我目前的调用链路是,前置->中心服务,因为底层是通过公司框架组成,前置通过dubbo调用中心服务时候,是统一使用一个接口类进行的,就像如图所示,
<dubbo:reference id="U0001" group="U0001" interface="com.service.FlowService" version="${dubbo.registry.version}"/> <dubbo:reference id="U0002" group="U0002" interface="com.service.FlowService" version="${dubbo.registry.version}"/> <dubbo:reference id="U0003" group="U0003" interface="com.service.FlowService" version="${dubbo.registry.version}"/> <dubbo:reference id="U0004" group="U0004" interface="com.service.FlowService" version="${dubbo.registry.version}"/>
如果熔断时候通过这个interface进行,还会导致所有RPC接口出现异常,应该按照group进行熔断较好,所以想寻求下大神的建议
原提问者GitHub用户sq-young2
Dubbo 按 group 和 version 维度进行详细划分的流量治理,Sentinel 目前其实也是支持的,启动参数加上 -Dcsp.sentinel.dubbo.interface.group.version.enabled=true 即可让 Dubbo 埋点资源名带上 group 和 version。
原回答者GitHub用户sczyh30
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云拥有国内全面的云原生产品技术以及大规模的云原生应用实践,通过全面容器化、核心技术互联网化、应用 Serverless 化三大范式,助力制造业企业高效上云,实现系统稳定、应用敏捷智能。拥抱云原生,让创新无处不在。