在十年前的传统软件开发中，如果一个系统扛不住了，老板的第一个反应往往是：“赶紧去机房，给服务器加两条极其昂贵的内存！”这种靠堆叠单机硬件（垂直扩容，Scale Up）的方式，很快就会触及物理的极限。
现代 SaaS 平台的极客玩法是“水平扩容（Scale Out）”。一台服务器扛不住？那就用 Nginx 挡在前面，后面挂 10 台、甚至 100 台廉价的云服务器。只要流量一来，就在云端疯狂拉起新的容器实例。
但这套极其华丽的扩容魔法，有一个极其变态的先决条件：后端的应用代码必须是绝对“无状态（Stateless）”的。
在心理测评系统中，如果你使用了传统的 Session 机制来维持学生的登录和做题状态，那么你的服务器就带上了致命的“状态”，无限扩容的美梦将当场破灭。
致命陷阱：被 Session 锁死的传统架构
假设系统采用传统的 Session/Cookie 认证。
学生登录后，Tomcat 服务器 A 在自己的内存里极其小心地开辟了一块 Session 空间，存下了这个学生的 userId = 1024。
十分钟后，该学生开始做量表的第 5 题，并发出了一个提交答案的请求。
在这个极其庞大的水平扩容集群中，Nginx 负载均衡器一看服务器 A 的 CPU 满了，极其尽职地将这个请求转发给了旁边空闲的服务器 B。
灾难发生了：
服务器 B 翻遍了自己的内存，根本找不到这个学生的 Session。它极其冷酷地返回一个 401 Unauthorized（未登录），直接把正在做题的学生踢回了登录页。学生极其愤怒地摔了鼠标。
为了解决这个问题，很多人试图配置复杂的“Session 复制”或“Session 黏滞（Sticky Session）”。但这极其消耗内网带宽，且在服务器动态伸缩时极其容易导致状态丢失，简直是一场灾难。
破局降维：拥抱 JWT（JSON Web Token）
正如橙星云架构团队在完成微服务云原生改造时所做的那样：彻底抛弃服务端的 Session，全面拥抱无状态的 JWT。
JWT 的核心极客哲学是：服务器不再记忆任何人的状态，把状态全部压缩进加密令牌，让客户端自己带过来！
当学生登录成功时，认证中心不再往内存里塞任何东西。它将该学生的 userId = 1024、过期时间以及角色等极度精简的信息，转换成一个 JSON。然后，利用极其强悍的 HMAC 或者 RSA 算法，用服务器独有的私钥对这个 JSON 进行签名，生成一长串字符（Token）扔给前端。
之后，学生每次提交答卷，前端都会在 HTTP Header 中极其自觉地带上这串 Token（Authorization: Bearer xxxxx...）。
无限扩容的艺术
在这个 JWT 架构下，我们再来看看请求打到服务器 B 会发生什么。
服务器 B 收到请求后，它根本不去查什么内存。它只需要用同样的公钥/密钥，极其迅速地对这串 Token 进行一次数学层面的签名验签（Verify）。
只要算出来的签名是对的，服务器 B 就绝对信任这个 Token，瞬间就能提取出 userId = 1024，并继续执行保存答卷的逻辑。
魔法就此诞生：
- 无论是服务器 A、B、C 还是临时拉起的 Z，任何人都能随时接管任何请求。
- 即使那台最初让他登录的服务器 A 爆炸了烧毁了，该学生在集群里继续做题也不会有任何感知，丝毫不会掉线。
- 运维可以在双十一或者开学早高峰，利用 Kubernetes（K8s）在 1 分钟内极其狂暴地拉起 50 台后端节点，由于彻底的无状态化，这些节点瞬间就能满血投入战斗。
极其克制的安全妥协
当然，JWT 并非完美。它最大的软肋在于“难以被服务器主动注销”。既然服务器不记状态，如果发现某人的账号被盗，想踢他下线，服务器该怎么做？
此时技术团队必须引入极客的妥协策略：双 Token 机制与极其微小的 Redis 黑名单。
发给前端的 Access Token 寿命极其短暂（比如只有 15 分钟），保证泄漏的危害时间极短。同时在 Redis 维持一个小型的注销黑名单。这种设计在享受了无状态无限扩容带来的极致吞吐的同时，又守住了账号安全的红线。
总结
在云原生 B 端架构的演进史中，从有状态的 Session 蜕变到无状态的 JWT，是技术团队跨越单机物理极限的最关键一跃。
通过将状态管理极其巧妙地从服务器内存下放到了数学加密签名中，架构师彻底粉碎了节点之间的依赖羁绊，让心理测评后端的量表引擎真正获得了在云端无限繁衍、极速伸缩的自由。