今天要說的是，對於spring cloud的負載均衡我不使用zuul，而是使用nginx+spring boot（多tomcat實現）。
爲什麼不使用zuul呢？使用zuul確實方便了我們的開發，他集成了spring session，使得多個微服務之間可以共享session。但是，恰恰是因爲這種機制，使得每個請求至少查詢兩次redis或多次redis，從而加重了redis的壓力和系統的N個通信環節。
spring cluod 的session共享機制是這樣的，zuul將sessionId的cookie傳遞到下一個微服務A，微服務A通過cookie值得出sessionId,然後根據sessionId查詢redis，讀取到所有的session值；當微服務A調用微服務B的時候，同樣是將cookie傳遞到微服務B，微服務B通過同樣的流程從redis得到所有的session值。也就是我們的微服務使用session前，我們的框架讀取了兩三次redis甚至更多。
這樣redis可能就會成爲了系統的瓶頸，因爲每個請求上來都必須讀寫幾次redis，無論從瓶頸或者延時來考慮，這種機制都有點不太好。在我的理解，微服務就應該只做微服務的工作，不應該有狀態。不應該去管理session，管理session的工作，還是交給web層來實現，即使spring cloud的微服務是通過web服務來實現的。
我下面要說的框架是，在微服務之前前置一個spring boot的web服務網關，通過web服務來調用微服務。所有的session讀寫工作，都通過前置web層來實現。微服務需要用到的session值，在前置web層裏讀出來（比如驗證碼或用戶ID），然後作爲參數傳遞給下一級的微服務，微服務不再需要自己去redis讀取session，而是從接口參數裏面獲取session。下面是我推薦的架構。
關於nginx的代碼和spring cloud的架構圖，請查閱下面的原文:
https://www.yunedit.com/xueyuan/jx/1007