4. 仲裁接口的总体架构：四层架构设计
跨项目仲裁接口并非单一API，而是一个具备完整治理能力的架构体系。为应对多项目间的资源冲突、优先级争议与决策追溯需求，我们采用接口层、仲裁逻辑层、数据层、监控层四层架构。每一层职责清晰、边界明确，既保障了仲裁流程的标准化，也为后续扩展提供了弹性空间。
4.1 四层架构总览
下图展示了仲裁接口的四层纵向结构，以及各层之间的调用关系与数据流向。
4.2 接口层：统一接入与安全防护
接口层是仲裁系统的对外门户，负责接收来自各项目管理系统、PMO工具或自动化脚本的仲裁请求。其核心职责包括：
- 协议适配：同时支持 RESTful API（JSON）与 gRPC（Protobuf），满足同步查询与高性能批量提交场景。
- 认证鉴权：基于 OAuth 2.0 或 API 校验调用方身份，确保只有授权项目或服务可发起仲裁。
- 请求限流与熔断：防止突发流量冲垮仲裁服务，保障核心逻辑的稳定性。
- 参数校验：对入参进行格式与业务规则校验，提前拦截无效请求。
实践建议：接口层应设计为无状态，便于水平扩展。推荐使用 API 网关统一管理路由、限流与日志，将认证逻辑下沉至网关层，减轻仲裁服务压力。
4.3 仲裁逻辑层：核心决策引擎
仲裁逻辑层是四层架构的“大脑”，所有跨项目冲突的识别、评估与裁决均在此完成。该层由以下核心模块组成：
| 模块名称 | 职责描述 | 输入 | 输出 |
|---|---|---|---|
| 冲突检测引擎 | 分析多个项目对同一资源（人力、预算、基础设施）的请求，识别时间窗口重叠或资源超分 | 项目资源请求、资源可用视图 | 冲突记录列表（含冲突类型、涉及项目、资源ID） |
| 优先级计算器 | 基于预设权重（战略对齐度、ROI、风险等级、截止日期）计算各项目请求的优先级分数 | 项目元数据、战略映射表 | 排序后的优先级队列 |
| 资源分配策略 | 执行分配算法（公平份额、加权分配、先到先得、协商式），生成资源分配方案 | 优先级队列、资源池状态 | 分配方案（含资源归属、时间片、约束条件） |
| 决策规则引擎 | 应用组织级仲裁规则（如“关键路径项目优先”“预算超限需人工审批”） | 规则集（可配置化） | 规则触发结果（通过/驳回/升级） |
| 决策记录生成器 | 将仲裁过程与结果封装为标准决策记录（ADR格式），包含上下文、选项、决策理由与影响 | 仲裁过程数据 | 结构化决策记录 |
4.4 数据层：持久化与状态管理
数据层为仲裁过程提供可靠的数据支撑，确保每一次仲裁都有据可查、可追溯。主要数据实体包括：
- 决策记录库：存储所有仲裁决策记录（ADR），支持按项目、时间、资源类型、决策人等多维度检索。
- 项目资源视图：实时维护各项目的资源占用情况，包括已分配、已预留、可用余额等状态。
- 冲突历史库：记录历史冲突的详细信息，用于趋势分析与规则优化。
- 配置字典：存储仲裁规则、权重参数、优先级映射表等动态配置，支持热更新。
注意：数据层必须保证强一致性。仲裁决策一旦生成，资源分配状态应通过分布式事务或 Saga 模式同步更新，避免出现“决策已通过但资源实际未锁定”的脏数据场景。
4.5 监控层：可观测性与持续改进
监控层是四层架构的“眼睛”，负责收集仲裁全链路的运行数据，为运维与治理提供依据。其核心能力包括：
- 仲裁链路追踪：记录每次仲裁请求从接口层到数据层的完整调用链，定位性能瓶颈。
- 决策时效监控：统计仲裁请求的平均处理时间、P99延迟，对超时仲裁进行告警。
- 异常告警：当仲裁失败率突增、资源分配冲突率过高或规则引擎抛出异常时，自动触发告警通知。
- 审计日志：记录所有仲裁操作的操作人、操作时间、变更内容，满足合规审计要求。
下图展示了监控层与其它三层之间的数据采集关系：
4.6 四层架构的协同工作流
一次完整的跨项目仲裁请求，在四层架构中的流转路径如下：
- 接口层接收仲裁请求，完成认证与参数校验，将合法请求转发至仲裁逻辑层。
- 仲裁逻辑层的冲突检测引擎从数据层读取当前资源视图，识别冲突。
- 优先级计算器与规则引擎协同工作，生成仲裁结论。
- 决策记录生成器将结论写入数据层的决策记录库，并更新资源视图。
- 监控层采集本次仲裁的耗时、规则命中情况与结果状态，写入审计日志。
- 接口层将仲裁结果（通过/驳回/升级）返回给调用方。
关键设计原则：四层之间通过明确的接口契约解耦。接口层不感知仲裁逻辑，仲裁逻辑层不直接操作数据库，数据层不关心监控采集方式。这种分层设计使得每一层都可以独立演进、独立扩缩容。