接著上一篇文章，現在來看看如何使用ribbon切換負載均衡規則和使用自定義的負載均衡。

對於zuul過濾器，有四個過濾器，pro(前置)、route、post(後置),error(異常)。如果不清楚的可以去了解下zuul的機制。

對於一個請求正確的經過zuul是 pro --->route --->post。那麼我們就利用這個機制，來做一些改造。

一、改造pre 

這個我會在request請求頭中去新增一個zuulRequestheader，scope為 sup-end。

二、自定義規則

我建立了一個類使用MyselfRule繼承了abstractLoadBalanceRule,重寫了choose()和initWithNiwsConfig()方法。我定義的choose(),就是去拿到當前的請求頭，拿到剛才的資料，並取出scope(),如果是我要的值，那麼我就讓他進入服務列表的第一個，如果不是那麼就進入第二個。

然後定義了一個類為ribbon的配置類，

最後在請求入口添加了一個註解@RibbonClients,我主要用這個註解是為了如果有多個不同的服務，使用不同的策略。如果僅僅使用value裡面的註解，只能宣告一個，而且還會導致一些問題，這個問題我還沒去測試研究，只是，在查閱資料的時候，看到其他大神說的，沒有具體去測試。

最後啟動專案，測試結果為:

我訪問三次，都會轉發到8010.(我在上一篇配置的服務列表)，成功使用了定製的策略進行負載均衡。

三、如何使用ribbon內建的策略

只需要修改new 一個ribbon中內建的七種策略機制。

其實我上面是想解決一下 同一個token的訪問同一個服務。這邊我的思路是，重寫zuul 的pre這個過濾器，在請求頭設定一個標識，表明這個token上次訪問的是那個host的哪個port。然後重寫post過濾器，在post過濾器中將這些設值。在自定義策略機中拿到請求頭判斷，給這個token分配service。同時還有一個思路就是在自定義的邏輯裡面，拿到每次訪問的token值，然後用某種演算法，能夠得到唯一的值分給不同的特定的機器。

上面的就是我基於這個思路做的一個小小的測試，想分享給大家。