理解 Spring Cloud 负载均衡的默认行为
在 Spring Cloud 生态系统中，服务发现通常由 Eureka 等组件负责，而负载均衡则由 Spring Cloud Loadbalancer 处理。默认情况下，Spring Cloud Loadbalancer 采用轮询（Round-Robin）策略进行负载均衡。这意味着，客户端的连续请求可能会被分发到不同的服务实例上，这对于大多数无状态的微服务应用是理想的。
然而，在某些特定场景下，可能需要将来自同一客户端的请求“粘”在同一个服务实例上，即实现粘性会话。例如，当服务实例内部维护了客户端特有的状态信息，且这些状态信息未被外部化存储时，粘性会话就显得尤为重要。
配置粘性会话负载均衡
Spring Cloud Loadbalancer 提供了 RequestBasedStickySessionServiceInstanceListSupplier 来支持基于请求的粘性会话。这可以通过两种主要方式进行配置：
1. 通过配置文件进行配置
在 Spring Cloud Gateway 或其他需要粘性会话的微服务应用的 bootstrap.yml 或 application.yml 文件中，可以添加如下配置：
spring:
cloud:
loadbalancer:
configurations: request-based-sticky-session通过此配置，Spring Cloud Loadbalancer 将自动启用基于请求的粘性会话策略。需要注意的是，这种策略通常依赖于 HTTP Cookie 来识别客户端并将请求路由到正确的实例。因此，确保您的应用和网关正确处理 Cookie 是关键。
2. 通过编程方式创建 Bean
对于更精细的控制或在特定上下文中应用粘性会话，可以通过创建一个 ServiceInstanceListSupplier 的 Bean 来实现。以下是一个示例：
import org.springframework.cloud.client.loadbalancer.reactive.LoadBalancerServiceInstanceListSupplier;
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);
}
}
在这个配置类中：
- @Configuration 标记该类为配置类。
- @Bean 注解的方法 discoveryClientServiceInstanceListSupplier 返回一个 ServiceInstanceListSupplier 实例。
- ServiceInstanceListSupplier.builder() 用于构建实例列表供应商。
- .withDiscoveryClient() 确保负载均衡器能够从服务发现客户端（如 Eureka）获取服务实例列表。
- .withRequestBasedStickySession() 是启用粘性会话的关键方法。它会根据请求中的特定标识（通常是 Cookie）来尝试将请求路由到之前访问过的服务实例。
- .build(context) 完成构建过程。
注意事项与最佳实践
尽管粘性会话在某些场景下提供了便利，但它通常被认为是微服务架构中的“反模式”，因为它引入了服务实例的状态依赖性，与微服务的无状态、可伸缩性原则相悖。
潜在问题：
- 降低可伸缩性： 当某个服务实例出现故障或需要扩容时，粘性会话会导致请求无法平滑地迁移到其他健康实例，从而影响系统的弹性和可用性。
- 负载不均衡： 某些客户端可能会产生大量请求，如果这些请求都粘在同一个实例上，可能导致该实例过载，而其他实例却处于空闲状态，从而影响整体的资源利用率。
- 部署复杂性： 在滚动更新或蓝绿部署等场景下，维护粘性会话会增加部署的复杂性，可能导致服务中断或用户会话丢失。
- 架构耦合： 强制使用粘性会话往往暗示着服务内部维护了会话状态，这增加了服务之间的耦合度，使得服务难以独立部署和扩展。
建议：
强烈建议在设计微服务时，优先考虑构建无状态服务。这意味着所有的会话状态、用户数据等都应该外部化存储，例如：
- 使用 Redis、Memcached 等分布式缓存存储会话信息。
- 使用 JWT (JSON Web Tokens) 进行无状态认证。
- 将用户数据存储在 数据库 中，并确保所有服务实例都能访问。
只有在仔细评估了所有替代方案后，且确实存在无法规避的强依赖场景时，才考虑使用粘性会话。即使如此，也应尽量限制其使用范围，并确保对 Cookie 处理有清晰的理解和管理。
总结
Spring Cloud 提供了灵活的机制来配置负载均衡策略，包括实现粘性会话。通过在配置文件中设置 spring.cloud.loadbalancer.configurations: request-based-sticky-session 或创建自定义的 ServiceInstanceListSupplier Bean，可以轻松启用基于请求的粘性会话。然而，在采用此策略之前，务必深入理解其对系统可伸缩性、可用性和架构健壮性的潜在影响。在大多数微服务场景中，推荐采用无状态设计，以充分发挥微服务架构的优势。
