Soul的限流断路器的使用和流程

由于之前并没有使用过Hystrix，Resilience4j和sentinel中的任何一种，此处仅对三种流控和断路器插件做一个流程分析

Soul中Hystrix的使用和操作流程

• 关于soul中插件的流程前文已经说过多次了,在此不在赘述。
• 根据规则的具体选择方式。Soul构建了两个不同的操作类HystrixCommandOnThread和HystrixCommand。两个类的不同是HystrixCommandOnThread为拦截的接口建立了自己的线程池，实现了线程池的隔离。而HystrixCommand只是实现了短路器的基本功能。使用了线程池隔离之后。可以针对不同的线程使用不同的线程池配置。既区分了不同的接口和自定义配置解决不同并发程度所造成的压力。也解决了不同接口之间造成影响的问题。这两个类基本就是@HystrixCommand的各大属性的集合，Soul通过界面配置的方式实现了断路器的零侵入性。这样来说，比Hystrix直接嵌入客户端更加方便

file

• 另外在具体的断路执行run过程中使用了RxReactiveStreams.toObservable的监听来实现具体的异步监听的情况。同时追踪Hystrix源码可以看到Hystrix使用了RxJava
• Hystrix插件的使用中综合使用了建造者模式，命令模式，观察者模式。以及RxReactiveStreams响应式流式编程。

Soul中Resilience4j的使用和操作流程

• 在Resilience4JPlugin中的执行方法中可以看到

    protected Mono<Void> doExecute(final ServerWebExchange exchange, final SoulPluginChain chain, final SelectorData selector, final RuleData rule) {
        final SoulContext soulContext = exchange.getAttribute(Constants.CONTEXT);
        assert soulContext != null;
        Resilience4JHandle resilience4JHandle = GsonUtils.getGson().fromJson(rule.getHandle(), Resilience4JHandle.class);
        if (resilience4JHandle.getCircuitEnable() == 1) {
            return combined(exchange, chain, rule);
        }
        return rateLimiter(exchange, chain, rule);
    }

根据CircuitEnable属性的值来决定只是做流控还是同时同时做流控和断流两个方向。但是这个规则的配置是基于数字配置的。是不是可以优化为boolean类型的,这可能是个可以优化的方向

file

• 最后通过代理工厂Resilience4JRegistryFactory来执行断流和流控的具体控制，相对来说比直接配置和代码来控制简单了很多

Soul中sentinel插件的使用和流程

• 在SentinelPlugin中并没有看到直接执行sentinel的内容，而是直接重载了PluginDataHandler的重载方法里
• 在重载方法中 FlowRuleManager.loadRules(flowRules)和DegradeRuleManager.loadRules(degradeRules)将sentinel都加载到了Sentinel中，由sentinel进行控制

三个断路器的控制基本就是这样， 后续对三个断路器有了使用经验再来具体进行对比。

欢迎关注和点赞，以及总结的分类面试题https://github.com/zhendiao/JavaInterview