在云原生架构里，无状态服务指的是运行实例自身不持久化任何与具体请求或用户相关的上下文数据，每一个请求都携带完成处理所需的全部信息。这样的服务实例可以被随意创建、销毁或替换，而不会影响到整体业务的连续性与正确性。与之相对的有状态服务，则依赖本地磁盘、内存或进程内缓存来维持会话，一旦实例重启或迁移，数据就面临丢失风险。
什么是无状态服务
无状态并不是说系统完全没有状态，而是把状态从计算节点中剥离出去，集中存放在外部的共享存储或专门的状态服务中。例如用户的登录信息、购物车内容、业务流水号等，都不应该写在容器本地的变量或文件里。服务本身只负责纯逻辑运算，输入即输出，不留下“记忆”。
从资源视角看，无状态服务的CPU和内存消耗通常是可预测的，因为每次请求的开销相近，不会随着运行时间推移而累积私有数据。这让调度系统更容易做装箱计算和过载保护。在Kubernetes中，无状态服务一般用Deployment来描述，副本之间完全对等，扩容就是增加Pod数量，缩容就是直接删除Pod。
核心设计原则
会话与状态外部化
最常见的错误是把HttpSession放在应用服务器内存中。在云原生环境，请求可能被负载均衡分发到任意Pod，如果A节点登录、B节点校验，就会报未登录。正确做法是引入分布式缓存，比如Redis，将session_id作为密钥，用户数据作为值存入其中，请求头携带session_id即可在任何实例恢复上下文。
下面是一段将会话存入Redis的伪代码示例，展示了状态外部化的基本思路：
// 用户登录成功后，将用户信息写入Redis，并设置过期时间
String sessionId = UUID.randomUUID().toString();
UserVO user = authService.login(name, pwd);
redisTemplate.opsForValue().set("session:" + sessionId, user, 30, TimeUnit.MINUTES);
// 响应中将sessionId返回给客户端，后续请求通过Header传递
response.setHeader("X-Session-Id", sessionId);
实例对等可替换
所有Pod必须使用相同的不可变镜像，且启动后不修改本地文件。这样任意实例挂掉，控制器重新拉起一个就能立刻承接流量。如果实例内部悄悄写了日志以外的本地配置或队列，就会导致“雪花服务器”，破坏对等性。
在Kubernetes里可以通过只读根文件系统增强这一约束，配合探针保证只有健康的实例才接入Service。示例配置片段如下：
spec:
containers:
- name: app
image: ipipp.com/registry/app:v1.2.0
securityContext:
readOnlyRootFilesystem: true
readinessProbe:
httpGet:
path: /health
port: 8080
请求自包含与幂等
无状态服务应尽量让请求自包含，比如把用户身份令牌、租户标识放在Authorization头，而不是依赖服务端记忆。同时接口要设计成幂等，因为云环境网络重试频繁，同一个订单创建请求可能到达两次，后端不能重复扣款。
实现幂等的一个简单方式是要求客户端传唯一业务号，服务端用数据库唯一索引或Redis原子锁去重。代码示意：
def create_order(req):
key = "order:" + req.biz_id
if redis.set(key, "1", nx=True, ex=300):
# 真正落库
db.insert_order(req)
return success()
else:
return existed()
与有状态服务的边界
并非所有组件都要无状态。数据库、消息队列、缓存本身是有状态的，它们通常以StatefulSet或专用中间件集群形式存在。无状态设计原则主要约束业务计算层，把复杂性下沉到基础设施。明确分层后，业务团队只需关心逻辑，运维团队专注保障状态存储高可用。
实践中可以用一张简表区分二者在云原生中的处理方式：
| 维度 | 无状态服务 | 有状态服务 |
|---|---|---|
| 扩容方式 | 直接加副本 | 需考虑数据分片与同步 |
| 存储 | 外部化 | 本地加副本 |
| K8s对象 | Deployment | StatefulSet |
落地建议
团队在迁移传统应用时应先梳理哪些数据属于会话态，哪些属于持久态。把会话态强制外移，持久态交给数据库。然后打磨镜像，做到一次构建处处运行。最后在网关层统一做认证透传，让后端服务彻底变成无状态函数。
当无状态原则落实到位，系统的弹性伸缩将从“手工预案”变为“自动响应”，大促时只需改Deployment的replicas，或者交给HPA根据CPU自动扩缩，真正释放云原生的生产力。
stateless_servicecloud_nativekubernetes修改时间：2026-08-09 00:48:26