2. IDP 自助门户整体架构：分层架构设计

IDP 自助门户作为企业数字身份治理的统一入口，其架构设计必须兼顾高并发接入、复杂业务编排与海量身份数据管理。本节采用经典的三层分层架构模型，将系统解耦为接入层、服务层与数据层，并详细阐述各层职责、组件交互关系及高可用设计原则。

2.1 分层架构总览

下图展示了 IDP 自助门户的核心分层架构，各层通过明确的 API 契约进行通信，实现关注点分离与横向扩展能力。

2.2 接入层设计

接入层是用户与 IDP 门户交互的第一道防线，负责流量接入、安全防护与协议转换。

2.3 服务层组件交互

服务层是业务逻辑的核心，各组件通过事件驱动与同步 API 两种模式协同工作。下图展示了典型的一次用户自助申请权限的组件交互流程。

2.4 数据层设计

数据层采用混合存储架构，根据数据特性选择最合适的存储引擎。

2.5 高可用设计原则

IDP 自助门户作为企业关键基础设施，必须满足 99.99% 以上的可用性要求。以下是核心设计原则：

1. 无状态化：接入层与服务层所有节点均无状态，会话数据下沉至 Redis，支持任意节点故障后请求无缝切换。
2. 冗余部署：每个组件至少部署 2 个实例，跨可用区（AZ）分布，避免单点故障。
3. 熔断降级：当依赖的下游系统（如 AD、HR 系统）响应超时或不可用时，服务层自动熔断并返回降级提示，避免级联故障。
4. 数据多副本：数据库采用主从同步 + 自动故障转移，缓存采用集群分片 + 副本，确保数据不丢失。
5. 灰度发布：新功能通过金丝雀发布逐步放量，配合全链路监控（APM）实时观察错误率与延迟。
6. 定期灾备演练：每季度执行一次跨 AZ 故障切换演练，验证 RTO（恢复时间目标）≤ 5 分钟，RPO（恢复点目标）≤ 1 分钟。

2.6 架构决策记录（ADR）示例

在架构设计过程中，关键决策应记录为 ADR，便于团队回溯与知识传承。