AI 助手 03：先确认依赖就绪，再宣布服务可用

今天这轮迭代从项目骨架推进到 V1 对话闭环，但最先要解决的不是聊天页面，而是“服务究竟什么时候真的可用”。企业 AI 应用比普通 Web 服务多了一层依赖：除了数据库和缓存，还会依赖向量库、模型服务或模型网关。容器进程启动，并不代表这些依赖已经可连接、可查询。

所以当前项目把 V0 的基础环境设计成 Docker Compose 一键启动，并明确区分存活检查（liveness）和就绪检查（readiness）。

当前环境的职责划分

Enterprise AI Assistant Platform 的 V0/V1 本地运行依赖和健康检查路径

Compose 一共编排了六类服务：PostgreSQL 保存业务数据、会话与调用日志；Redis 作为后续缓存和异步任务的基础依赖；etcd 与 MinIO 支撑 Milvus standalone；Milvus 为后续 RAG 向量检索准备；Python 服务承接模型和检索生态；Java 服务承接业务 API、上下文与审计边界。Vue 前端最后通过 Java API 使用这些能力。

这里没有试图把所有事都塞进一个服务。Java 与 Python 的拆分让后续的 Spring 业务能力和 Python AI 生态各自演进；但它们也不能各自报“UP”就结束，因为调用链的用户体验取决于最下游依赖是否真正可用。

存活和就绪回答的不是同一件事

Python 服务提供两类接口：

GET /health/live
GET /health 或 /health/ready

/health/live 只说明 FastAPI 进程正在响应，适合判断“容器是否卡死”。/health 和 /health/ready 则分别连接 PostgreSQL、Redis 与 Milvus：任一个失败时返回 503 DEPENDENCY_UNAVAILABLE，同时只暴露依赖状态和异常类型，不泄露连接串或密码。

这避免了一个常见误判：Python 进程虽然活着，但数据库迁移尚未完成、Milvus 尚未能连接时，聊天或 RAG 仍然无法可靠提供服务。对调用方而言，这应该是“暂未就绪”，而不是“服务正常、稍后随机报错”。

Java 也有自己的 /api/health 和 /api/health/live，用于确认业务服务进程。/api/health/python（同样映射为 /api/health/ready）会再调用 Python 的就绪检查。这样前端的系统状态页能同时展示当前请求上下文、Python 服务和其依赖状态，而不是只显示一个绿色的 Java 标识。

启动顺序为什么要写进 Compose

Python 服务依赖 PostgreSQL 与 Redis 的 healthcheck；Milvus 先由 etcd、MinIO 启动，再由 Python 的 readiness 做实际连接验证。Java 则等待 Python 服务通过健康检查后启动。这里的 depends_on 解决的是容器启动先后，readiness 则解决“端口虽然开了、能力却还不可用”的间隙，两者缺一不可。

本地验收从项目根目录开始：

docker compose up -d --build
docker compose ps
Invoke-RestMethod http://localhost:8000/health/live
Invoke-RestMethod http://localhost:8000/health
Invoke-RestMethod http://localhost:8080/api/health
Invoke-RestMethod http://localhost:8080/api/health/python

当 Python readiness 返回 503 时，正确处理方式不是让 Java 假装一切正常，而是通过 /api/health/python 返回明确的下游健康检查失败。系统状态页也会把 Python 标记为不可用，并提示启动对应服务。这样的失败路径在开发期很朴素，却能让排查从“聊天为什么坏了”变成“哪一个依赖没有就绪”。

这一版的边界

当前健康检查适合本地与单机 Compose 验收：每次请求会做实际依赖连接，默认超时为两秒；它还不是 Kubernetes 探针策略，也没有 Prometheus 指标、熔断和持续告警。Milvus 容器的启动不等于已创建业务 collection，后续 RAG 迭代还要把 collection 初始化和索引状态纳入就绪语义。

不过 V0 已经留下一个可复用的判断原则：**功能上线前，先定义依赖未就绪时系统该说什么、前端该显示什么、排查该从哪里开始。**有了这个基础，V1 的对话接口、模型适配和后续知识库能力才能在同一套可验证的运行边界里增长。

至此，今天的迭代记录形成三篇：可验证的对话闭环、请求上下文与权限前置、以及多服务就绪检查。下一次实现新的能力时，我会继续以“已落地的代码、明确的边界和可执行的验收方式”为准，而不提前把路线图写成成果。