1.思考
1.问题点
由于Dubbo的配置的优先级问题，导致消费方的配置会将服务提供方的配置覆盖，而在默认的容错策略下会启动fail-over策略。这就会在消费方配置重试机制不合理或者使用默认规则但是短时间流量激增并且provider应用提供的对应dubbo服务rt较长的情况下会出现服务提供方雪崩问题的出现。然后后续依赖于这个Dubbo服务的其他服务消费方也会收到波及。
2.思路
1.想到的解决方案
1.首先针对部分配置重新加载，加载策略自定义
2.在服务消费端，做好服务监控和保护
3.在服务提供端，增加服务保护
2.核心实现逻辑
1.主要依赖于dubbo开放各种扩展spi，这边目前采用拦截扩展spi
3.具体实现逻辑
1流程图
2.技术实现
a.前置拦截器：调用基于保护策略的执行器（拦截器默认在服务提供方可用，因为默认是单机配置，核心配置跟随服务提供的应用走）
b.后置拦截器：发生异常后的打标（打标只在消费方生效，因为这边默认是提供方服务可用
2.基于时间做消费方的被动下线、上线
3.基于消费方的调用目标、模式、参数、版本号、上线时间等来生成令牌，不记录消费方机器ip，默认不同机器在相同参数、版本等都一致的情况下调用结果一致。
4.提供扩展执行器注解,在服务上线时可以选择配置扩展的执行模式
5.使用方式
1.引入依赖、服务提供方增加配置
2.在提供的服务商配置指定的降级执行器
3.编写执行器，注意降级目标方法，则编写同名，同参数方法，如果是抛出异常则是原方法名+Exception+同参数
测试代码地址 dubbo-protect
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
