科杰企业级系统（技术架构方案）

1. 文档定位

本文档用于给科杰企业级系统提供一套可落地的技术实施级总体方案，目标是：

• 支撑一期先上线；
• 支撑后续模块扩展；
• 支撑多端接入；
• 支撑未来 IoT 和外部协同；
• 控制早期复杂度，避免过度架构。

2. 技术架构设计原则

2.1 业务优先，架构不过度超前

一期不建议直接上重型微服务集群，而建议采用模块化单体 + 清晰领域边界 + 预留服务化拆分能力。

2.2 主档优先，围绕设备和标准资产建模

系统的核心不是订单，也不是工单，而是：

• 标准设计资产；
• 设备主档；
• 一机一档；
• 台账闭环；
• 合规状态。

2.3 多端统一后端

PC、移动端、外部协同页、IoT 接口应尽量共用统一后端能力，通过 BFF 或 API 网关做接口整形。

2.4 强审计、强附件、强状态机

这套系统涉及：

• 图纸版本；
• PLC版本；
• BOM版本；
• 台账补录；
• 合规状态；
• 导出整包资料； 所以必须从底层支持审计、附件、状态流转。

2.5 先支撑 Web + 移动 + 预留 IoT

一期应重点把：

• PC 管理后台
• 移动端现场作业
• IoT 预留接口 打通，而不是一开始做复杂工业实时平台。

3. 总体技术架构

建议采用 6 层结构。

3.1 终端层

• PC 管理后台
• 移动端 H5 / 小程序 / App
• 客户协同门户（后续）
• 供应商/维保商协同门户（后续）
• IoT 设备与边缘网关（后续）

3.2 接入层

• Nginx / API Gateway
• 统一鉴权入口
• BFF（Backend For Frontend）
• 文件下载 / 导出入口

3.3 应用层

按业务域组织模块：

• 用户权限域
• 客户商机域
• 标准设计资产域
• 设备主档域
• 台账域
• 售后域
• 合规域
• 分析域
• 通知域
• 导出域

3.4 领域层

• 领域服务
• 状态机逻辑
• 审批流规则
• 业务校验
• 领域事件

3.5 基础设施层

• MySQL / PostgreSQL
• Redis
• 对象存储（OSS / MinIO）
• 消息队列（RabbitMQ / Kafka）
• 搜索（可后续 Elasticsearch）
• 定时任务调度器

3.6 集成层

• ERP/财务
• OA/审批
• 短信/企业微信/钉钉
• 电子签章
• 视频/地图
• IoT 平台
• 外部监管平台

4. 一期推荐技术选型

4.1 后端

推荐方案：

• Java + Spring Boot + Spring Modulith / Spring Cloud 起步能力

原因：

• 企业系统成熟；
• 权限、审批、导出、调度、附件、集成生态成熟；
• 后续从模块化单体平滑演进到服务化成本较低。

替代可选：

• Node.js / NestJS（适合小团队快速推进，但大型企业系统治理要求下通常不如 Java 稳）
• Go（适合集成与网关层，但业务后台开发效率与通用中后台生态不如 Java）

4.2 前端（PC）

推荐方案：

• Vue 3 + TypeScript + Pinia + Vue Router + Element Plus / Ant Design Vue

原因：

• 中后台生态成熟；
• 表单、表格、权限菜单、导出、审批类页面开发效率高；
• 后续维护成本低。

4.3 移动端

推荐方案：

• H5 + 企业微信/钉钉容器优先 或 UniApp / Taro

原因：

• 日检、维保、工单、扫码、签字等场景偏轻交互；
• 先做轻端，比原生 App 成本低很多；
• 若后期设备扫码、离线采集、蓝牙外设需求增强，再考虑原生混合升级。

4.4 数据库

推荐方案：

• MySQL 8 作为主业务库
• 结合 JSON 字段承载少量扩展属性

原因：

• 业务型系统最稳妥；
• 团队普遍熟悉；
• 配合审计、附件、导出、分页都成熟。

4.5 缓存与会话

• Redis

用途：

• 登录 Token
• 权限缓存
• 字典缓存
• 热点设备摘要
• 导出任务状态

4.6 文件与附件

推荐方案：

• MinIO（私有部署） 或云 OSS

用途：

• 图纸文件
• PLC 文件
• 资料包
• 台账附件
• 签字图片
• 导出压缩包

4.7 消息与异步任务

推荐方案：

• 一期：RabbitMQ
• 中长期：Kafka（当 IoT 实时数据量明显上升时）

应用：

• 导出异步任务
• 通知提醒
• 审批事件
• 档案完整度重算
• IoT 告警事件（后续）

4.8 定时任务调度

推荐方案：

• XXL-Job / Quartz

用途：

• 日检/月检/维保/年检任务生成
• 到期提醒
• 风险状态重算
• 导出包清理
• 数据快照

4.9 日志与可观测性

推荐方案：

• 日志：ELK / Loki + Grafana（后续）
• 监控：Prometheus + Grafana
• 链路：OpenTelemetry（预留）

5. 应用架构建议

5.1 一期建议：模块化单体

原因：

• 需求仍在演化；
• 主数据耦合强；
• 小团队更容易交付；
• 运维成本低；
• 后续可按域拆服务。

5.2 二期以后再考虑领域拆分

建议优先可拆分的域：

• IoT 与运维域
• 导出与文档服务
• 通知服务
• 分析服务
• 外部协同门户

6. 核心技术能力清单

一期必须具备：

• RBAC 权限控制
• 数据范围权限
• 附件中心
• 统一审计日志
• 状态机管理
• 模板化导出
• 异步任务
• 定时任务
• 字典管理
• 多角色菜单控制

7. 非功能要求

7.1 安全性

• 所有登录接口 HTTPS
• Token 鉴权
• 敏感操作审计
• 文件权限校验
• 导出权限校验
• 关键资料防越权下载

7.2 可用性

• 一期目标以“稳定好用”优先，不追求高并发夸张指标
• 支持断点导出、失败重试、任务幂等

7.3 可扩展性

• 模块边界清晰
• 事件驱动预留
• 文件、通知、导出、IoT预留独立能力

7.4 数据可追溯

• 主状态修改必须留痕
• 补录必须留痕
• 文件替换必须留版本记录或审计

8. 部署建议

8.1 一期部署形态

建议：

• 1 套应用服务
• 1 套 MySQL 主库
• 1 套 Redis
• 1 套 MinIO/OSS
• 1 套调度服务
• 1 套 Nginx

8.2 环境划分

• dev 开发环境
• test 测试环境
• prod 生产环境

8.3 容器化建议

• Docker 部署
• 中长期再引入 Kubernetes

原因：

• 早期系统规模没必要直接上复杂容器编排治理；
• 先保证交付速度和部署可控。

9. 演进路线

阶段一

• 模块化单体
• PC + 移动端
• 主数据 + 台账 + 档案 + 合规 + 服务

阶段二

• 增强导出、通知、分析服务
• 打通更多外部系统
• 增加协同门户

阶段三

• 引入 IoT 数据平台
• 引入更强的实时告警与远程运维能力
• 按域拆分独立服务

10. 结论

科杰企业级系统在技术实施上，最优路径不是一开始追求“工业互联网大平台”架势，而是先用模块化单体把主档、标准设计资产、台账、售后、合规这些真正决定系统生命力的核心域做稳，再逐步演进到多端、多服务、IoT 和产业链协同。