关于国内腾讯，阿里等等互联网公司的主流业务全都不使用 jwt 做鉴权的一些思考

jwt 在 V2EX 也是月经水了，jwt 虽然很优雅，但所有人必须承认的一个客观事实是国内互联网企业，包括腾讯、阿里、美团等等，所使用的主流业务中无一例外没有一个使用 jwt 做鉴权的，边缘业务中即使有也很少，这个贴主要想分享一下对于这种现象的一些个人思考。

首先需要明确的是，我不是对 jwt 有意见。由于鉴权无时无刻不在发生，jwt 的设计从哲学上来讲当然是很优雅的。而且实际业务落地中也确实达到了便于横向扩展的设计目的（通过将白名单映射为黑名单的方式可以有效减轻后端压力），这点我与论坛里一些坚决认为 jwt 啥啥都不行人观点不同，我认为简单业务场景下 jwt 是达到了设计要求的，确实是一种理想方案。

我认为 jwt 尴尬的地方在于，虽然通过补丁处理后能应付简单的状态场景（比如业务场景是签发凭证后用户手机丢了，要求修改密码，屏蔽原凭证，或者用户以不高的频率要求用户组权限升级、降级，比如年费 VIP 用户组等等），但是实际业务需求中对于单个账号的状态往往远比这复杂得多，我觉得这也是国内主流互联网公司不使用 jwt 的原因。

比如典型的业务场景，一个生产业务的后端通常会对接口权限进行多维度上的拦截，比如同一个 IP 以过高频率请求同一地址是会被屏蔽的，而即使你使用多个 IP，如果账号相同，那么还是会被屏蔽，前者是对 IP 的判断，而后者是一种附加在账号上的状态判断。再比如经常有用户权限的频繁变动，比如一个账号短时间内访问频率过高，那么就被加入请稍等权限组，让用户冷静一下，过几小时再放出来，以此类推，类似这种频繁变更状态的业务使用 jwt 显然不合适。

与此同时，由于现代 nosql 的发展，比如 redis 集群远比我们想象中强大，实际生产落地中，即使是日活千万的项目（对大多数人来说这已经是规模相当大的业务了），实际换算的每秒平均请求数也仍小于 redis 集群的负载瓶颈，这也削减了 jwt 在扩展性上的优势。简单来说，虽然 jwt 帮助后端减轻压力，但其实后端并不特别 care 这部分压力，毕竟账号状态往往是 k-v 搜索，而不是复杂 sql 。结合两方面原因，这应该也是主流业务不使用 jwt 的原因。

简单总结的话，我觉得不用 jwt 不是因为 jwt 做的不好，在简单业务场景下 jwt 确实能做的比 uuid 更好，但往往业务需要维护复杂性，导致 jwt 无法胜任。而又由于，一旦有成熟方案，那么理所应当在所有业务中推广这种模式，反过来导致即使简单业务场景里也没什么人使用 jwt 解决，毕竟程序员是最贵的，性能不够可以花钱加，何必折磨自己呢？