Monorepo微服务架构下YOLO实时预测系统的结构优化与共享方案咨询

一、最终Workflow结构 #

采用分层Monorepo结构，既解决共享代码问题，又避免依赖冗余，同时兼顾本地开发便利性：

├── packages/
│   ├── shared/           # 共享核心模块：统一存utils、数据Schema、通用配置
│   │   ├── src/
│   │   │   ├── schemas/  # YOLO推理结果、转换后数据的Schema（比如Pydantic模型、SQLAlchemy映射类）
│   │   │   ├── utils/    # 通用工具：数据格式转换、日志封装、DB连接基类
│   │   │   └── pyproject.toml  # 仅声明共享模块自身依赖（如pydantic、sqlalchemy-core）
│   ├── model-training/   # 独立模型训练服务
│   │   ├── src/
│   │   ├── pyproject.toml
│   │   └── Dockerfile
│   ├── inference-service/# 推理服务：YOLO实时预测+写入Postgres
│   │   ├── src/
│   │   ├── pyproject.toml  # 通过本地路径依赖shared模块，再加yolov5/8、psycopg2等专属依赖
│   │   └── Dockerfile
│   ├── elt-service/      # ELT转换服务：读取原始数据、清洗转换后存新表
│   │   ├── src/
│   │   ├── pyproject.toml  # 依赖shared模块+ pandas、psycopg2等
│   │   └── Dockerfile
│   ├── api-service/      # 数据API服务：暴露最终数据表接口
│   │   ├── src/
│   │   ├── pyproject.toml  # 依赖shared模块+ fastapi、uvicorn等
│   │   └── Dockerfile
│   └── frontend/         # 前端仪表盘
│       ├── src/
│       ├── package.json
│       └── Dockerfile
├── docker-compose.yml    # 本地开发/测试用容器编排
└── README.md

• 本地开发：用包管理工具的本地路径依赖（比如Poetry的shared = { path = "../shared" }，或Pip的-e ../shared），安装后直接运行脚本，不用依赖基础镜像。
• 容器部署：先把shared模块打成wheel包，再在各服务的Dockerfile里安装这个wheel，避免重复打包依赖。示例Dockerfile片段：

  # 构建shared模块的wheel（可单独做一个构建阶段）
  FROM python:3.10-slim as shared-build
  WORKDIR /app
  COPY packages/shared/pyproject.toml packages/shared/poetry.lock ./
  RUN pip install poetry && poetry build --format wheel
  
  # 推理服务的Dockerfile
  FROM python:3.10-slim
  WORKDIR /app
  # 复制并安装共享模块的wheel
  COPY --from=shared-build /app/dist/shared-*.whl ./
  RUN pip install shared-*.whl
  # 安装服务专属依赖
  COPY packages/inference-service/src/ ./src/
  RUN pip install -r requirements.txt
  

二、适用的设计模式 #

• 共享内核模式：把utils和Schema做成所有服务的共享基础，相当于系统的“通用语言”——推理服务输出的检测结果Schema，ELT直接拿来做转换依据，API也用同一个Schema返回给前端，不用每个服务重复定义，彻底避免数据格式不一致的问题。
• 单一职责原则：每个服务只聚焦一件事：训练服务只管迭代YOLO模型、推理服务只管实时预测存DB、ELT服务专门做数据清洗转换、API只对外提供数据接口、前端专注可视化，每个服务独立部署扩容，符合你要的微服务可扩展性需求。
• 数据传输对象（DTO）模式：用shared里的Schema作为数据传输的标准格式，从推理到ELT再到API，数据格式全程统一，减少转换时的出错概率，也方便排查线上问题。

三、动态添加路径的合理性 #

动态添加路径（比如脚本里写sys.path.append("../shared")）仅适合本地临时调试，绝对不能用于生产环境：

• 弊端：
  1. 完全依赖本地目录结构，一旦目录变动就会报错，容器化部署时路径更难控制。
  2. 无法通过包管理工具追踪依赖，容易出现版本不一致、依赖缺失的问题。
  3. IDE无法识别动态路径，代码提示、语法检查全部失效，开发体验极差。
• 替代方案：
  1. 本地开发用包管理工具的本地依赖（如Poetry路径依赖、Pip editable安装）。
  2. 生产环境把共享模块打成wheel包，作为正式依赖安装到各服务，彻底避免动态路径的隐患。

内容的提问来源于stack exchange，提问作者ole