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

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使用，從而實現了上述的所說的在選擇器規則存在的狀況下依然選擇了roundrobin負載均衡

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