2. 现有IAM模型痛点分析：粗粒度权限、硬编码策略、数据冗余与接口耦合

在重构之前，必须对现有IAM系统的核心痛点进行系统性诊断。多数遗留IAM平台在快速迭代中形成了“粗粒度权限模型 + 硬编码策略逻辑 + 数据冗余存储 + 接口职责模糊”的耦合架构。以下从四个维度展开分析，并给出对应的量化指标与架构影响。

2.1 粗粒度权限：角色爆炸与最小权限缺失

传统RBAC模型通常只定义“角色-权限”两级映射，且权限粒度停留在模块级或菜单级。这种设计导致以下问题：

• 角色数量膨胀：为满足不同岗位的细微差异，运维团队不得不创建大量“影子角色”，如“财务主管_华东区_只读”、“财务主管_华东区_编辑”。
• 最小权限原则失效：用户获得角色后，自动继承该角色绑定的所有粗粒度权限，无法按需剥离单个操作（如仅允许“查看订单”而不允许“导出订单”）。
• 权限审计困难：粗粒度模型下，一个角色可能包含数十个无关权限，安全审计时无法快速定位“谁拥有什么敏感操作”。

2.2 硬编码策略：逻辑分散与变更风险

大量权限校验逻辑直接嵌入在业务代码中，例如：

// 硬编码示例：在订单服务中直接写死权限判断
if (user.getRole().equals("SUPER_ADMIN") || 
    (user.getDept().equals("finance") && order.getAmount() < 10000)) {
    // 允许操作
} else {
    throw new AccessDeniedException("无权限");
}

这种做法的核心缺陷：

• 策略不可见：权限规则散落在数十个微服务的代码仓库中，无法集中查看、审计或导出。
• 变更成本高：修改一条策略需要走完整CI/CD流水线，涉及代码修改、PR评审、回归测试、灰度发布，平均交付周期3~5天。
• 一致性难保证：同一业务规则在不同服务中可能被实现为不同逻辑，导致“一处放行、一处拦截”的安全漏洞。

2.3 数据冗余：权限缓存与数据源不一致

为提升性能，许多IAM系统将用户-角色-权限关系冗余存储在多个缓存层（Redis、本地内存）甚至业务数据库中。这种架构带来以下问题：

• 数据不一致：当权限变更时，缓存未及时失效或更新，导致用户仍持有已撤销的权限（权限残留）。
• 存储膨胀：同一份权限数据在用户服务、订单服务、支付服务中各存一份副本，数据冗余度高达300%~500%。
• 维护复杂度高：每次权限变更需要同步更新多个数据源，一旦某个同步任务失败，系统进入不一致状态。

2.4 接口耦合：职责模糊与契约缺失

现有IAM系统的API设计普遍存在接口职责不单一、数据契约不明确的问题：

• 接口职责模糊：同一个接口既返回用户信息，又返回角色列表，还附带权限判断结果。调用方需要解析复杂嵌套JSON，且接口变更时影响面难以评估。
• 数据契约缺失：接口返回字段没有明确的语义定义和版本管理。例如，permissions字段在不同版本中可能代表“权限ID列表”、“权限名称列表”或“权限对象数组”。
• 调用链混乱：业务服务之间互相调用查询权限，形成网状依赖。一次用户请求可能触发5~8次内部鉴权调用，延迟增加200ms以上。

2.5 痛点总结与重构方向

综合以上分析，现有IAM模型的四大痛点相互强化，形成“技术债螺旋”：