工作階段保持是一种負載平衡行为，用于在设定时间内将同一客户端或同一使用者会话的請求持续转发到同一台後端伺服器。它也常被称为黏性工作階段或工作階段親和性。实际使用中，負載平衡器不是每次都把新請求独立分配到任意可用伺服器，而是记住之前的路由结果，并在保持规则有效期间继续把该客户端送回同一个目标。

这种机制很重要，因为并不是所有應用都已经完全无狀態。部分 Web 應用、登入流程、购物车、聊天会话、多步骤表单和内存中的业务流程，仍然会把临时会话資料保存在某个應用实例上。如果同一使用者的后续請求被转到另一台没有本地狀態的後端，就可能出现会话中断、重新登入、临时資料丢失或业务行为不一致。

因此，工作階段保持可以理解为負載平衡器与應用会话模型之间的协调机制。它并非所有系统都必须使用，许多现代分布式應用会专门设计成不依赖它。但是当應用狀態仍然停留在某个後端实例上时，工作階段保持就是一种实用且有时必要的方案。

工作階段保持会在一段时间内把客户端绑定到同一个後端，使有狀態交互在多次請求之间保持一致。

工作階段保持的含义

为同一个客户端会话提供一致的後端路径

从本质上看，工作階段保持意味着同一客户端会被重复路由到同一台後端伺服器，而不是每个請求都被自由重新均衡。在普通負載平衡环境中，每个請求可能会按照轮询、最少连接、权重等算法分配到最合适的後端。启用工作階段保持后，負載平衡器会优先考虑该客户端的连续性，只要保持记录仍然有效，就把后续請求继续送往同一後端。

这也是工作階段保持经常与有狀態 Web 交互联系在一起的原因。它的目标不只是路由方便，而是在應用狀態尚未完全外置到共享会话存储或无狀態令牌模型之前，保持應用流程的连续稳定。

在实际架构讨论中，工作階段保持并不是使用者会主动感知的功能，而是让應用在一系列相关請求被持续處理时保持稳定的基础机制。

也称为黏性工作階段或工作階段親和性

Session persistence、sticky sessions 和 session affinity 在負載平衡場景中经常表达非常接近的含义。不同厂商可能使用不同术语，但核心思想相同：負載平衡器会在一段时间内有意保留客户端与後端之间的关系。

理解这一点有助于阅读不同平台的技术文档。无论在 Web 运维、云平台还是 Ingress 系统中，这些术语通常都指向同一类会话亲和机制。

工作階段保持本身不会让應用变成有狀態。它只是通过把使用者在部分会话生命周期内绑定到同一後端，帮助有狀態應用保持行为一致。

工作階段保持如何工作

負載平衡器先做初始路由决策

多数工作階段保持流程都从一次普通負載平衡選擇开始。第一次請求到来时，負載平衡器会根据組態算法選擇後端，例如轮询、最少连接、加权路由或其他方式。初始目标确定后，保持机制会记录足够的信息，以便之后识别同一个客户端。

这点很关键，因为工作階段保持通常不是完全替代負載平衡，而是改变第一次路由之后的處理方式。初始請求、故障后的重新分配以及保持记录过期后的選擇，仍然依赖負載平衡算法。

换句话说，第一次請求通常仍然被負載平衡，而后续請求可能按亲和关系转发。

系统保存亲和键

第一次請求被分配后，平台需要一种方法来识别同一客户端后续請求。不同的工作階段保持方法使用不同的键值：有些使用 Cookie，有些使用源 IP 地址或哈希逻辑，还有些会使用更贴近應用层的自定义資料。

只要这个键存在，后续請求就可以在保持记录有效且後端仍可用的情况下匹配到同一伺服器。因此，亲和键是否准确代表真实網路和應用环境中的一个使用者会话，会直接影响保持效果。

工作階段保持的质量很大程度取决于所选键在整个会话生命周期中是否稳定、唯一且适合该业务場景。

后续請求复用同一後端

当同一客户端再次访问时，負載平衡器会检查保持记录。如果找到有效匹配，就将請求转发到原来的後端，而不是重新做一次新的均衡决策。这个过程会持续到保持时间过期、後端不可用、保持資料变化，或平台策略要求重新计算亲和关系为止。

这种行为可以在應用期望单節點连续性的情况下，保持登入狀態、购物车或多步骤流程的稳定。没有工作階段保持，后续請求可能落到另一台不了解该会话狀態的後端。

因此，工作階段保持通常要和会话超时策略、故障處理、負載平衡健康检查一起设计，而不能只当作一个简单开关。

工作階段保持会在第一次請求后创建亲和记录，并在后续請求中复用该後端選擇。

常见的工作階段保持方法

基于 Cookie 的保持

基于 Cookie 的保持是 HTTP 和 Web 應用环境中最常见的方法之一。負載平衡器或應用会設定一个 Cookie，用于标识会话与後端之间的关系。后续請求携带该 Cookie 时，就会在組態时长内被路由回同一台後端伺服器。

这种方式非常适合浏览器型工作流，也常用于购物、认证和门户类應用，因为 Cookie 天然适合 HTTP/HTTPS 中反复发生的使用者交互。在公共互联网和共享網路环境中，它通常也比简单的網路层方法更精准。

当浏览器参与是业务流程核心时，Cookie 保持通常是传统 Web 應用会话连续性的强預設選擇。

基于源 IP 或哈希的保持

另一种常见方法是根据客户端源 IP 地址或某个請求属性的哈希值實現保持。这种方式部署简单，因为它不要求應用 Cookie，但也存在限制。位于共享 NAT 閘道后的使用者可能被错误地归为同一组，移动或漫游使用者在公网 IP 变化时也可能失去保持关系。

因此，源 IP 保持通常更适合受控环境，而不是不可预测的互联网大规模客户端群体。它仍然可以在企业内网、内部應用或某些基础设施場景中发挥作用。

这种方法的简单性很有吸引力，但真正价值取决于输入属性在会话生命周期中是否足够稳定和唯一。

應用感知或自定义保持

一些平台支持更高级的保持方式，可以使用應用資料、协议字段或自定义匹配逻辑，而不只是 Cookie 或 IP 地址。当應用具有更复杂的会话身份模型，或标准 Cookie 方法不够时，这类保持方式非常有价值。

它也说明工作階段保持可以根据應用层进行调优，而不是固定不变的单一功能。在大型或专业环境中，它可能比通用方法产生更可靠的亲和效果。

但高级保持通常比标准 Cookie 粘性需要更谨慎的设计、测试和运维理解。

最合适的保持方法取决于應用如何识别使用者会话，而不只是負載平衡器支持什么功能。

工作階段保持的优势

为有狀態應用提供会话连续性

工作階段保持最直接的优势是连续性。如果應用把临时会话資料本地保存在某个後端实例上，保持机制可以让使用者继续与同一实例交互，而不是在節點之间不可预测地跳转。

这可以减少会话中断、反复登入、表单部分丢失和應用行为不一致。对于较旧的應用或快速部署的 Web 工作负载，它可能是保持稳定使用者体验的最简单方法。

在某些环境中，工作階段保持不只是有帮助，而是让会话型應用在負載平衡下可用与不稳定之间的关键差异。

在某些情况下简化應用架构

当替代方案需要立即把所有会话狀態迁移到分布式共享存储时，工作階段保持也可以简化應用设计。团队可以在水平扩展的同时继续依赖本地会话狀態，至少在架构成熟度过渡阶段可以这样做。

这并不意味着工作階段保持总是理想的长期设计，但它确实很实用。它允许团队在不一次性重构所有依赖会话的功能时支持连续性。

这也是工程师最终更偏好无狀態模型的情况下，黏性工作階段仍经常出现在真实生产系统中的原因之一。

潜在的性能收益

工作階段保持也可能带来性能收益。如果同一後端本地保留了使用者临时狀態或热缓存，重复請求就可以避免反复重建狀態或跨節點同步。在短期重复交互较多的负载中，即使保持的主要目的不是速度，也会让應用感觉更灵敏。

当應用在本地内存中維護热会话資料，而原本需要每次查询共享存储或重建狀態时，这种收益会更加明显。

因此，在合适的工作负载中，工作階段保持可以同时改善使用者连续性和後端效率。

当重复使用者請求依赖仍绑定在特定後端实例上的临时狀態时，工作階段保持最有价值。

取舍与限制

负载分布可能不够均匀

工作階段保持的主要取舍是降低了纯負載平衡的灵活性。如果使用者必须回到同一後端，平台就不能根据当前负载自由重新分配每个請求。如果某些持久会话负载很重或持续时间很长，就可能造成流量分布不均。

实际上，管理员需要同时关注单个会话行为和整体節點利用率。黏性工作階段可以提升连续性，但如果会话群体本身没有均衡好，也会形成热点。

这也是工作階段保持应该有意识地启用，而不是預設启用的重要原因之一。

故障切换更复杂

工作階段保持还会让故障切换更复杂。如果後端伺服器不可用，保持记录可能不再指向有效目标。平台必须打破粘性、重新分配会话，或让使用者重新建立狀態。因此，最好让應用能容忍重新分配，或仍然具备某种外部会话恢复机制。

换句话说，工作階段保持有助于连续性，但不能替代弹性的應用狀態管理。如果绑定節點故障，而狀態又不存在于其他地方，使用者中断仍然很可能发生。

良好的会话架构需要在保持便利性和优雅故障處理之间取得平衡。

不适合完全无狀態架构

许多现代云原生架构会刻意避免依赖黏性工作階段。它们把会话狀態外置到共享資料存储、令牌、缓存或分布式身份层，使任意健康後端都可以處理任意請求。在这些架构中，工作階段保持可能不必要，甚至会因为限制負載平衡灵活性而不理想。

因此，工作階段保持应当被视为一种设计選擇，而不是自动預設项。它在應用模型需要时很有用，但并非每个應用都应该依赖它。

对现代平台设计而言，一个简单原则是：当保持机制能解决真实狀態问题时使用它；当无狀態模式已经更好地解决问题时避免使用它。

工作階段保持常常是实用方案，但不是通用最佳实践。它的价值取决于應用是否仍依赖後端本地会话狀態。

工作階段保持的應用場景

带登入狀態的 Web 應用

最常见的應用之一是登入型 Web 應用，其中认证狀態、使用者流程或临时上下文仍保存在某个後端实例上。工作階段保持可以确保后续已认证請求继续到达同一伺服器。

这对旧式 Web 平台、定制企业门户或混合现代化环境尤其相关，因为这些系统的会话狀態可能尚未完全外置。

对这类應用，工作階段保持经常是传统会话處理与现代負載平衡基础设施之间的运维桥梁。

购物车和电商流程

当购物车内容、临时定价逻辑或结账狀態本地保存在某个應用实例上时，电商系统经常使用工作階段保持。在这些流程中，保持机制可以避免结账体验中断和临时会话資料反复重建。

这是一个经典場景，因为客户通常会在短时间内完成一系列相关操作，而丢失会话连续性会立即产生业务影响。

当购物车和结账狀態仍然是節點本地狀態时，工作階段保持具有很高价值。

多步骤表单和交易流程

使用多步骤表单、引导式注册或分阶段交易流程的應用，如果每一步都依赖前一步产生的临时内存狀態，也可以从工作階段保持中受益。通过让使用者在流程期间停留在同一後端，負載平衡器降低了中途丢失连续性的风险。

这适用于注册系统、内部业务门户、理赔流程、支持门户和管理工作流等場景，其中会话不仅包含认证狀態，还包含流程狀態。

这些流程通常会非常明显地暴露会话不一致问题，因此往往最先采用工作階段保持。

聊天、实时 Web 会话和 API 閘道

在某些聊天應用、实时有狀態交互和 API 閘道場景中，工作階段保持也很有用，因为上游服务可能期望同一節點连续處理。在 API 环境中，当後端本地缓存或交易上下文让重复路由更有价值时，可以選擇性使用保持机制；但许多 API 平台仍优先采用无狀態设计。

对实时或会话型服务，将同一交互保持在一个節點上可以减少狀態重建并提升连续性，尤其适合过渡型架构。

与其他場景一样，决策取决于会话或对话狀態实际存放在哪里。

Kubernetes 和 Ingress 环境

云原生和 Kubernetes 部署也会在特定工作负载中使用工作階段保持。它特别适合迁移阶段、有狀態 Web 工作负载，或集群中仍有部分服务尚未完全改造为无狀態的情况。

在这些环境中，Ingress 或閘道级保持可以帮助将請求稳定路由到 Pod 或上游服务，同时平台仍然可以利用统一前端访问和可扩展部署模式。

在承载新旧應用混合设计的真实生产集群中，它是一种常见的实用折中方案。

部署最佳实践

只在解决真实问题时使用保持

第一条最佳实践是：只有当應用确实依赖单節點连续性时才启用工作階段保持。如果工作负载已经是无狀態的，添加粘性可能只会降低均衡灵活性而没有明显收益。保持机制应由應用行为驱动，而不是习惯性开启。

这也有助于长期保持架构清晰。团队可以在确实需要的地方使用保持，同时推动其他服务向更具弹性的共享狀態或无狀態模型迁移。

这种選擇性方法通常能带来更健康的长期平台设计。

有意识地選擇保持方法

基于 Cookie 的保持通常最适合浏览器和 Web 應用会话，源 IP 或哈希方法更适合受控环境。特殊場景可能需要更高级的應用感知方法。所选方法应匹配應用识别会话连续性的方式，也要符合客户端在網路中的真实行为。

选错方法可能导致亲和关系不稳定、错误分组或复杂度过高。最简单的方法并不总是最正确的方法。

因此，保持方法選擇既是基础设施决策，也是應用设计决策。

谨慎設定超时和故障切换行为

保持时长应该足以支持使用者工作流，但不应长到让过期亲和关系无意义地保留。管理员还应测试绑定後端不可用时会发生什么。良好部署需要承认：工作階段保持提升连续性，但不能替代故障规划。

在任何黏性工作階段架构中，连续性与弹性之间的平衡都是最重要的设计点之一。

組態得当时，工作階段保持可以支持稳定性，而不会把平台锁定到僵硬或脆弱的行为中。

FAQ

简单来说，什么是工作階段保持？

工作階段保持是一种負載平衡功能，用于让使用者請求在部分会话期间继续到达同一後端伺服器，而不是每次請求都独立重新分配。

工作階段保持和黏性工作階段一样吗？

是的。在負載平衡环境中，黏性工作階段和工作階段親和性通常都是工作階段保持的其他叫法。

为什么有些應用需要工作階段保持？

有些應用会把登入狀態、购物车、聊天上下文或多步骤流程資料等临时会话信息保存在某个後端实例上。保持机制可以让后续請求返回同一实例。

實現工作階段保持的主要方式有哪些？

常见方式包括負載平衡器 Cookie、應用 Cookie、源 IP 或哈希亲和，以及更高级的應用感知保持方法。

工作階段保持总是好選擇吗？

不是。它适合有狀態應用，但完全无狀態架构通常不需要它，并且更适合更灵活的负载分布。