Divide外掛的使用

上一篇已經說到，Soul閘道器代理了我們自定義的一個SpringBoot服務。這一篇。我們就來嘗試下如何實現閘道器的預設的Divide外掛提供的負載均衡功能（好像也只能根據匹配的規則提供負載均衡的功能）此選擇器為我SpringBoot服務啟動並連線到soul-admin之後預設生成的，但是由此產生了一個問題，當我的應用下線之後，這個選擇器和選擇器規則並沒有下線？有待後續的研究。同時觀察表單元素。參閱Soul文件，發現有如下選擇器規則

型別：custom flow 是自定義流量。full flow 是全流量。自定義流量就是請求會走你下面的匹配方式與條件。全流量則不走。匹配方式：and 或者or 是指下面多個條件是按照and 還是or的方式來組合。條件：uri:是指你根據uri的方式來篩選流量，match的方式支援模糊匹配（/**）header:是指根據請求頭裡面的欄位來篩選流量。query: 是指根據uri的查詢條件來進行篩選流量。ip:是指根據你請求的真實ip，來篩選流量。host:是指根據你請求的真實host，來篩選流量。post:建議不要使用。條件匹配: match : 模糊匹配，建議和uri條件搭配，支援 restful風格的匹配。（/test/**） = : 前後值相等，才能匹配。 regEx : 正則匹配，表示前面一個值去匹配後面的正則表示式。 like ：字串模糊匹配。

> 但是官方文件中，並未給出創造了Post這種篩選方式，但是仍然不建議使用的原因，期待後續的原始碼的閱讀能找到答案

另外在divide外掛首頁我們可以看到，我們可以新增除了預設生成的規則之外的規則

最後實踐一下根據uri匹配的負載均衡，啟動多個客戶端程式，看看請求被轉發到那個服務上,可以看到不同負載策略的不同表現同時我們在選擇器表單框內，可以看到隨著多個客戶端程式的使用，增加了配置的情況另外，此處的weight權重策略和選擇器規則策略誰起作用？可以試下。將選擇器配置策略調整為50，50 。選擇器均衡規則調整為random。如果選擇器規則優先，那麼應該兩個客戶端每個客戶端接收一個請求，如果均衡規則優先。那麼可以得到隨機的請求，接下來我們試下可以看到當一個選擇器和選擇器規則同時滿足條件時，以粒度更小的選擇器規則均衡策略為準。關於這個是如何實現的，期待後續透過原始碼進行了解