Linux中systemd虽不原生支持滚动升级，但可通过套接字激活、信号热切换、多实例反向代理及就绪探针四种方式实现平滑升级：1.套接字激活保持端口连续；2.信号控制主进程热替换；3.多实例+反向代理灰度切换；4.集成readiness probe确保服务就绪。
Linux 中 systemd 服务本身不直接支持“滚动升级”（那是 Kubernetes 或负载均衡集群的概念），但可通过组合 systemd 特性与外部协调机制，实现效果等价的平滑升级——即服务不中断、连接不断开、流量无损切换。关键在于避免直接 restart，转而利用进程替换、套接字传递和健康状态协同。
用 systemd 套接字激活保持端口连续
这是最接近“无缝”的原生方案，适用于监听网络端口的长期服务（如自研 HTTP 服务、RPC 服务）：
- 将服务拆为两个 unit：一个
.socket单元负责监听端口并按需启动服务；一个.service单元定义实际进程 - 旧服务运行时，systemd 已持有监听 socket 描述符；新版本 service 启动后，systemd 自动把该描述符传递给它
- 旧进程退出时，不会关闭端口，新进程立即接管所有待处理连接和新建连接
- 操作示例：
sudo systemctl daemon-reload && sudo systemctl restart myapp.service（前提是已配置 socket 激活）
用信号控制主进程热切换（类 Nginx 模式）
适用于自身支持热重载的服务（如 Nginx、OpenResty、某些 Go/Python 服务）：
- 新二进制编译完成，替换
/usr/local/bin/myapp，但不重启 service - 向主进程发送
SIGUSR2（或自定义信号），触发其 fork 新进程、复用监听 socket - 再发
SIGWINCH让旧 worker 优雅退出，只处理完已有请求 - systemd 不感知进程替换，仍认为服务“active”，无需 reload unit
多实例 + 反向代理灰度切换
当服务不支持热替换时，这是最通用可靠的方案：
- 部署新版本为独立 service（如
myapp-v2.service），使用不同端口或 Unix socket - 通过 Nginx / HAProxy / Envoy 将流量逐步从 v1 切到 v2（按比例或按健康检查结果）
- 确认 v2 稳定后，停用 v1：
sudo systemctl stop myapp-v1.service && sudo systemctl disable myapp-v1.service - 整个过程由 proxy 控制，systemd 只负责单个实例生命周期，不参与协调
配合 readiness probe 实现自动化验证
单纯启动新进程不等于服务就绪，systemd 可集成健康检查：
- 在
.service中配置ExecStartPost=调用本地探针脚本，等待端口响应或 API 返回 200 - 或用
Type=notify+systemd-notify --ready，让服务主动上报就绪状态 - 搭配
Restart=on-failure和StartLimitIntervalSec=60，防止启动失败反复拉起
