微服务架构下数据库单条资源的用户访问权限管控方案咨询

先直接说结论：你提到的两种方案都有明显弊端，更务实的做法是通过集中校验+缓存复用解决重复校验成本高的问题，具体思路如下：

先拆解两种方案的问题 #

• 每个微服务交叉校验：完全不可取。一来重复执行权限检查（比如查数据库、匹配规则）会拉高系统开销；二来每个微服务都要写一套权限校验逻辑，代码冗余到爆炸，后期改权限规则得挨个改服务，维护成本直接上天。
• 给每个资源生成单独AccessToken：听起来省心，但实际坑很多。客户端要管理一堆资源级Token，复杂度飙升；而且Token一旦生成，要是用户权限被收回（比如管理员删了他对资源1的权限），旧Token还能继续用，存在安全漏洞；另外服务端还要维护这些Token的生命周期，又是额外的工作量。

更靠谱的实践方向 #

• 集中式权限校验层：单独搞个权限校验服务，或者在API网关层集成校验逻辑。所有业务请求先过这一层，统一检查用户对目标资源的权限，通过后再转发到对应微服务。同时把校验结果缓存起来（比如用Redis存用户ID-资源ID的权限状态），设置3-5分钟的短有效期，既减少重复校验的成本，又能在权限变更时及时生效。
• 在全局Token中附加已授权资源信息：用户首次访问某资源并通过校验后，把该资源的权限信息加到全局AccessToken里（比如JWT的payload加个allowed_resources数组）。但要注意，一旦用户权限变更，必须让旧Token失效（比如用黑名单机制），或者让客户端主动刷新Token。这种方式适合权限不频繁变动的场景。
• 共享权限缓存：业务微服务之间共用一个权限缓存池，每个服务需要校验时先查缓存，没查到再调用权限服务做校验，查到后把结果存进缓存。这样不用每个微服务都写完整的校验逻辑，只要对接缓存和权限服务就行，复用性更强。

关键注意点 #

不管用哪种方案，业务微服务都不能完全信任客户端传递的权限信息——哪怕是资源级的AccessToken，也要在缓存失效或关键操作时重新校验，防止客户端伪造Token或者权限变更后旧Token被滥用。

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