为何百万QPS下正常的鉴权服务，在千万QPS时便会雪崩？本文深入剖析中心化鉴权架构的致命缺陷，揭示其从性能瓶颈到全局单点的演变过程，并提出将远程校验转变为本地计算与连接复用的核心设计思路，为构建千万级并发系统提供关键参考。
智能速览
中心化鉴权在千万QPS下会成为全局性能瓶颈，引发延迟、连接数暴增和雪崩风险。
架构破局的核心是将每请求的远程鉴权，转变为本地计算加连接级复用。
采用自包含Token（如JWT），网关本地验签可将耗时从毫秒级降至微秒级，彻底解放鉴权服务压力。
对于WebSocket等长连接，通过连接建立时鉴权一次，后续复用身份，可使鉴权调用频次降低两个数量级。
生产环境最佳实践是混合架构：HTTP API用自包含Token，长连接用连接复用，敏感操作保留同步校验兜底。
精华内容
当请求量从百万级跃升至千万级，为何看似稳固的鉴权服务会瞬间崩溃？根源在于其中心化设计，它已成为全局最热的单点。突破瓶颈的关键，在于将鉴权开销彻底从请求的关键路径上移除。
中心化的天花板
传统架构下，网关每收到一个请求，都需远程调用鉴权服务验证Token，再将用户身份转发给后端。这种模式在低并发时看似无懈可击，但QPS从百万增至千万时，鉴权服务的复杂度增长远超10倍。
三大瓶颈随之凸显：首先是延迟累加，每次网络往返耗时1-5毫秒，导致P99延迟从1.9ms劣化至5.0ms；其次是连接数暴增，网络开销急剧增加；最致命的是，鉴权服务一旦抖动，便会引发全局性雪崩。
这暴露了中心化架构的天花板，即鉴权服务成为了不可伸缩的全局热点。
自包含Token方案
第一招是将远程查询变为本地计算，其典型实现是自包含Token（如JWT）。它将用户身份、权限、过期时间等全部信息编码进Token，并附加数字签名防篡改。
网关收到请求后，只需用公钥进行本地验签，微秒级即可完成，无需任何远程调用。相比传统模式的3ms网络往返，自包含Token的验签仅需0.01ms，性能优势巨大，使网关可无限水平扩展。
其代价是Token吊销变得困难，但可通过设置短有效期（如15分钟）并配合一个小型吊销列表来解决，网关全量缓存此列表的成本极低。
长连接复用技巧
第二招是将每请求鉴权变为连接级复用，适用于WebSocket、gRPC等长连接场景。在连接建立之初进行一次鉴权，后续该连接上的所有请求都直接复用已验证的身份信息，无需再次鉴权。
这一策略的收益是数量级的。假设千万QPS下有100万长连接，每秒10%的连接是新建立的，那么鉴权服务的调用量从1000万次骤降至10万次，压力降低100倍。
针对用户权限变更的安全风险，可将授权逻辑下沉到业务层，网关缓存通用策略并支持推送更新。一旦Token失效，服务端可主动断开连接，强制客户端重新鉴权。
分层混合架构
在实际生产环境中，单一策略无法应对所有场景，分层处理的混合架构是最佳选择。其核心思想是根据不同业务场景的特点，匹配最合适的鉴权策略。
具体而言，对于无状态的HTTP API，采用自包含Token方案，实现极致的本地化验签；对于IM消息、实时推送等长连接场景，采用连接级复用策略，大幅降低鉴权频次；同时，保留一小部分同步校验逻辑，用于处理支付、注销等高敏感操作的兜底验证。
这种组合拳设计，让鉴权服务在千万QPS下依然能保持低负载，同时兼顾了系统的实时性与安全性。
从百万到千万QPS，API鉴权架构演进的本质，是不断消除中心化依赖，将鉴权开销从请求的关键路径上移除。无论是本地计算还是连接复用，其目标都是将中心化瓶颈分散或消除。未来，随着系统规模的进一步扩大，架构设计是否还能找到新的突破点？
