2、系统架构概览：追溯平台与OA系统的技术栈、网络拓扑、数据流向
本章聚焦于供应商CAPA整改任务同步场景下，追溯平台与OA系统之间的技术架构关系。理解两个系统的技术栈、网络拓扑及数据流向，是后续接口设计与开发的基础。以下从三个维度展开分析。
2.1 技术栈对比
追溯平台与OA系统在技术选型上存在显著差异，主要体现在数据库、中间件、部署方式及接口协议上。下表列出了核心组件的对比：
| 对比维度 | 追溯平台 | OA系统 |
|---|---|---|
| 核心定位 | 产品全生命周期追溯与质量管理 | 企业流程审批与协同办公 |
| 数据库 | PostgreSQL 14 + TimescaleDB（时序扩展） | MySQL 8.0 + Redis 缓存 |
| 应用框架 | Spring Boot 2.7 + MyBatis-Plus | .NET 6 + Entity Framework Core |
| 消息中间件 | RabbitMQ（异步事件驱动） | 无独立消息队列，依赖数据库轮询 |
| 接口协议 | RESTful API + JSON | WebService + XML（遗留接口） |
| 部署方式 | Docker + Kubernetes（容器化集群） | Windows Server + IIS（单体部署） |
| 认证方式 | OAuth 2.0 + JWT | Session + Cookie |
集成要点： 追溯平台采用微服务架构，接口响应快、可水平扩展；OA系统为传统单体架构，接口调用需注意超时重试与幂等性设计。两者协议差异（JSON vs XML）要求集成网关做协议转换。
2.2 网络拓扑结构
两个系统部署在企业内网的不同网段，通过API网关与ESB（企业服务总线）实现跨网段通信。下图展示了核心网络拓扑关系：
网络隔离说明： 追溯平台部署在DMZ区，OA系统位于办公内网，两者之间通过防火墙策略仅开放指定端口（如443/8443）。ESB承担协议转换与路由转发，避免系统间直接暴露接口。
2.3 数据流向与同步流程
供应商CAPA整改任务的同步涉及三个主要阶段：任务下发、状态回写、附件同步。下图展示了完整的数据流向：
2.4 接口调用时序
一次完整的CAPA整改任务同步，涉及以下关键步骤的时序交互：
- 任务创建： 追溯平台CAPA服务生成整改任务，通过ESB调用OA系统的
CreateTask接口，传入任务参数。 - 任务确认： OA系统返回任务ID与接收确认，追溯平台将任务状态标记为“已下发”。
- 状态轮询： 追溯平台定时任务每5分钟查询OA系统
GetTaskStatus接口，获取任务最新状态。 - 状态回写： OA系统在任务完成时，主动调用追溯平台
UpdateCAPAStatus接口，回写整改结论。 - 附件传输： OA系统将整改附件上传至文件服务器，追溯平台通过ESB文件通道拉取附件并关联至CAPA记录。
注意事项： OA系统的WebService接口基于SOAP协议，响应时间可能超过5秒。追溯平台调用时需设置合理的超时时间（建议10秒），并启用连接池避免线程阻塞。同时，OA数据库的轮询频率不宜过高，防止对生产库造成压力。
2.5 关键设计决策
- 异步解耦： 追溯平台通过消息队列（RabbitMQ）异步处理任务下发请求，避免同步阻塞影响核心业务。
- 协议适配： ESB层统一将OA的XML/SOAP转换为追溯平台所需的JSON/REST，降低系统间耦合。
- 幂等设计： 所有接口调用均支持幂等性，通过CAPA编号+任务ID唯一标识，防止重复创建或重复回写。
- 审计追踪： 每次接口调用均记录请求/响应日志，存储在追溯平台的日志审计服务中，用于问题排查与合规审计。