私有化架构的核心不是组件名称，而是边界可解释：谁能访问入口、认证在哪里发生、文件落到哪里、哪个服务调用模型、日志和备份由谁管理。只有把这些路径画清楚，才能检查数据是否真的不出域，并为容量、故障和审计制定方案。
五个逻辑层
| 层 | 主要组件 | 职责 |
|---|---|---|
| 访问层 | 用户浏览器、内网 DNS、TLS 入口 | 提供 Web 访问，执行网络准入与证书终结；终端不直接连接数据库或模型 |
| 网关与身份层 | API 网关、账号与组织服务 | 认证请求、传递用户上下文、执行 API 路由与账号组织管理 |
| 业务与处理层 | 知识、文档、文档解析、音频、算力等微服务 | 处理上传、元数据、解析任务、检索、问答、写作、审核、会议与资源视图 |
| 模型层 | vLLM 路由及本地模型服务 | 为大模型、视觉、向量、精排和语音链路提供内网推理能力 |
| 数据层 | MySQL、MinIO | 保存账号与业务结构数据，以及文档、音频、附件和处理产物 |
一份文档的典型数据流
- 用户通过浏览器和 TLS 入口登录，API 网关验证身份后把上传请求转给业务服务。
- 文档原文件写入 MinIO，文档元数据与处理状态写入 MySQL；业务服务派发解析任务。
- 解析服务从对象存储读取文件，按类型执行文本、Office、PDF 或 VLM-OCR 处理，并写回结构化结果与产物。
- 完成的内容进入索引和检索范围；用户提问时，知识服务在授权范围内召回材料并通过内网模型服务组织回答。
- 回答携带引用信息，用户可回看原文；操作与保留信息按照部署和审计策略管理。
持久化与无状态边界
业务微服务本身不依赖各自的本地数据盘，持久数据集中写入 MySQL 和 MinIO。这有利于重建应用 Pod，但不意味着系统天然高可用：如果数据库、对象存储或其底层磁盘仍是单点，应用副本增加也无法避免数据层中断。生产方案需要根据可用性目标设计数据库与对象存储冗余、磁盘故障域、备份和恢复。
K3s 中声明的存储容量不一定等于物理硬配额。磁盘扩容、监控告警和容量隔离要结合实际存储实现确认。
网络与安全设计清单
入口边界
确定内外网入口、TLS、域名、反向代理、访问控制与上传大小 / 超时策略；模型和数据服务不直接暴露给终端。
服务边界
限制命名空间和服务间访问，保护数据库、对象存储和模型接口凭据，避免把内部管理接口暴露为公网路由。
身份与权限
建立账号、组织、知识库和管理员职责矩阵；对离职、调岗、共享账号与高权限操作建立复核流程。
恢复与升级
数据库和对象存储需要一致的备份策略；离线升级前验证包完整性、版本兼容、备份可恢复和回滚路径。
高可用不是默认标签
当前部署可按项目规模从单节点起步，也可结合既有集群设计多节点，但副本数、数据库拓扑、对象存储拓扑、GPU 服务冗余、入口负载均衡和机房故障域必须逐项确认。对关键业务，应基于恢复时间目标（RTO）与恢复点目标（RPO）做故障演练，而不是仅凭“容器化”判断系统具备高可用。