AI 应用基础设施入门：为什么要用 Docker（前端视角）

戴维南
2 阅读8分钟

0. 一句话先说清

做 AI 应用时，通常不只一个服务，而是“一组服务”协同：
API 服务 + PostgreSQL + Redis + MinIO + Milvus (+ 监控/队列)。
Docker 的价值不是炫技，而是把这组服务标准化、可复现、可一键启动。

1. 三个概念分别是什么

1.1 Docker（准确说是 Docker Engine）

它是“容器运行时引擎”，负责真正创建和运行容器。
你可以理解为：底层执行器。

你平时用的命令：

  • docker build
  • docker run
  • docker ps

本质都在调用 Engine。

1.2 Docker Compose

它是“多容器编排工具”，通过 docker-compose.yml 一次定义多个服务。
你可以理解为：一键拉起整套本地基础设施。

例如，一个 compose 文件就能同时起：

  1. postgres
  2. redis
  3. minio
  4. milvus
  5. 你的 api 服务

1.3 Docker Desktop

它是 Docker 的桌面发行版（Windows/macOS 常见），包含：

  1. Docker Engine
  2. Docker Compose
  3. 图形界面（看容器日志、状态、资源占用）

你可以类比：

  • Docker Desktop 像 Git 的图形化客户端（如 Sourcetree/GitHub Desktop）
  • 它本身不是“新协议”，而是把底层能力打包并提供 GUI，顺便把环境装好

2. 为什么 AI 应用几乎都要 Docker

2.1 服务太多，不可能手动一个个装

AI 应用常见依赖：

  1. PostgreSQL（业务数据）
  2. Redis（缓存/队列）
  3. MinIO（对象存储）
  4. Milvus（向量库）

你当然可以“分别下载安装 + 手动启动”，但代价很高：

  1. 版本不一致（你和同事环境不同）
  2. 启动顺序混乱（今天能跑、明天不行）
  3. 端口冲突难排查
  4. 新人上手慢

2.2 可复现性是团队生命线

用 Docker/Compose 后：

  1. 同一份配置，任何人都能拉起同样环境
  2. CI/CD 里也能跑相同依赖
  3. “我这边能跑”问题显著减少

2.3 部署也更自然

本地用容器，线上通常也是容器（K8s/ECS 等）。
开发和生产差异会更小，迁移成本更低。

3. 不用 Docker 行不行？

可以，但一般只在两种情况：

  1. 你全用云托管（RDS/Redis Cloud/对象存储/向量数据库 SaaS）
  2. 项目非常小，且你能接受环境不一致风险

现实里，即使用云托管，本地开发也常常需要一部分本地依赖。
所以多数团队仍会用 Compose 起最小本地环境。

4. 一个最小可用示例（AI 应用本地依赖）

version: '3.9'
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app
      POSTGRES_DB: appdb
    ports:
      - '5432:5432'

  redis:
    image: redis:7
    ports:
      - '6379:6379'

  minio:
    image: minio/minio:latest
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: minio
      MINIO_ROOT_PASSWORD: minio123
    ports:
      - '9000:9000'
      - '9001:9001'

  milvus:
    image: milvusdb/milvus:v2.4.0
    command: ["milvus", "run", "standalone"]
    ports:
      - '19530:19530'
      - '9091:9091'

启动：

docker compose up -d

5. 为什么“后端先天友好，前端不利”

5.1 后端先天友好

后端天然和基础设施打交道（数据库、缓存、消息队列、存储）。
所以后端工程师对“环境编排、服务依赖、端口和网络”更熟悉。

5.2 前端不利的真实原因

前端日常更多是：

  1. Node 依赖管理
  2. 页面构建和调试
  3. API 对接

突然转到 Docker 时，会遇到：

  1. 容器网络概念不熟
  2. 卷挂载/端口映射不熟
  3. 多服务日志联调成本高

这不是能力问题，是工作上下文差异。

5.3 前端同学的最低可行掌握

先会这 6 个就够用：

  1. docker compose up -d
  2. docker compose ps
  3. docker compose logs -f <service>
  4. docker compose down
  5. 看懂端口映射（宿主机:容器）
  6. 看懂卷挂载（配置/数据持久化）

6. 模型中转站（Gateway）推荐与选型

你提到“中转站”，本质是 统一模型入口网关：
上游可以接多个模型供应商，下游给业务方一个统一 API。

6.1 推荐方案（生产稳妥版）

  1. 主链路：优先接入正规上市企业的云模型平台（稳定性、合规、SLA 更有保障）。
  2. 网关层：自己维护一层统一网关，做协议适配（OpenAI 风格 / Anthropic 风格）。
  3. 成本链路：再接入你提到的“轨迹流动（或类似聚合平台）”作为补充路由，不建议当唯一入口。

6.2 为什么这样选

  1. 稳定性：上市公司平台通常更不容易出现“服务突然消失”的极端风险。
  2. 能力覆盖：推理模型、Embedding、重排、部分数据处理能力通常更全。
  3. 协议统一：网关层把上游差异吃掉，业务代码不必频繁改 SDK。
  4. 成本可控：可以按模型类型做路由（高质量走主链路，低成本走补充链路）。

6.3 “价格适中有优惠”怎么落地

  1. 把请求分级：核心请求与非核心请求分开路由。
  2. 做配额和熔断：避免某个上游价格/稳定性波动拖垮全局。
  3. 每月复盘：按模型统计单次成本、成功率、延迟，再动态调整路由权重。

7. 核心基础设施详解：PostgreSQL + Redis + MinIO + Milvus + Neo4j

7.1 PostgreSQL（关系数据库）

定位：业务主库 + 元数据中心。
典型存：

  1. 用户、租户、权限
  2. 对话会话、工单、任务状态
  3. 文档元信息、检索索引引用关系

AI 场景价值：

  1. 事务一致性强，适合“业务状态机 + Agent 执行状态”。
  2. 结构化 + 半结构化（JSON）混合数据处理更灵活。
  3. 与 pgvector 等扩展生态结合方便（很多 AI 项目直接用）。

7.2 Redis（缓存/队列/临时状态）

定位：高速缓存与短期状态层。
典型存：

  1. 热 Key（会话上下文缓存）
  2. 限流计数
  3. 异步队列（任务分发）

AI 场景价值：

  1. 降低模型前后的状态读写延迟。
  2. 减轻主库压力。
  3. 做实时任务协调（例如流式响应状态）。

7.3 MinIO（对象存储，S3 兼容）

定位：大文件与非结构化数据存储。
典型存：

  1. 上传附件（PDF/图片/Office）
  2. OCR 中间结果
  3. 训练/评测数据集文件

AI 场景价值：

  1. 文档体积大，不适合塞进关系库。
  2. 与文档解析、向量化流水线天然对接。
  3. 本地开发和线上对象存储接口一致（S3 语义）。

7.4 Milvus（向量数据库）

定位：高维向量检索（ANN）引擎。
典型存：

  1. 文档 chunk 向量
  2. 代码片段向量
  3. FAQ/知识卡片向量

AI 场景价值：

  1. 支持大规模相似度检索。
  2. 对 RAG 是核心组件之一。
  3. 能按集合/分区做多租户隔离。

7.5 Neo4j（图数据库）

定位：关系网络与多跳路径查询。
典型存：

  1. 实体-关系图（人、组织、系统、权限）
  2. 代码依赖图（模块、函数、调用关系）
  3. 知识图谱（概念、术语、引用）

什么是图数据库：
把数据建模成 节点（Node）+ 边（Edge）+ 属性（Property），核心是查“关系路径”。

为什么 AI 场景要用图数据库：

  1. 多跳关系检索（A 关联 B，B 关联 C）比关系表拼接更直观。
  2. 适合 GraphRAG / LightRAG 这类“关系优先”的检索。
  3. 对“依赖分析、影响面分析、权限传播分析”非常友好。

8. 为什么很多 AI 团队优先 PostgreSQL，而不是 MySQL

先说结论：
不是 MySQL 不能用，而是 AI 场景下 PostgreSQL 往往更省心。

8.1 PostgreSQL 常见优势（AI 工程视角）

  1. 半结构化数据处理能力强（JSON 查询/聚合更灵活）。
  2. 扩展生态丰富（如 pgvector、全文检索、地理扩展等）。
  3. 复杂查询能力强（CTE、窗口函数、分析查询场景常见）。
  4. 很多 AI 开源项目默认优先给 PostgreSQL 方案。

8.2 MySQL 什么时候也可以

  1. 你团队已深度 MySQL 化，且业务主要是标准 OLTP。
  2. AI 检索层单独放 Milvus/向量服务，不在主库做太多复杂检索。
  3. 你有成熟 DBA 体系，迁移成本高于收益。

8.3 实用决策建议

  1. 新建 AI 平台：优先 PostgreSQL（通常综合成本更低）。
  2. 存量 MySQL 系统：先保持 MySQL，不要硬迁；把 AI 检索层独立出来。
  3. 目标是“系统整体最稳”，不是“数据库宗教之争”。

9. 最终建议

  1. 团队统一一份 docker-compose.yml 作为本地标准环境。
  2. 基础设施最小集建议：PostgreSQL + Redis + MinIO + Milvus，关系检索复杂时加 Neo4j。
  3. 模型接入建议：上游多供应商 + 统一网关协议适配（OpenAI/Anthropic 风格）。
  4. 把服务初始化脚本（建库、建 bucket、建 collection）自动化。
  5. 把“怎么起服务、怎么排错、怎么切换模型路由”写进 README。

一句话：
AI 应用不是一个进程，而是“模型网关 + 多存储 + 多检索 + 多服务”的系统工程。

avatar
文章
阅读
粉丝