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

由於之前並沒有使用過Hystrix，Resilience4j和sentinel中的任何一種，此處僅對三種流控和斷路器插件做一個流程分析

Soul中Hystrix的使用和操作流程

• 關於soul中插件的流程前文已經說過多次了,在此不在贅述。
• 根據規則的具體選擇方式。Soul構建了兩個不同的操作類HystrixCommandOnThread和HystrixCommand。兩個類的不同是HystrixCommandOnThread為攔截的接口建立了自己的線程池，實現了線程池的隔離。而HystrixCommand只是實現了短路器的基本功能。使用了線程池隔離之后。可以針對不同的線程使用不同的線程池配置。既區分了不同的接口和自定義配置解決不同並發程度所造成的壓力。也解決了不同接口之間造成影響的問題。這兩個類基本就是@HystrixCommand的各大屬性的集合，Soul通過界面配置的方式實現了斷路器的零侵入性。這樣來說，比Hystrix直接嵌入客戶端更加方便

• 另外在具體的斷路執行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類型的,這可能是個可以優化的方向

• 最后通過代理工廠Resilience4JRegistryFactory來執行斷流和流控的具體控制，相對來說比直接配置和代碼來控制簡單了很多

Soul中sentinel插件的使用和流程

• 在SentinelPlugin中並沒有看到直接執行sentinel的內容，而是直接重載了PluginDataHandler的重載方法里
• 在重載方法中 FlowRuleManager.loadRules(flowRules)和DegradeRuleManager.loadRules(degradeRules)將sentinel都加載到了Sentinel中，由sentinel進行控制

三個斷路器的控制基本就是這樣， 后續對三個斷路器有了使用經驗再來具體進行對比。

歡迎搜索關注本人與朋友共同開發的微信面經小程序【大廠面試助手】和公眾號【微瞰技術】，以及總結的分類面試題https://github.com/zhendiao/JavaInterview