Soul的SPI以及負載均衡策略研究

上一節留下的幾個問題在之後進行的研究

如何從abstractSoulPlugin執行完之後到WebClientPlugin的相同方法，是責任鏈模式還是其他的加載過程

各個插件執行的時候實際上是責任鏈模式。請求分發執行的這個方法主要是SoulWebHandler 繼承了Spring webflux的WebHandler的handle方法。handle方法中的參數正好就是請求的相關參數，然後我們就可以在插件的執行邏輯內轉發和做操作

abstractSoulPlugin是如何加載註冊或修改後的選擇器等數據

可以看到在數據同步的配置中,是由zkClient.subscribeDataChanges來訂閱數據的改變操作，從感覺上來說，可能沒有websocket那麼明顯

plugin 中的執行方法是如何獲取到ServerWebExchange的相關請求數據

SoulWebHandler 繼承了Spring webflux的WebHandler的handle方法,springwebflux內部獲取了請求的相關屬性放入了ServerWebExchange中

Soul的SPI以及引申出的負載均衡

針對負載均衡的研究，其實我在一開始的使用的文章中就已經提到過了。因此我今天繼續嘗試了負載均衡的相關代碼的查看，首先，在上一節的基礎上，我們可以知道，插件是通過責任鏈模式進行執行的。而我們負載均衡這一部分是使用的默認的divide插件來執行的。在divide插件的doExecute方法中，首先進行了SPI的類加載，然後根據類加載的情況獲取了具體的負載均衡的策略。用來執行了具體的負載均衡策略，通過如下在SPI代碼插入的日誌語句

可以看到。SPI不僅加載了負載均衡的具體方式。而且在此之前，還加載了多次匹配策略，全局搜索後發現不僅base插件和divide插件會加載SPI類，監控相關的MetricsTrackerFacade中也同樣使用了SPI類。同時，在SPI的第一次加載某個SPI實現時，SPI會將相關類實例在緩存中緩存起來。這樣不用在後續的代碼中繼續執行加載資源解析spi文件等具體的耗時操作，另外負載均衡中內置了hash，輪詢roundrobin,隨機random三種負載均衡方式，由於對算法還沒有進行深入研究，在此不做過多說明，後續進行了一些研究再在此基礎上進行說明

下面，想探討下，當選擇器負載均衡和選擇器規則負載均衡不相同且選擇器規則負載均衡爲random時爲什麼選擇的是選擇器的負載均衡