在构建基于Spring Cloud微服务框架时，使用了常用的框架NGINX+ZUUL+Eureka+业务服务，Session使用Spring boot的Redis集成，所有微服务间共享Session。    所有业务的微服务Rest接口前台调用接口通过ZUUL进行转发，而ZUUL通过创建ZUULFilter过滤器来对请求鉴权及一些Session操作，而且为了保证Session实时生效

    最近定位一个以前没有注意到的奇葩问题。在系统开发过程中，在测试环境有些人反馈偶尔会出现请求应用时会重定向到后端业务微服务地址，而且还不是必现问题，有点棘手。    当前系统请求流如下：    Request --> NGINX ---> ZUUL --> Business Micro Service    即页面请求先到达暴露出来的反向代理服务器N

    在微服务开发过程中，为了使用方便经常会将频繁访问的信息如用户、权限等放置到SESSION中，便于服务访问，而且，微服务间为了共享SESSION，通常会使用Redis共享存储。但是这样就会有一个问题，Spring boot在封装Request对象时会将当前SESSION中所有属性对象反序列化，反序列化都成功以后，将SESSION对象生成。如果有一个微服务将本地的自定义Bean对象放置到SES

    Spring cloud各个微服务使用过程中，通过Eureka进行服务的注册与发现。ZUUL网管及服务间请求调用，默认都是通过Eureka进行。    服务间请求处理过程，一般是通过服务名，到Eureka中获取实际的服务请求地址，然后根据实际地址进行HTTP请求。    默认情况下，通过服务名到Eureka获取服务所在地址一般是如下构成的：    http://${eureka...