5.4 部署与维护：不间断值班体系

5.4 部署与维护：不间断值班体系

本节摘要：部署是把代码变成服务，维护是让服务长期值班。本节覆盖交叉编译与静态二进制的部署红利、优雅退出的标准实现、健康检查与观测接入，以及版本回滚预案。读完本节，你的服务上线有标准动作、退出有体面流程、故障有回头路。

依赖管清了，本节走交付的最后一道工序。Go 在这一环有天然优势：构建产物是一个静态链接的可执行文件，不需要目标机器装运行时，交叉编译只改两个变量。部署的本该复杂的工序被语言特性大幅简化，剩下的是纪律：怎么停得体面、怎么被监控系统看见、出问题怎么回头。

一份二进制的红利

$ set GOOS=linux&& set GOARCH=amd64&& go build -o gateway ./cmd/gateway
$ go version -m gateway
./gateway: go1.22.5
	dep github.com/pkg/errors	v0.9.1	h1:...
​

第一条命令在本机为 Linux 服务器产出可执行文件，大小通常在个位数到几十兆之间；第二条查看产物的构建信息与依赖清单，审计时对得上账。放进容器也极简：基于最小基础镜像，拷入二进制加证书即可，镜像体积以兆计，拉取启动都快。这个红利反复兑现：发布快、回滚快、故障机器上少一层环境变量。

优雅退出：下班要有交接单

进程被杀时直接断掉在途请求，是很多深夜故障的放大器。优雅退出的标准实现是：收信号、广播 context、等业务收尾、限时兜底：

package main

import (
	"context"
	"fmt"
	"os/signal"
	"sync"
	"syscall"
	"time"
)

func main() {
	ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
	defer stop()

	var wg sync.WaitGroup
	// 启动 N 个业务 goroutine，全部监听 ctx
	for w := 1; w <= 3; w++ {
		wg.Add(1)
		go func(id int) {
			defer wg.Done()
			for {
				select {
				case <-ctx.Done(): // 收工铃：部署方发来停止信号
					fmt.Printf("员工%d 完成手头工作退出\n", id)
					return
				default:
					// 处理业务
				}
			}
		}(w)
	}

	<-ctx.Done() // 主 goroutine 等铃
	fmt.Println("收到停止信号，等待员工收尾……")

	done := make(chan struct{})
	go func() { wg.Wait(); close(done) }()

	select {
	case <-done:
		fmt.Println("全员收尾完毕，体面退出")
	case <-time.After(10 * time.Second): // 兜底：收尾超时强制离场
		fmt.Println("收尾超时，强制退出")
	}
}
// 部署方发送 SIGTERM 后输出:
// 收到停止信号，等待员工收尾……
// 员工2 完成手头工作退出
// 员工1 完成手头工作退出
// 员工3 完成手头工作退出
// 全员收尾完毕，体面退出
​

这段模板把 3.6 的取消树接到运维信号上：signal.NotifyContext 把系统信号转成 context 取消，业务 goroutine 无感知地沿用同一套收工机制。兜底超时必不可少——总有第三方调用不理会取消，无限等待会让发布脚本卡死。

图 5-2：从提交到回滚的值班流水线

配置与发布单

部署的另一半工件是配置。经验法则是配置与二进制同源不同发：环境地址、容量参数、超时预算放配置，随环境注入；业务语义的开关放代码评审，随版本发布。启动时把生效配置完整打进结构化日志，凌晨排障时"这个实例此刻跑的是什么参数"一查便知，这是最便宜的可观测性投资。

发布单则是一份清单化的操作脚本：本次发布包含哪些变更、预期指标怎么动、观察期多久、回滚触发条件是什么。"回滚触发条件"要写成可执行的判断而不是感觉——错误率超过基线若干倍、持续若干分钟，即自动或手动回滚。写不出现象级判断的发布，说明变更是什么影响了什么都说不清，那就还没准备好上线。

健康检查与观测接入

容器与负载均衡需要两个探针接口：探活回答"进程还活着吗"，挂了就重启；就绪回答"能接流量吗"，没就绪就不派活。两者的区别在故障场景下生死攸关——下游短暂不可用时应该摘流量（就绪失败）而不是自杀（探活失败），重启解决不了依赖问题。观测侧沿用 4.3 的大屏：指标暴露延迟、错误率、goroutine 数量与队列深度，结构化日志带请求级追踪号，告警阈值按 4.5 的症状类别设置。

回滚与维护纪律

上线方案从第一天起就要包含回滚：旧版本产物保留在发布位，配置兼容新旧两代，数据迁移与代码发布解耦（先加宽表结构，发代码，最后收窄）。回滚演练与发布演练同等重要——没演练过的回滚等于没有回滚。日常维护则是轻活：补测试、跑审计、看大屏、按 4.5 手册处理偶发事故。

完整案例：并发采集服务的第一次上线

背景：团队写好一个日志采集服务（多工作池加批量上报），首次部署到生产。

操作：交叉编译出 Linux 二进制；容器镜像内置探活与就绪两个探针；发布脚本先上灰度实例，观察指标基线三十分钟；滚动替换存量实例，每批之间等待错误率平稳；旧版本产物保留三个版本；上线后第一周每天过一遍 goroutine 基线。

结果：发布全程无感，在途请求零失败；第三天一次下游抖动中就绪探针正确摘除流量，未产生超时告警；基线稳定，无泄露迹象。

解读：这次顺利上线没有用到一个新语法——全部是前几章工程纪律的执行。特别注意基线观察的意义：goroutine 与内存的泄露都是慢性病，上线首周不看基线，等报警时已积重难返。

变式：服务要跑在边缘小内存设备上怎么办？构建时用编译参数裁剪调试信息缩小体积，运行时用 GOGC 与内存上限调节回收激进程度，再用 4.3 的基准与剖析验证权衡。同一个二进制在服务器与边缘设备上的调优侧重完全不同——"一次构建、按目标调参"是 Go 部署体系的弹性所在。

收班要点

• 静态二进制加交叉编译是 Go 部署的红利：产物单文件、环境零依赖、版本信息可查。
• 优雅退出四步：信号转 context、广播收工、WaitGroup 等待、超时兜底。
• 探活与就绪分工明确：重启归探活，摘流量归就绪。
• 回滚从第一天就是发布方案的一部分，没演练过等于没有。
• 上线首周盯基线：goroutine 数量、内存曲线、错误率，慢性病只能早发现。

工程四件套齐了。下一节是全书毕业设计：把并发模式、context、测试、部署一次用全，交付一条完整的并发文件处理流水线。