面试题答案
一键面试传统单体架构与微服务架构会话管理差异
- 管理集中性
- 传统单体架构：会话数据通常存储在单体应用内部，管理相对集中。所有与会话相关的逻辑，如登录验证、会话创建与销毁等，都在同一个应用进程内完成。例如，使用基于内存的会话管理，将会话数据存储在应用服务器的内存中，所有请求处理线程都可以直接访问这些数据。
- 微服务架构：每个微服务都是独立的进程，会话管理无法像单体架构那样集中进行。不同微服务可能部署在不同的服务器上，甚至使用不同的技术栈，需要在多个微服务之间协调会话数据的存储、共享和管理。
- 扩展性
- 传统单体架构：随着业务增长，单体应用扩展通常通过增加服务器实例来实现。会话管理扩展相对简单，可采用粘性会话（Sticky Session），将用户请求始终路由到同一个服务器实例，以确保会话数据的一致性。但这种方式在大规模扩展时，可能会因单个实例故障导致用户会话丢失，且扩展性有限。
- 微服务架构：微服务架构天然具有良好的扩展性，每个微服务可以独立进行水平扩展。然而，这也给会话管理带来挑战，因为多个微服务实例处理用户请求时，需要保证会话数据在所有实例间的一致性和共享性，不能简单依赖粘性会话。
- 数据存储
- 传统单体架构：可选择多种会话数据存储方式，如内存、文件系统或关系型数据库。内存存储简单高效，但应用重启或服务器故障时会话数据会丢失；文件系统存储适合持久化需求不高的场景；关系型数据库存储能提供持久化和数据一致性，但读写性能相对较低。
- 微服务架构：需要一种能支持分布式环境的会话数据存储，如Redis。Redis具有高并发读写性能、支持分布式部署，能满足多个微服务实例对会话数据的快速读写和共享需求。但引入Redis也增加了系统复杂性，需要处理与Redis的连接管理、数据同步等问题。
Spring Cloud分布式会话管理面临的挑战及应对策略
- 会话数据一致性
- 挑战：多个微服务实例可能同时读写会话数据，容易出现数据不一致问题。例如，一个微服务更新了会话中的用户信息，而另一个微服务读取到的还是旧数据。
- 应对策略：使用分布式锁，如基于Redis的分布式锁。在对会话数据进行读写操作前，先获取锁，确保同一时间只有一个微服务实例能操作会话数据。另外，采用缓存更新策略，如读写时都更新缓存，保证缓存与会话数据源（如数据库）的数据一致性。
- 跨微服务会话传递
- 挑战：用户请求可能在多个微服务之间传递，需要确保会话信息在各个微服务间正确传递，否则会导致后续微服务无法识别用户会话状态。
- 应对策略：在请求头中传递会话标识，如JWT（JSON Web Token）。每个微服务在接收到请求时，从请求头中解析出会话标识，然后根据标识从共享的会话存储（如Redis）中获取完整的会话数据。Spring Cloud Gateway等网关组件可以在请求进入微服务架构时统一处理会话标识的添加和验证。
- 会话数据安全
- 挑战：分布式环境下，会话数据在多个微服务间传输和存储，面临更多安全风险，如数据泄露、篡改等。
- 应对策略：对会话数据进行加密处理，在存储和传输过程中使用SSL/TLS协议加密数据。同时，对微服务间的调用进行身份验证和授权，只有经过授权的微服务才能访问和修改会话数据。可以使用Spring Security等安全框架实现身份验证和授权功能。
- 性能与资源消耗
- 挑战：频繁读写共享的会话存储（如Redis）可能导致性能瓶颈，增加网络开销和资源消耗。
- 应对策略：合理设置会话数据的缓存策略，对不经常变化的会话数据设置较长的缓存时间，减少对后端存储的读写次数。同时，对微服务进行性能优化，如采用异步处理方式读写会话数据，避免阻塞业务逻辑。还可以根据业务需求对会话数据进行分片存储，减轻单个存储节点的压力。