2. 平台门户架构简介
平台门户作为企业级服务的中枢接入点，承担着统一认证、服务路由、资源聚合与安全管控的核心职责。在基线核验通信机制中，门户架构决定了核验请求的流转路径、模块间的协作方式以及对外部系统的适配能力。本节从总体架构、核心模块划分、外部交互方式三个维度展开说明。
2.1 总体架构
平台门户采用分层解耦 + 微服务网关的混合架构，自上而下分为四层：
| 层级 | 名称 | 职责说明 |
|---|---|---|
| L1 | 接入层 | 统一入口、SSL 卸载、限流熔断、反爬虫 |
| L2 | 网关层 | 路由分发、协议转换、身份令牌校验、基线核验前置过滤 |
| L3 | 业务服务层 | 资源管理、认证授权、核验引擎、审计日志 |
| L4 | 数据与基础设施层 | 关系库、缓存、消息队列、配置中心、容器编排 |
各层之间通过内部 RPC（gRPC/Thrift）或异步消息（Kafka/RocketMQ）进行通信，层间调用必须经过网关层管控，禁止业务服务直接暴露到公网。
架构要点： 基线核验请求从接入层进入后，在网关层完成身份预检与协议适配，再路由至业务服务层的核验引擎模块。这种分层设计使得核验逻辑与接入协议解耦，支持 HTTP、gRPC、MQTT 等多协议统一接入。
2.2 核心模块划分
平台门户内部按功能域划分为以下核心模块，每个模块对应一个或多个微服务实例：
| 模块名称 | 服务角色 | 与基线核验的关联 |
|---|---|---|
| 统一认证中心 | OAuth2 / OIDC 令牌颁发、SSO 单点登录 | 核验请求携带的 access_ 由本模块签发 |
| 资源注册中心 | 管理受保护资源（API、数据、设备）的元数据 | 基线核验的目标资源列表由本模块维护 |
| 基线核验引擎 | 执行资源与基线模板的比对、差异计算、结果判定 | 核心执行单元，接收网关转发的核验请求 |
| 策略决策点 | 基于规则引擎做动态授权决策 | 核验通过后触发资源访问策略评估 |
| 审计日志服务 | 记录所有核验操作与结果，支持追溯 | 每条核验记录持久化，用于合规审计 |
| 配置管理中心 | 统一管理基线模板、阈值、黑白名单 | 核验引擎运行时加载的基线配置来源 |
模块间依赖关系： 基线核验引擎依赖资源注册中心获取资源元数据，依赖配置管理中心获取基线模板，核验结果同时写入审计日志服务。策略决策点仅在核验通过后参与授权判定，不直接介入核验过程。
2.3 门户与外部系统的交互方式
平台门户需要与三类外部系统进行通信：上游客户端（浏览器、移动端、IoT 设备）、下游业务系统（CRM、ERP、SCM）、第三方平台（身份提供商、外部审计系统）。交互方式分为同步与异步两种模式：
2.3.1 同步交互（REST / gRPC）
- 场景： 客户端发起基线核验请求、实时查询核验结果。
- 协议： 对外使用 HTTPS + JSON，对内使用 gRPC + Protobuf。
- 超时控制： 网关层统一设置 5s 超时，核验引擎内部调用不超过 3s。
- 重试策略： 幂等接口支持最多 2 次自动重试，非幂等接口不重试。
2.3.2 异步交互（消息队列）
- 场景： 批量基线核验、核验结果回调、资源变更通知。
- 中间件： Apache Kafka / RocketMQ，保证至少一次投递。
- 消息格式： 统一使用 CloudEvents 规范，携带核验上下文 ID。
- 死信处理： 消费失败的消息进入死信队列，人工介入后重放。
交互安全约束： 所有外部系统与门户的通信必须经过网关层，禁止业务服务直接暴露端口。同步接口必须携带 JWT 令牌，异步消息必须携带签名（HMAC-SHA256）。基线核验请求的令牌有效期不得超过 15 分钟。
2.4 架构设计要点总结
- 分层隔离： 接入层、网关层、业务服务层、数据层严格分离，层间通过 API 网关或消息队列通信，避免服务间直接耦合。
- 网关前置： 基线核验请求在网关层完成令牌校验、协议转换、限流熔断，降低核验引擎的接入复杂度。
- 模块化核验： 核验引擎作为独立模块，与认证、资源管理、配置管理解耦，便于独立扩缩容和版本迭代。
- 双模交互： 实时核验走同步 REST/gRPC，批量核验与事件通知走异步 MQ，兼顾低延迟与高吞吐。
- 安全合规： 所有外部通信强制签名或令牌认证，核验记录全量审计，满足基线合规要求。