微服务设计疑问：用户存在校验用JWT还是事件编排？

现有方案的问题拆解 #

1. 仅依赖JWT校验 #

JWT的无状态特性导致无法主动失效已删除用户的令牌，即便设置15分钟短有效期，仍存在时间窗口内已删除用户可发帖的风险。仅适合对用户删除后发帖限制极低的场景，不符合多数需要严格权限控制的业务需求。

2. 先创建帖子再异步校验用户存在 #

• 核心问题：存在无效操作浪费资源（创建后立即删除），且有短暂时间窗口帖子会被其他用户看到，影响体验。
• 性能风险：高频发帖场景下，异步请求的堆积可能导致服务过载，除非做批量处理，但复杂度较高。

3. 删除用户事件+定时清理帖子 #

• 未解决核心问题：JWT过期前用户仍可正常发帖，定时任务的延迟（比如1小时）会导致脏数据长时间存在。
• 优势：实现简单，适合对“删除用户后立即禁止发帖”要求不高，但需要最终数据一致性的场景。

推荐的最佳实践组合 #

1. 同步校验+缓存优化（核心方案） #

在posts-service处理创建请求时，同步调用user-service的用户状态校验接口（校验用户是否存在且未被删除），但通过缓存降低对user-service的依赖：

• posts-service本地缓存用户状态（活跃/已删除），缓存过期时间设为短于JWT有效期（比如10分钟），避免缓存过期后出现JWT有效但用户已删除的情况。
• user-service删除用户时，主动发送事件通知posts-service立即清理该用户的缓存，确保后续请求能拿到最新状态。
• 给user-service的校验接口添加限流、降级策略：比如限流阈值设为posts-service峰值QPS的1.2倍，降级时直接拒绝创建请求（避免服务雪崩）。

2. 最终一致性兜底 #

保留定时任务（比如每15分钟一次，而非1小时），扫描posts-service中关联已删除用户的帖子并清理，作为同步校验和缓存机制的兜底，避免因缓存清理失败、网络波动等极端情况导致的脏数据残留。

权衡策略总结 #

内容的提问来源于stack exchange，提问作者MB2