Spring Cloud 负载均衡概述
在基于 spring cloud 的微服务架构中，服务发现（如 eureka）与负载均衡（如 spring cloud loadbalancer）是核心组件。默认情况下，spring cloud loadbalancer 采用轮询（round robin）策略进行服务实例间的请求分发，确保请求均匀地分配到各个服务实例。然而，在某些特定场景下，开发者可能需要实现粘性会话（sticky session），即确保来自同一客户端的后续请求总是被路由到处理其初始请求的同一服务实例。
粘性会话负载均衡的配置方法
Spring Cloud Loadbalancer 提供了 RequestBasedStickySessionServiceInstanceListSupplier 来支持基于请求的粘性会话。以下是两种主要的配置方式。
1. 通过配置文件进行配置
这是最直接的配置方式，通过在应用的 application.yml 或 bootstrap.yml 中设置相应的属性即可启用粘性会话。
spring:
cloud:
loadbalancer:
configurations: request-based-sticky-session将 spring.cloud.loadbalancer.configurations 设置为 request-based-sticky-session 后，Spring Cloud Gateway 或其他使用 Spring Cloud Loadbalancer 的组件将开始使用粘性会话策略。
2. 通过 Java Bean 进行编程配置
对于需要更精细控制或自定义逻辑的场景，可以通过创建 Java Bean 的方式来配置粘性会话。这种方式允许开发者将 ServiceInstanceListSupplier 注册为 Spring Bean。
import org.springframework.cloud.client.loadbalancer.reactive.RequestBasedStickySessionServiceInstanceListSupplier;
import org.springframework.cloud.loadbalancer.core.ServiceInstanceListSupplier;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class CustomLoadBalancerConfiguration {
@Bean
public ServiceInstanceListSupplier discoveryClientServiceInstanceListSupplier(
ConfigurableApplicationContext context) {
return ServiceInstanceListSupplier.builder()
.withDiscoveryClient() // 结合服务发现
.withRequestBasedStickySession() // 启用粘性会话
.build(context);
}
}在这个示例中，我们创建了一个 CustomLoadBalancerConfiguration 类，并定义了一个 ServiceInstanceListSupplier 类型的 Bean。通过 ServiceInstanceListSupplier.builder().withDiscoveryClient().withRequestBasedStickySession().build(context)，我们构建了一个结合了服务发现和请求粘性会话功能的实例列表供应商。
注意事项
无论采用哪种配置方式，在使用粘性会话时，都需要特别注意 Cookie 的处理。粘性会话通常依赖于客户端发送的特定 Cookie 来识别会话并将其路由到正确的服务实例。确保您的应用和网关正确地生成、发送和解析这些 Cookie。
粘性会话的架构考量与最佳实践
尽管粘性会话可以解决某些特定问题，但在现代微服务架构中，强烈建议避免使用粘性会话。粘性会话通常被认为是次优架构的标志，因为它引入了以下问题：
- 降低可伸缩性： 粘性会话将客户端请求绑定到特定的服务实例，这限制了负载均衡器在增加或减少服务实例时进行自由调度的能力。当某个实例过载时，即使有其他空闲实例，粘性会话也可能阻止请求被重新路由，从而导致性能瓶颈。
- 影响弹性与可用性： 如果一个绑定了会话的服务实例发生故障，那么所有依赖于该实例的客户端会话都将中断，用户体验受到影响。这与微服务架构追求的无状态、高可用和弹性设计原则相悖。
- 增加复杂性： 粘性会话的实现和维护通常涉及额外的复杂性，例如会话管理、Cookie 处理以及在多数据中心或云环境中的挑战。
- 阻碍服务升级与滚动部署： 在进行服务升级或滚动部署时，如果旧实例仍然持有活跃的粘性会话，那么在这些会话结束之前，旧实例可能无法被安全地移除，从而延长了部署周期或增加了中断风险。
最佳实践是设计无状态的微服务。 确保每个服务实例都可以独立处理任何请求，不依赖于先前的请求状态。如果确实需要维护会话状态，应将其外部化存储在共享的、高可用的存储中，例如：
- 分布式缓存： 如 Redis、Memcached，用于存储用户会话、认证令牌等。
- 数据库： 用于持久化更复杂的业务状态。
通过这种方式，任何服务实例都可以从共享存储中检索会话信息，从而实现真正的无状态服务，极大地提升了系统的可伸缩性、弹性和容错能力。
总结
Spring Cloud 提供了简单的方法来实现粘性会话负载均衡，无论是通过配置文件还是 Java Bean，都可以方便地启用此功能。然而，在采用粘性会话之前，开发者应深入理解其对微服务架构可能带来的负面影响。在绝大多数情况下，设计无状态服务并将会话状态外部化是更优的选择，它能更好地适应微服务架构的动态性和高可用性需求。只有在极少数无法避免粘性会话的场景下，才应谨慎使用，并确保充分考虑其潜在的限制和风险。
