部署与升级
HeteroFlow 是本站的异构算力与大模型调度产品。部署与升级。大模型调度平台的部署与升级：单一容器镜像内嵌前端，升级与回滚都是原子换容器，不存在前后端版本错配；数据层单机嵌入式起步、生产切 PostgreSQL，每次部署自动产生全量备份。
部署与升级
> 大模型调度平台的部署与升级：单一容器镜像内嵌前端，升级与回滚都是原子换容器，不存在前后端版本错配；数据层单机嵌入式起步、生产切 PostgreSQL，每次部署自动产生全量备份。
1. 部署形态
| 组件 | 形态 |
|---|---|
| 平台主服务 | 单容器镜像（后端 + 嵌入式前端），一个镜像即完整平台 |
| 数据层 | 单机：嵌入式数据库零依赖起步；生产：PostgreSQL（多副本 / 高可用的前提） |
| 配置 | 环境变量注入（数据库连接串、会话密钥等），凭据不落命令行与日志 |
| 备份 | 每次部署自动产生全量备份包，按时间戳轮换保留 |
单机 4 核即可承载开发 / 中等规模使用；生产建议独立数据库实例与数据卷。
2. 标准升级流程（五步，任一步失败自动回滚）
1. 打包：从源码产出部署包；
2. 构建：构建新镜像；
3. trial 冒烟：新容器先在独立临时端口起一个trial 实例，健康检查通过才继续——坏版本到不了线上；
4. 数据备份：替换前自动全量备份；
5. 替换容器：旧容器改名让位、新容器以原名上线。
升级后核对两条：健康检查接口返回正常版本；备份目录出现本次备份包。
3. 回滚纪律（两级命名，认错对象是头号事故根因）
让位后的旧容器分两级命名，语义不同：
| 命名形态 | 身份 | 能否作回滚目标 |
|---|---|---|
| 让位容器（无时间戳后缀） | 本次升级前的容器 | 是，唯一目标 |
| 带时间戳的历史容器 | 上上代及更早，仅为留档 | 否 |
回滚三步，顺序不可省：
1. 演练：回滚脚本先以演练模式跑一遍，确认它识别的目标容器与镜像；
2. 三重 ID 闭合：目标容器镜像 ID = 回滚镜像 tag 指向 ID = 预期版本 ID，三者一致才执行；
3. 执行：删新容器 → 让位容器改回主名并启动 → 健康检查确认。
4. 数据库形态切换（单机 → PostgreSQL）
切换是一次性停机窗口操作，迁移工具内置三步，表清单与应用自动建表同源、永不漂移：
1. 摸底（只读）：列出将迁表、行数与未迁表警示，不写目标库；
2. 执行（幂等）：全量迁移，自增序列逐表校正，日志类大表按保留窗口截断（截断点记录在目标库表注释中）；
3. 校验：逐表行数 + 抽样全字段比对。
切换后核对两条铁证：启动日志显示数据库后端为 PostgreSQL；审计哈希链校验返回零问题（审计链密钥错会立刻表现为大量校验问题）。多实例 / 多副本形态必须显式配置会话密钥，未配置会拒绝启动——这是防呆设计，不是故障。
回滚锚点：源数据文件全程只读保留；用切换前的环境配置重建容器即回到原形态。窗口内新库写入在回滚时会丢失，回滚决定越早做丢得越少。
5. 备份与恢复
- 备份脚本覆盖两种数据库形态（流式导出压缩 / 文件级打包），按时间戳轮换保留 N 份；
- 恢复演练两种形态均真跑过（导出件灌回隔离库零错误 / 文件包完整性校验通过）；
- 纪律：备份目录只增不删（滚动策略除外）；破坏性清理（删容器 / 镜像 / 备份）先归档清单再动手。
6. 日常维护要点
- 磁盘水位：每次部署新增一层镜像与一个备份包，构建缓存也是大头，磁盘水位纳入每周巡检；清理时逐项核对引用，不做无差别清理；
- 登录限流窗口：登录相关接口按 IP 滑动窗口限流，自动化脚本与巡检应「一次登录 + 应用内导航」，避免反复整页刷新触发新的会话刷新请求；撞到限流等窗口自然滑过，不要重试；
- SSO 故障五步检查：身份服务本体应答 → 反向代理连通 → 平台侧 provider 配置的地址与反代前缀一致 → 认票据一次性（重放失败是协议预期）→ 重新走登录；
- 变更纪律：每次变更后更新运维交接文档（版本、回滚目标）；冻结类发布的时间点不得超前实际时间。