什么是无状态服务
想象一下你去咖啡店买咖啡，每次换一个店员，他都能准确知道你之前点过什么——这叫有状态。但在很多网络服务里，我们不希望服务器“记住”用户。这种不依赖本地存储会话信息的服务，就是无状态服务。
为什么选择无状态架构
在高并发场景下，比如电商大促或直播抢购，流量可能瞬间翻十倍。如果每个请求都绑定到特定服务器，一旦那台机器出问题，用户就掉线了。而无状态服务把所有数据存在外部（比如 Redis 或数据库），任何一台机器都能处理任意请求，故障转移自然平滑。
典型应用场景
常见的登录系统现在大多用 Token 机制。用户登录后拿到 JWT，之后每次请求自带凭证。服务器不需要查本地 session 表，只验证 Token 签名即可放行。这样的接口天然适合做成无状态服务。
集群部署的关键步骤
部署无状态服务集群，核心是解耦 + 标准化。下面是一个基于 Nginx + Docker 的简单示例：
version: '3'
services:
app:
image: my-web-app:latest
ports:
- "8080"
environment:
- NODE_ENV=production
- REDIS_HOST=redis-service
restart: unless-stopped
redis-service:
image: redis:alpine
nginx:
image: nginx:alpine
ports:
- "80:80"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf
depends_on:
- app
Nginx 作为反向代理，把请求均匀分发给多个 app 实例。只要每个实例启动时配置一致、共享同一份外部数据源，就能实现无缝扩容。
健康检查不能少
集群中某台实例挂了怎么办？得靠健康检查自动剔除异常节点。Kubernetes 中可以通过 liveness 和 readiness 探针实现：
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
这些探针让系统能实时感知服务状态，避免把请求打到正在启动或已崩溃的容器上。
静态资源与配置管理
无状态还意味着所有配置从外部注入。环境变量、ConfigMap、远程配置中心都是常见方式。比如数据库地址绝不写死在代码里，而是通过 DATABASE_URL 动态传入。
前端资源建议托管到 CDN，后端 API 专注逻辑处理。这样哪怕整个集群重启，页面依然能快速加载。
实际运维中的小技巧
上线新版本时，用滚动更新逐步替换旧实例，用户几乎无感。如果发现新版本有问题，回滚也是一条命令的事。这种灵活性，正是无状态集群的优势所在。
日志别往本地文件写，统一输出到 stdout，由日志收集器（如 Fluentd）集中处理。排查问题时，直接查 Elasticsearch 就行，不用一台台登录机器翻日志。