https://ops.docs.72602.space/using/application/index.html 有状态or无状态应用 Hugo en Fri, 07 Mar 2025 15:00:59 +0800 https://ops.docs.72602.space/using/application/stateful_stateless/index.html Fri, 07 Mar 2025 15:00:59 +0800 https://ops.docs.72602.space/using/application/stateful_stateless/index.html 对应用“有状态”和“无状态”的清晰界定，直接决定了它在Kubernetes中的部署方式、资源类型和运维复杂度。 一、核心定义 1. 无状态应用 定义：应用实例不负责保存每次请求所需的上下文或数据状态。任何一个请求都可以被任何一个实例处理，且处理结果完全一致。 关键特征： 请求自包含：每个请求包含了处理它所需的所有信息（如认证Token、Session ID、操作数据等）。 实例可替代：任何一个实例都是完全相同、可以随时被创建或销毁的。销毁一个实例不会丢失任何数据。 无本地持久化：实例的本地磁盘不被用于保存需要持久化的数据。即使有临时数据，实例销毁后也无需关心。 水平扩展容易：因为实例完全相同，所以直接增加实例数量就能实现扩展，非常简单。 典型例子： Web前端服务器：如Nginx, Apache。 API网关：如Kong, Tyk。 JWT令牌验证服务。 无状态计算服务：如图片转换、数据格式转换等。输入和输出都在请求中完成。 一个生动的比喻：快餐店的收银员。 任何一个收银员都可以为你服务，你点餐（请求），他处理，完成后交易结束。他不需要记住你上次点了什么（状态），你下次来可以去任何一个窗口。 2. 有状态应用 定义：应用实例需要保存和维护特定的状态数据。后续请求的处理依赖于之前请求保存的状态，或者会改变这个状态。 关键特征： 状态依赖性：请求的处理结果依赖于该实例上保存的特定状态（如用户会话、数据库中的记录、缓存数据等）。 实例唯一性：每个实例都是独特的，有唯一的身份标识（如ID、主机名）。不能随意替换。 需要持久化存储：实例的状态必须被保存在持久化存储中，并且即使实例重启、迁移或重建，这个存储也必须能被重新挂载和访问。 水平扩展复杂：扩展时需要谨慎处理数据分片、副本同步、身份识别等问题。 典型例子： 数据库：MySQL, PostgreSQL, MongoDB, Redis。 消息队列：Kafka, RabbitMQ。 有状态中间件：如Etcd, Zookeeper。 用户会话服务器：将用户Session保存在本地内存或磁盘的应用。 一个生动的比喻：银行的客户经理。 你有一个指定的客户经理（特定实例），他了解你的所有财务历史和需求（状态）。如果你换了一个新经理，他需要花时间从头了解你的情况，而且可能无法立即获得你所有的历史文件（数据）。 二、在Kubernetes中的关键差异 这个界定在K8s中至关重要，因为它决定了你使用哪种工作负载资源。 特性 无状态应用 有状态应用 核心K8s资源 Deployment StatefulSet Pod身份 完全可互换，无唯一标识。名字是随机的（如 app-7c8b5f6d9-abcde）。 有稳定、唯一的标识符，按顺序生成（如 mysql-0, mysql-1, mysql-2）。 启动/终止顺序 并行，无顺序。 有序部署（从0到N-1），有序扩缩容（从N-1到0），有序滚动更新。 网络标识 不稳定的Pod IP。通过Service负载均衡访问。 稳定的网络标识。每个Pod会有一个稳定的DNS记录：<pod-name>.<svc-name>.<namespace>.svc.cluster.local。 存储 使用PersistentVolumeClaim模板，所有Pod共享同一个PVC或各自使用独立的、无关联的PVC。 使用稳定的、专用的存储。每个Pod根据它的身份标识，挂载一个独立的PVC（如 mysql-0 -> pvc-mysql-0）。 数据持久性 Pod被删除，其关联的PVC通常也会被删除（取决于回收策略）。 Pod即使被调度到其他节点，也能通过稳定标识重新挂载到属于它的那块持久化数据。 典型场景 Web服务器、微服务、API 数据库、消息队列、集群化应用（如Zookeeper） 三、一个常见的误区：“看似无状态，实则有状态” 有些应用初看像无状态，但深究起来其实是有状态的。