部署与就绪

应用已启动，为什么还不能接收请求

保存部署声明、启动进程、收到就绪通知和发布网关路由，是四个不同的完成点。沿 Yaoploy 到 Yaogress 的路径，逐项判断一个副本何时可以对外服务。

先说明“部署完成”指哪件事

一份 App 声明保存的是希望运行什么、运行多少份，以及是否公开 HTTP 服务。它提交成功后，Yaoploy 才依据当前受管节点分配任务；节点仍需取得镜像、准备运行环境并启动应用。声明写入与这些动作并非同一事务。

这里采用设计中明确区分的四类结果：声明已保存、子进程存活、实例符合就绪条件、网关配置与当前端点一致。把它们分别呈现，才能解释“进程在运行，但访问尚未成功”这一常见状态。下文说明规范中的判断方法，不将验收要求当作已完成的部署报告。

对于带 Listener 的应用，Agent 先绑定真实监听套接字，再把同一个文件描述符交给子进程。就绪通知使用另一条专用管道：当前仍存活的子进程写入规定的单字节并关闭管道，Agent 才接纳 Ready。仅仅分配到端口、看到 PID，或先收到那个字节而尚未读到管道结束，都不构成完整通知。

Agent 的本地 Ready 还要与服务器的当前会话、已采用计划、镜像和监听绑定相符，才会进入公开端点集合。旧进程迟到的通知不能替新进程就绪。没有 Listener 的 worker 使用不同约定：前台子进程存活即可成为 Ready，其业务处理是否成功仍由应用判断。

考虑一个示例：应用要求两份副本，节点 A 的控制连接中断，服务器随后把替代任务交给节点 C。当前受管集合可以重新达到两份，但 A 上的进程未必已经退出。副本数描述的是当前管理范围内的收敛目标，并非所有机器上的全局执行上限。

因此，数据库写入排他、订单去重和外部资源授权不能依靠“副本数为一”来代替。应用需要在自己的业务边界解决这些问题。与此同时，Agent 仍须保留本机未结束的子进程、套接字和挂载责任；退出管理范围不会清除这些实际资源。

每个公开 App 对应一个完整的 Yaogress Service，包含全部选定域名后缀和全部合格 Ready 后端。没有 Ready 后端时，不保留一个看似可用的空服务；遇到其他所有者的路由冲突时，也不会只发布未冲突的那一部分。执行状态和网关状态分别记录，便于定位卡在哪一层。

即使配置显示 Synced，它也只说明当时观察到的完整 Service 与目标一致。实际 HTTP 请求到来后，Yaogress 才按 Host 先查 Exact、未命中再查 Any，并为本次交换固定一个后端。连接或传输失败不会触发另一次业务请求来“补成功”，因此还应观察一次真正的应用响应。

排查可以从已获得的最强事实向前走。重复提交同一部署声明无法替代就绪通知，重复刷新网关页面也不能证明应用已经完成清理。下列顺序保留当前对象和当前观察，不要求把每一层都变成新的控制流程。

验证应独立观察进程、控制会话、服务记录和 HTTP 交换。单看某个页面显示绿色，无法证明这些绑定正确。以下情形来自设计中的验收要求，目标是分别排除旧通知、范围扩大与部分路由发布。