无状态应用层是高可用与水平扩展的基石，需彻底剥离本地状态、外置所有会话与中间数据、统一使用共享存储与配置中心、构建跨az集群并配合服务发现与智能负载均衡，再通过演练和监控验证其真实性。
无状态应用层是实现高可用与无限水平扩展的基石。关键不在于堆机器，而在于让每个服务实例都可随时被替换、重启或下线，不影响任何请求处理——这需要从设计源头切断服务对本地状态的依赖。
彻底剥离会话与上下文状态
服务本身不保存登录态、用户偏好、临时计算结果等任何与请求生命周期绑定的数据。所有这类信息必须外置到共享存储中：
- 用户会话（Session）统一存入 Redis，设置合理过期时间，并启用主从+哨兵或集群模式保障 Redis 自身高可用
- 临时中间状态（如下单流程中的草稿、多步表单数据）也走 Redis 或轻量级数据库，避免写入本地内存或文件
- 若需会话粘性（如 WebSocket 长连接），应通过负载均衡器的 IP Hash 或 Cookie 持久化实现，而非依赖服务端本地存储
所有状态外置，服务只做纯计算
一个请求进来，服务要能完全靠“请求参数 + 外部存储读取”完成全部逻辑。这意味着：
- 禁用本地缓存（如 Guava Cache、Caffeine 单机缓存），改用分布式缓存（Redis/Memcached）并统一管理失效策略
- 配置信息不硬编码、不放本地 properties 文件，而是接入配置中心（如 Nacos、Apollo），支持运行时热更新
- 日志、指标、链路追踪 ID 等上下文信息，通过 ThreadLocal + 请求头透传 + MDC 统一注入，不依赖实例内存保留
集群部署与智能流量调度
无状态只是前提，真正支撑无限扩展的是可弹性伸缩的集群机制：
- 至少部署 3 个以上应用节点，跨可用区（AZ）分布，避免机房级故障导致全量不可用
- 使用服务发现（如 Nacos、Consul）替代静态 IP 列表，节点上线自动注册、异常心跳超时自动剔除
- 入口层用 Nginx 或云厂商 SLB，按最少连接数或加权轮询分发请求；内部服务调用走客户端负载均衡（如 Spring Cloud LoadBalancer）
- 配合 Kubernetes 的 HPA（基于 CPU/请求延迟/QPS 自动扩缩容），实现流量涨跌时秒级响应
验证与兜底：让“无状态”真实可信
光写代码不等于真正做到无状态，必须通过机制验证：
- 定期执行“随机杀进程”演练：在测试环境模拟节点宕机，确认请求无丢失、会话不中断、业务逻辑不报错
- 监控维度要覆盖“单实例状态残留”风险点：比如本地缓存命中率突增、ThreadLocal 对象未清理告警、文件句柄异常增长
- 发布时强制滚动更新（rolling update），每次只停一个实例，确保集群始终有足够健康节点承接流量
做到这四点，服务就不再是瓶颈，而是一个可无限复制的计算单元。流量来了加机器，故障了自动切流，扩容不再需要改架构、调参数、等排期——这才是无状态设计带来的真实弹性。
