在Spring Boot API Gateway中实现Sticky Session

小结 在Kubernetes微服务的云环境中,如何在Spring Boot API Gateway中实现Sticky Session,当服务请求被某一个服务器处理后,所有后续的请求都被转发到被第一次进行处理的同一个服务器再进行处理,这里进行了尝试,取得了想要的结果。 问题 Spring Boot API Gateway中实现Sticky Session在Spring Boot官方文档并没有特别详细的描述,看来看去语焉不详,如下: https://docs.spring.io/: 3.9. Request-based Sticky Session for LoadBalancer 解决这个问题不仅要自定义负载均衡策略和方法,并需要Spring Boot API Gateway能够用某种方法取得服务器实例的ID并将每一个收到的服务请求处理并转发到具有相应服务器实例ID的服务器。实际上在Github上已经有大神给出了解决方案,具体地址如下: Github: tengcomplex/spring-cloud-gateway-lb-sticky-session 在API Gateway中实现Sticky Session 实现的环境为Kubernetes微服务的云环境,这里需要使用cookie,并使用Eureka服务发现模块。具体思路如下: StickySessionLoadBalancer实现ReactorServiceInstanceLoadBalancer,相当于自定义了一个负载均衡策略 当Spring Boot API Gateway收到http服务请求,StickySessionLoadBalancer在cookie中找服务器实例ID: 自定义一个scg-instance-id为cookie的键值 如果scg-instance-id为cookie被找到,而且是一个有效的服务器实例ID,那么这个服务请求就会被路由到这个具有服务器实例ID的服务器实例进行处理 反之,如果没有找到scg-instance-id为cookie的键值,或者服务器实例ID无效(有可能服务器已经宕机),那么委托ReactorServiceInstanceLoadBalancer重新选择一个服务器,并将服务请求转发那个服务器 无论以上路由如何选择,Spring Boot API Gateway会将服务器实例ID更新到cookie中去,scg-instance-id为的键值 注:以上图片是Sticky Session的Spring Boot API Gateway路由示意图,来源于Github: Question: Sticky session in routes with load balancer […]

Tomcat启动的两个问题

小结 Tomcat服务碰到两个常见的问题,进行了解决。 问题及解决 Address already in use: JVM_Bind 端口被占用的问题经常会碰到,最常见的解决办法是把占用端口的进程进行关闭,或者是修改Tomcat使用的端口。如下: netstat -ano | find “80” taskkill /PID 73328 /F 实际上以下进程是不能杀掉的,这样就踢到铁板了。 C:\Users\Administrator>netstat -aon | find “80” … TCP 172.16.0.12:34905 172.16.22.40:8080 SYN_SENT 3712 找到3712的这样一个进程,发现是TmListen.exe,是Trend Micro的杀毒软件的。 C:\Users\Administrator>tasklist|findstr 3712 TmListen.exe 3712 Services 0 11,876 K 终极解决办法,重启计算机,问题解决。 No buffer space available ,tomcat启动报错 这个问题是个很诡异的错误,原因是部署的8080或8090 端口不在范围内。参考CSDN: No buffer space available ,tomcat启动报错,执行netsh int ipv4 […]