revel 框架无内置平滑重启机制，生产环境必须通过绑定 127.0.0.1、nginx 反向代理、docker compose 多实例+healthcheck+start-first 更新策略协同实现零停机更新。
Revel 框架本身不提供平滑重启能力，必须靠外部进程管理 + Nginx 反向代理 + 容器编排（如 Docker Compose）协同实现无缝更新。 直接用 revel run 或杀进程重启，必然中断连接；生产环境必须剥离 Revel 自带服务器的直接暴露角色。
为什么不能直接用 revel run --graceful 之类？
Revel 没有内置优雅停机或滚动更新机制。它的 revel run 是开发模式工具，启动的是单进程 net/http 服务器，收到 SIGTERM 后立即退出，不会等待请求完成。即使你加了 server.shutdown=graceful（这是 Spring Boot 的配置，Revel 不识别），也完全无效。
常见错误现象包括：
- 用户正在提交表单时，Nginx 报
502 Bad Gateway - 健康检查失败后，新旧实例同时不可用，出现服务空白期
- 多个 Revel 实例共用同一端口，启动时报
bind: address already in use
必须绑定 127.0.0.1 而非 0.0.0.0
这是 Nginx 反向代理生效的前提。如果 Revel 监听 0.0.0.0:8089，它可能被外网直连、绕过 Nginx 的限流/缓存/SSL 终止，更关键的是：健康检查和负载均衡会失效。
正确启动方式（生产环境）：
REVEL_RUNMODE=prod revel run -a myapp -p 8089 -addr 127.0.0.1
要点：
-
-addr 127.0.0.1强制只监听本地回环，拒绝外部连接 -
REVEL_RUNMODE=prod关闭热重载、调试面板等开发特性 - 不要用
revel build后手动运行二进制——仍需进程管理器托管生命周期
Docker Compose 部署时如何避免更新中断？
单副本 replicas: 1 的 Compose 服务永远做不到零停机。必须满足三个硬性条件：
-
replicas: 2或更高（至少两个实例才能交替） - 定义有效的
healthcheck，例如：healthcheck:<br> test: ["CMD", "curl", "-f", "http://localhost:8089/health"]<br> interval: 15s<br> timeout: 5s<br> retries: 3
（注意：Revel 应用需自行暴露/health端点，且必须监听127.0.0.1） -
deploy.update_config显式设置：order: start-first（先启新、再停旧）parallelism: 1（每次只更新一个副本）delay: 10s（给健康检查留出时间）
更新命令必须用：docker compose up -d --no-deps --force-recreate myapp
而不是 up -d 全量重建——后者会触发依赖服务连锁重启，还可能因宿主机端口冲突导致失败。
Nginx reload 是平滑的，但配置错了就不是
nginx -s reload 本身是原子操作，旧 worker 进程会继续处理已有连接，新 worker 接管新连接。但前提是：
- 上游 server 列表已提前更新（比如指向新的 Docker service 名或 IP），否则 reload 只是“平滑地转发到宕机实例”
- proxy 设置中启用连接复用与超时控制，例如：
proxy_http_version 1.1;proxy_set_header Connection '';proxy_read_timeout 60; - 没有在
upstream块里写死容器 IP——Docker 网络里 IP 是动态的，必须用 service name（如myapp:8089）
最容易被忽略的一点：Revel 应用的 /health 端点返回 200 并不等于“已加载全部模块、数据库连接就绪”。它必须真实反映业务就绪状态，否则 Nginx 会把流量切过去，而 Revel 还在初始化阶段——这比中断更危险。
