接着上一篇文章，現在來看看如何使用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值，然後用某種算法，能夠得到唯一的值分給不同的特定的機器。
上面的就是我基於這個思路做的一個小小的測試，想分享給大家。