鉴权处理通常会有三种方案：
- 微服务各自独立鉴权
- 网关统一鉴权
- 混合策略
其中最佳实践是混合策略，即先在网关把简单普遍必要的鉴权过一遍（如游客和已注册用户），再在微服务内部进行详细鉴权（如管理员和内容制作者）。这样即保证了普通用户的访问效率，也避免了代码重复。
权限信息获取
网关要进行统一鉴权首先要获取数据库中存贮的权限信息，而又由于统一大流量鉴权吞吐量大，可以考虑用 redis 缓存优化速度。
由此有一下几种获取流程：
| 方案 | 优点 | 缺点 |
|---|---|---|
| 网关直接查询数据库 | - 实时性强，确保每次请求获取最新权限数据。 - 结构简单，无需额外的缓存层或远程调用。 | - 每次请求都访问数据库，导致数据库压力大，影响性能。 - 扩展性较差，用户和权限数据增多时数据库可能成为瓶颈。 |
| 网关先查 Redis，查不到再查数据库 | - 提高性能，大部分请求直接从 Redis 获取数据，减少数据库访问。 - 降低数据库压力，提高系统稳定性。 | - 可能存在数据一致性问题，需要缓存更新机制。 - 需要额外处理 Redis 维护和更新逻辑，增加系统复杂性。 |
| 网关先查 Redis，查不到再 RPC 调用权限服务 | - 高性能，大部分请求从 Redis 获取，减少数据库和权限服务负担。 - 通过 RPC 访问权限服务，实现网关与权限服务解耦，提高系统灵活性和可维护性。 | - 可能存在网络开销，缓存未命中时需要远程调用，增加通信成本。 - 需要处理 RPC 通信和容错机制，增加系统复杂性。 |
| 网关仅从 Redis 获取数据 | - 最高性能，所有请求直接从 Redis 读取，提升响应速度。 - 彻底减轻数据库压力，数据库负载最小。 | - 可能存在数据一致性问题，必须确保 Redis 数据及时更新。 - 依赖 Redis，高可用性要求高，否则 Redis 故障会影响整个权限系统。 |
总结
- 如果追求实时性，选择 直接查询数据库，但要注意数据库的性能瓶颈。
- 如果想要平衡性能和实时性，选择 Redis + 数据库回源，适合大多数业务场景。
- 如果系统解耦需求强，选择 Redis + RPC 调用权限服务，适用于微服务架构。
- 如果对性能要求极高，选择 仅使用 Redis，但需要完善缓存更新和高可用机制。