【系统架构设计百科】无状态设计：扩展的第一步也是最难的一步
💡
原文中文，约28000字，阅读约需67分钟。
📝
内容提要
在电商平台大促前，运维团队将应用服务器从8台扩展到32台，但由于负载均衡器开启会话保持，导致流量分布不均，影响性能。文章探讨了无状态服务的重要性，强调将状态外置到共享存储，以实现更好的扩展性和故障隔离。无状态服务允许任意请求由任意实例处理，简化了发布和测试过程。通过将会话、缓存和文件状态外置，系统能够提高性能和可靠性，避免Sticky Session带来的问题。
🎯
关键要点
- 在电商平台大促前，运维团队将应用服务器从8台扩展到32台，但由于负载均衡器开启会话保持，导致流量分布不均，影响性能。
- 无状态服务允许任意请求由任意实例处理，简化了发布和测试过程。
- 将状态外置到共享存储可以实现更好的扩展性和故障隔离，避免Sticky Session带来的问题。
- 无状态服务的架构收益包括自由伸缩、简化发布、故障隔离和测试简化。
- Sticky Session会导致负载不均衡、故障恢复困难、扩缩容失效和部署复杂化。
- 状态外置模式通过将状态从进程内存移到外部共享存储来实现无状态服务。
- 不同类型的状态适合不同的外部存储，如会话状态适合Redis，文件状态适合对象存储。
- 文件上传应采用直传对象存储的方式，避免应用服务器接触文件数据。
- WebSocket连接需要通过连接注册表和Redis Pub/Sub来管理跨实例的消息传递。
- 在改造过程中，需逐步迁移状态，确保每一步都有回退能力。
❓
延伸问答
无状态服务的定义是什么？
无状态服务是指任意请求可以由任意实例处理，且结果完全一致，不持有任何跨请求的上下文。
为什么无状态设计对系统扩展性至关重要？
无状态设计消除了串行化约束，使每个请求独立并可并行处理，从而提高系统的扩展性和吞吐量。
Sticky Session会带来哪些问题？
Sticky Session会导致负载不均衡、故障恢复困难、扩缩容失效和部署复杂化。
如何将会话状态外置到Redis？
将会话状态外置到Redis需要添加相关依赖并配置Redis连接，确保Session数据存储在Redis中而非应用实例内。
文件上传在无状态设计中应如何处理？
文件上传应采用直传对象存储的方式，避免应用服务器接触文件数据，确保文件直接从客户端上传到对象存储。
在改造过程中，如何确保每一步都有回退能力？
在改造过程中，应逐步迁移状态，并在每一步实施回退方案，以确保系统的稳定性和可恢复性。
➡️
