不用 K8s,自托管也能零停机部署 + 一键回滚(拆开没那么玄)

自托管部署最尴尬的一刻,是你敲下docker stop old docker run new的那几秒——服务对外就是一串 502。用户刚好在这个窗口点进来,看到的就是一个大红页面。回滚更狼狈:线上出事了,你手忙脚乱翻「上一个能用的镜像 tag 是哪个来着」,或者git log里瞪着一串 SHA 猜哪个是上次好的版本。小团队、homelab、内网服务,大多没有 K8s 那套滚动更新 一键回滚。是不是就只能忍这个窗口?我一开始也这么以为。后来真去把它拆开,结论是:零停机部署的核心根本不是 K8s 那套调度,而是三件小事——把新版本先备好、用一个原子操作切过去、切完不对立刻切回。这篇讲清楚里面的门道。一、零停机的本质:把「切换」压缩成一个原子动作先看清楚stop old → run new为什么会 502:这两条命令之间有一段「旧的已经没了、新的还没起」的真空期。窗口再短,只要有请求打进来就是失败。关键的思路转变是:把一次部署拆成**「准备」和「切换」两个阶段**。准备阶段:把新版本完整地放到旁边(新目录 / 新镜像),这期间旧版本原封不动照常服务,零影响。慢一点也无所谓,反正没人受影响。切换阶段:从旧指到新,这一步要尽可能原子——最好压缩成一个内核保证的单步操作,让「真空期」小到不存在或只有一瞬。想通这一点,剩下的就是针对不同产物,找到那个「原子切换动作」。二、文件产物(jar / dist / 静态站):原子软链是标准答案如果你部署的是一个 jar、一份前端 dist、一个静态站,标准解法是软链原子切换:releases/ 20260701-a1b2c3/ - 这次的新版本 20260630-f9e8d7/ - 上一版本 current - releases/20260701-a1b2c3 - 一条软链,应用只认 current部署时先把新版本传到releases/新/,current这条软链先完全不动。等新版本齐了,再切软链。切的时候有个容易踩的细节:# ❌ 有窗口:ln -sfn 是 unlink symlink 两步,中间一瞬 current 不存在ln-sfnreleases/新 current# ✅ 原子:先建临时软链,再用 mv -T 一次 rename(2) 覆盖ln-sfnreleases/新 current.tmpmv-Tcurrent.tmp currentmv -T底层是一次rename(2)系统调用,内核保证原子,绝不会出现 current 指向空的那一瞬。任一时刻,current要么指向完整的旧版本,要么指向完整的新版本,没有中间态。诚实但重要的一点:软链原子了,不代表进程零重启。如果你的应用是长驻进程(比如 jar 起来就在内存里跑),切软链之后还得给它发个 reload 信号,让它重新读current。软链保证的是「任一时刻 current 都指向一个完整版本」,不是「进程不用重启」。这两件事别混为一谈。三、容器:先 pull 后换,把窗口压到秒级容器部署没有软链这一层,但思路一模一样——先准备,再切换:docker pull 新镜像:把新镜像拉到本地。这期间旧容器照跑,零影响。顺手docker inspect记下旧容器当前用的镜像,当回滚锚点。docker rm -f 旧 docker run -d 新:删旧起新,两条命令紧挨着,把窗口压到最小。诚实的取舍:这里rm之后、run完全就绪之前,有一个「无容器」的短窗口,通常是秒级。对绝大多数自托管场景,秒级窗口完全能接受。但别假装它是零窗口——真要做到零窗口,得上蓝绿:先起新容器、验健康、再把反代 upstream 从旧切到新、最后删旧。代价是切换期间同时跑两份、还要反代配合。滚动(秒级窗口)还是蓝绿(零窗口占双份资源),按你的服务重要性选,别无脑上最复杂那个。四、健康检查放在哪:切换之后,失败就回滚新版本切上去了,怎么知道它没崩?切换之后立刻探一下健康 URI,不健康就立刻回滚到上一版本。这里要说清一个方向问题:这是**「切后验证」**,不是「切前灰度」。新版本切换的那一刻就已经对外服务了,健康检查是用来「发现坏了赶紧退」,而不是「验好了才放行」。想要「验好了才放行」,你需要的是蓝绿(先在旁边验健康,过了才切流量)。对小团队,「切后秒级回滚」的性价比通常比「切前灰度」更高——实现简单得多,而代价只是坏版本暴露了几秒。反代层(比如 Caddy)还能再加一层被动健康检查(health_urihealth_interval),把不健康的上游自动踢出负载均衡,多一道兜底。五、一键回滚:别翻镜像 tag,让工具「重发上一次成功」回滚最容易做错的姿势,是靠人脑记忆——「上一个能用的镜像 tag 是v1.3.2还是v1.3.1来着?」出事的时候人是最不可靠的。正确姿势是:系统本来每次部署就存了这次的产物 目标机清单。回滚 找到「上一次全机成功的部署」,把它的产物按原来的目标机重新发一遍。整个过程复用正常部署链路,所以回滚本身也走健康检查、也能再回滚,不是一条特殊的旁路。诚实的取舍,这几条得认清:一键回滚 重新部署历史版本,耗时和成本 ≈ 一次新部署(要重新 pull 镜像 / 重新上传文件)。它不是「秒切回旧容器」。真想秒级切回,得自己留着旧容器不删——那是另一种取舍(常驻占资源)。依赖历史记录:只能回滚到最近 N 次部署里「上一次成功」的版本。如果你把镜像仓库里的老 tag删了,pull就拉不回来,回滚也就失败。老版本的镜像别急着清。一个真踩过的坑,顺便记一笔:部署记录里为了省显示空间,存的是7 位短 SHA。而 go-git 的CommitObjectAPI只认 40 位全 SHA——直接拿短 SHA 去查提交,一律「提交不可达」,功能静默降级。修法是先用ResolveRevision把短 SHA / 分支名 / tag 解析成全 hash,再取提交对象。这种「存的时候图省事存了个缩写、用的时候要还原」的坑,自己搓部署工具时特别容易栽,记一下。六、几个会咬你的坑原子软链只对「切换那一步」原子;应用要不要重启才能读到新版本,是另一回事,得单独配 reload。容器rmrun有秒级窗口,别对外宣称零停机;真要零窗口上蓝绿,认下双份资源的代价。健康检查是切后验证,失败意味着坏版本已经暴露了一小段。能接受就用滚动,不能接受再上蓝绿。首次部署没有「上一版本」可回滚——健康失败就是彻底失败,得人工介入。别指望首发也能自动兜底。回滚成本 ≈ 新部署,不是免费秒切。把它当「一次自动化的重新部署」来预期,而不是「撤销键」。七、后来我把这套也做进了工具里道理拆开都不复杂,但每一环都得自己拼:原子软链的mv -T、容器的先拉后换、蓝绿/滚动的选择、切后健康检查、失败自动回滚、一键重发上一次成功、短 SHA 的ResolveRevision……我把这些连同前几篇讲的 CI 构建、多机部署、Caddy 自动 HTTPS、Per-PR 预览环境,一起塞进了我那个 Go 单二进制部署工具Pipewright:文件产物用原子软链切换,容器先拉后换记回滚锚点,蓝绿 / 滚动两种策略可选;切换后自动跑健康检查,不健康自动回滚到上一版本;一键回滚:在面板上点一下,自动定位上一次全机成功的部署并重发,不用记镜像 tag;部署记录、代码 diff 里的短 SHA 自动ResolveRevision解析,不会「提交不可达」。开源 MIT,单二进制、无运行时依赖(前端embed.FS打进二进制,默认 SQLite),定位个人开发者 / 小团队自托管。仓库:https://github.com/huangchengsir/pipewright但就算你不用它,这篇的核心结论照样成立:零停机部署 先准备 原子切换 切后回滚;一键回滚 重发上一次成功的版本。不用 K8s,自托管也能有这套体验——它没那么玄。欢迎来提 issue 拍砖。