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時為什麼選擇的是選擇器的負載均衡

透過在外掛執行的斷點中執行可以看出。外掛同時獲取了規則和選擇器的負載均衡策略。而執行那個負載均衡策略在具體的執行器中進行選擇

可以看到在random的負載均衡策略中仍然進行了選擇器權重的區分。透過類的繼承關係可以看到getWeight方法被定義在模板抽象類中，同時被roundrobin和random使用，從而實現了上述的所說的在選擇器規則存在的情況下依然選擇了roundrobin負載均衡