今天要说的是，对于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