第 16 篇：容器化后端生产最佳实践#

2.1 生产基线不是清单而是契约#

生产基线不是上线前临时勾选的一张表，而是服务和平台之间的契约。后端服务承诺提供健康检查、结构化日志、指标、优雅停机、配置读取方式和依赖超时；平台承诺提供镜像仓库、调度资源、密钥注入、发布控制、日志指标采集、告警和回滚能力。任何一方只写“建议”而不落到门禁，都会在事故中退化成口头经验。

一份可靠的生产基线至少要回答五个问题：这个服务从哪个镜像 digest 启动，运行时读取哪些配置和密钥，资源容量依据是什么，发布失败如何恢复，故障时哪些指标和日志能证明问题边界。只有这些问题都有可执行答案，容器化才从“部署方式”变成“运行体系”。

2.2 不可变发布与可回滚状态#

不可变发布的对象不只是镜像。生产中的一次发布应该绑定代码版本、镜像 digest、配置版本、数据库变更、灰度策略、Feature Flag、依赖版本和发布单。只回滚镜像而不回滚配置，常常会制造更隐蔽的问题；只回滚应用而不处理数据库 schema，也可能让旧版本读到不兼容的数据。

更稳妥的做法是把发布输入完整记录下来，并在变更设计阶段写清楚回滚路径。镜像要固定 digest，配置要有版本和变更记录，数据库迁移要尽量向前兼容，外部开关要能独立关闭，发布系统要能把“当前线上状态”与“目标状态”做 diff。不可变发布的价值不在于形式干净，而在于事故中可以准确复现和撤销。

2.3 运行时治理闭环#

运行时治理关注服务进入集群之后如何持续保持安全、稳定和可观测。它包括资源 requests 与 limits、HPA 或 KEDA、PodDisruptionBudget、readiness/liveness/startup probes、terminationGracePeriodSeconds、安全上下文、RBAC、NetworkPolicy、日志指标追踪采集、告警和应急手册。

这些能力不能彼此孤立。例如 readinessProbe 决定实例什么时候接入流量，优雅停机决定实例什么时候退出流量，PDB 决定节点维护时还能保留多少可用副本，SLO 告警决定发布是否应该暂停或回滚。生产治理的本质是让控制面、应用进程和团队流程围绕同一套信号协作。

3.1 从提交到流量的状态转换#

一次健康的生产发布通常经历以下路径：代码合并后触发 CI，执行单元测试、集成测试和安全扫描；构建镜像并生成 SBOM、漏洞扫描报告和镜像签名；把镜像 digest 写入环境化 manifest；执行策略检查、dry-run 和 diff；在预发环境验证依赖、配置和迁移；进入生产后按滚动、蓝绿或灰度策略放量；监控错误率、延迟、饱和度和业务指标；若超过阈值则暂停或回滚。

这条路径里最重要的是状态要显式。CI 不能只输出“成功”，还要留下测试、扫描、签名和制品记录；发布系统不能只执行 apply，还要记录目标 manifest、审批人、变更窗口和回滚命令；监控系统不能只展示 CPU，还要把版本、实例、路由、错误码和用户影响关联起来。

3.2 控制面与数据面的分工#

Kubernetes 控制面负责把声明的期望状态推进到实际状态，但它不知道你的业务请求是否真的成功。Deployment 可以保证副本数，Service 可以维护 endpoints，kubelet 可以根据探针重启容器，但订单是否能创建、支付回调是否成功、消息是否堆积，需要应用指标和业务探测来证明。

因此，后端服务必须主动暴露生产语义。健康检查应区分进程存活、启动完成、是否可接流量；指标应覆盖 HTTP 错误率、延迟分位数、依赖调用、队列堆积、连接池、JVM 或运行时状态；日志应带 traceId、spanId、用户或租户边界、版本和实例信息。平台提供通道，应用提供语义，两者缺一不可。

3.3 失败优先的发布机制#

生产发布不能只设计成功路径。更可靠的设计是先假设发布会失败，再决定如何限制影响面。灰度发布通过小流量暴露风险，蓝绿发布通过双环境降低切换成本，金丝雀通过分批实例或用户分组观察差异，Feature Flag 让功能开关与镜像发布解耦。

失败优先还意味着回滚必须可演练。团队要知道回滚镜像需要多久，配置回滚由谁执行，数据库变更是否可逆，缓存和消息队列是否需要补偿，告警恢复后是否还要继续观察。没有演练过的回滚流程，在真实事故中往往只是文档。

4.1 一份最小 Deployment#

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: order-api
5
  labels:
6
    app: order-api
7
    owner: backend
8
    version: "2026.07.05-1"
9
spec:
10
  replicas: 3
11
  strategy:
12
    type: RollingUpdate
13
    rollingUpdate:
14
      maxUnavailable: 0
15
      maxSurge: 1
16
  selector:
17
    matchLabels:
18
      app: order-api
19
  template:
20
    metadata:
21
      labels:
22
        app: order-api
23
        version: "2026.07.05-1"
24
    spec:
25
      terminationGracePeriodSeconds: 45
26
      containers:
27
        - name: order-api
28
          image: registry.example.com/backend/order-api@sha256:replace-with-real-digest
29
          ports:
30
            - containerPort: 8080
31
          envFrom:
32
            - configMapRef:
33
                name: order-api-config
34
            - secretRef:
35
                name: order-api-secret
36
          resources:
37
            requests:
38
              cpu: "500m"
39
              memory: "768Mi"
40
            limits:
41
              memory: "1Gi"
42
          startupProbe:
43
            httpGet:
44
              path: /actuator/health/startup
45
              port: 8080
46
            failureThreshold: 30
47
            periodSeconds: 2
48
          readinessProbe:
49
            httpGet:
50
              path: /actuator/health/readiness
51
              port: 8080
52
            periodSeconds: 5
53
            failureThreshold: 2
54
          livenessProbe:
55
            httpGet:
56
              path: /actuator/health/liveness
57
              port: 8080
58
            periodSeconds: 10
59
            failureThreshold: 3
60
          securityContext:
61
            runAsNonRoot: true
62
            allowPrivilegeEscalation: false
63
            readOnlyRootFilesystem: true
64
            capabilities:
65
              drop: ["ALL"]

这个示例刻意保留了 digest、labels、resources、probes、terminationGracePeriodSeconds 和 securityContext。它们不是“高级配置”，而是生产服务的最低表达能力：能追踪版本，能控制容量，能判断是否接流量，能安全退出，能限制运行时权限。

4.2 让配置和密钥离开镜像#

镜像应该只包含应用制品和运行依赖，不应该包含环境配置、数据库密码、第三方 token 或生产证书。配置可以通过 ConfigMap、环境变量或挂载文件注入；密钥应通过 Kubernetes Secret、External Secrets、Vault、云厂商 Secret Manager 等机制注入，并结合审计、加密、轮换和最小权限。

需要注意的是，Secret 不是完整的密钥治理平台。它解决的是集群内分发形式，不自动解决来源可信、访问审批、定期轮换、泄漏检测和废弃清理。生产实践中应把密钥生命周期写入流程：谁创建，谁审批，谁能读取，多长时间轮换，轮换是否触发滚动重启，泄漏后如何撤销。

4.3 用探针和终止流程保护流量#

startupProbe、readinessProbe 和 livenessProbe 不应混用。startupProbe 用来保护慢启动服务，避免启动期间被 livenessProbe 误杀；readinessProbe 决定实例是否进入 Service endpoints；livenessProbe 只处理进程不可自愈的死锁或卡死，不应用来检查所有外部依赖。

优雅停机同样关键。服务收到 SIGTERM 后应停止接收新请求，等待正在处理的请求完成，关闭消费者或定时任务，提交必要 offset，释放连接池。Kubernetes 侧应配置合理的 terminationGracePeriodSeconds，应用侧应实现 shutdown hook。否则滚动更新看似成功，用户侧却可能出现连接重置、重复消费或半提交事务。

5.1 镜像供应链：从 tag 到 digest#

生产环境应优先使用镜像 digest，而不是可变 tag。tag 适合人类阅读，digest 才能唯一指向制品内容。CI 构建镜像后，应记录源码提交、构建参数、基础镜像版本、SBOM、漏洞扫描结果、签名信息和 digest，并把 digest 写入发布 manifest。这样回滚时拿到的是同一个制品，而不是同名 tag 下的新内容。

镜像供应链还包括基础镜像治理和构建可复现。后端服务应尽量使用精简基础镜像，固定版本，定期重建以吸收安全补丁；构建阶段和运行阶段分离，避免把编译工具、包管理缓存和临时凭据带入运行镜像；镜像扫描发现高危漏洞时，要区分基础镜像漏洞、应用依赖漏洞和误报，并给出修复 SLA。

5.2 资源容量：requests、limits 与弹性#

requests 是调度承诺，limits 是运行边界。CPU requests 过低会让服务在节点压力下被挤压，memory requests 过低会让调度过度乐观，memory limit 过低会导致 OOMKilled。对于 JVM 服务，还要让容器内存、堆大小、直接内存、线程栈、Metaspace 和缓存之间留出余量，不能只看 -Xmx。

容量设置应该来自压测、历史监控和业务预测，而不是复制模板。上线前至少要知道单副本在目标资源下的吞吐、P95/P99 延迟、错误率、GC 表现、连接池使用率和依赖瓶颈。HPA 可以按 CPU、内存或自定义指标扩缩容，但它不是容量规划的替代品；如果冷启动慢、连接预热重或下游限流严格，盲目扩容反而可能放大故障。

5.3 安全基线：身份、权限与网络#

安全基线要覆盖镜像、Pod、ServiceAccount、RBAC、Secret、网络和运行时。镜像层面要减少攻击面并扫描漏洞；Pod 层面要非 root 运行、禁止提权、只读根文件系统、丢弃 Linux capabilities；权限层面要为服务绑定最小 ServiceAccount 和 RBAC；网络层面要用 NetworkPolicy 或服务网格策略限制东西向访问。

生产安全不应只停留在上线前扫描。运行时同样需要审计和告警，例如异常 exec、异常出网、Secret 读取异常、镜像来源异常、特权容器、HostPath 挂载和跨命名空间访问。安全策略最好通过准入控制器或策略引擎自动阻断，而不是依赖人工 review 记忆。

6.1 Spring Boot 服务的容器边界#

Spring Boot 服务容器化时，最常见的问题是启动慢、内存估算不准和健康检查语义模糊。建议使用 Actuator 区分 liveness、readiness 和 startup，启动阶段不要因为数据库短暂不可用就被 liveness 杀死；readiness 可以包含关键依赖检查，但要避免每次探测都打爆数据库。

JVM 参数应感知容器限制，例如使用 MaxRAMPercentage 控制堆占比，并为非堆内存留空间。日志输出到 stdout/stderr，由平台采集；配置通过环境变量或文件注入，并明确热更新语义。对于消费者服务，还要在停机时先停止拉取新消息，再处理已拉取任务，最后提交 offset。

6.2 数据库、缓存与消息队列依赖#

容器化不会消除外部依赖风险。数据库连接池过大可能在扩容后打满数据库，缓存不可用可能让请求直接击穿到 DB，消息队列积压可能让消费者扩容后触发下游限流。每个依赖都应该有超时、重试、熔断、限流和降级策略，并在指标中暴露调用量、错误率、延迟和饱和度。

数据库迁移要特别谨慎。生产发布最好采用向前兼容策略：先加字段或新表，再发布兼容新旧结构的应用，观察稳定后再清理旧字段。不要把不可逆迁移和应用镜像发布绑成无法拆分的一步，否则回滚时会发现代码能回去，数据结构回不去。

6.3 CI/CD 与环境分层#

开发、测试、预发和生产应该共享同一套模板，但使用不同 overlay 或 values。差异可以体现在副本数、资源、域名、密钥引用、灰度比例和告警阈值上，不应体现在完全不同的 YAML 结构上。结构差异越大，预发验证对生产越没有意义。

CI/CD 流水线需要把质量门禁前置：测试不过不构建，扫描高危不发布，策略检查不通过不 apply，diff 未确认不变更，发布后 SLO 指标恶化要自动暂停或要求人工确认。流水线不是为了“自动点按钮”，而是为了让每次变更留下足够证据。

7.1 发布失败：先恢复服务再分析原因#

发布失败时，先看用户影响和 SLO 是否被破坏。如果错误率、延迟或业务成功率已经越过阈值，应优先暂停发布、切回旧版本、关闭 Feature Flag 或降级依赖。恢复服务之后再分析是镜像问题、配置问题、数据库迁移问题、依赖问题还是容量问题。

排查顺序可以从发布输入开始：比对旧版本与新版本的镜像 digest、ConfigMap/Secret 版本、环境变量、数据库迁移、路由权重和副本状态；再看 Pod events、container exit code、readiness 失败原因、应用日志和关键指标。不要只盯业务日志，因为很多发布问题发生在应用接入流量之前。

7.2 资源异常：用证据区分应用与平台#

资源报警不等于“机器不够”。CPU 高可能是流量上涨、死循环、GC 频繁或压缩加密开销；内存高可能是缓存增长、堆外内存、连接泄漏或 limit 设置过低；重启可能来自 OOMKilled、探针失败、节点驱逐或应用主动退出。每种原因对应的证据不同。

排障时应同时查看应用指标、容器指标和集群事件。应用指标告诉你请求、依赖和业务是否异常；容器指标告诉你 CPU、内存和网络是否饱和；集群事件告诉你调度、驱逐、探针和镜像拉取是否异常。只有把三类证据拼起来，才能判断是扩容、优化代码、调整 limit、修探针还是处理节点问题。

7.3 安全与密钥事故：缩小爆炸半径#

密钥泄漏或权限误配时，不要只删除一个 Secret。应先判断泄漏范围：哪些服务能读到这个 Secret，哪些 Pod 已经挂载，是否进入日志、镜像层、CI 输出或第三方系统。然后执行撤销、轮换、重启相关工作负载、审计访问记录和补充策略阻断。

权限事故的复盘重点是为什么最小权限没有生效。是否使用了默认 ServiceAccount，是否给了命名空间级别过宽权限，是否允许容器提权，是否没有网络隔离，是否缺少准入策略。安全修复要落到模板、策略和门禁，而不是只在当前服务上临时补丁。

8.1 上线清单：把隐性经验变成门禁#

上线清单应覆盖制品、配置、容量、发布、安全、观测和恢复。制品侧确认 digest、扫描、签名和 SBOM；配置侧确认环境差异、Secret 来源和轮换策略；容量侧确认 requests、limits、副本数、压测结果和扩缩容策略；发布侧确认灰度、回滚、数据库迁移和变更窗口；安全侧确认非 root、RBAC、NetworkPolicy 和准入策略；观测侧确认日志、指标、trace、dashboard 和告警；恢复侧确认备份、恢复演练和应急手册。

清单最好由 CI、策略引擎和发布系统自动执行。人工 review 适合判断风险和业务语义，不适合记忆每个字段是否填写。凡是能机器检查的规则，都应该沉淀成模板或门禁。

8.2 SLO、告警与值班手册#

告警应围绕用户体验和错误预算，而不是围绕所有可能波动的资源指标。对后端 API 来说，常见 SLI 包括请求成功率、P95/P99 延迟、关键业务成功率、依赖错误率和队列处理延迟。SLO 则定义一段时间内可接受的目标，例如 30 天内成功率不低于 99.9%。

值班手册要把告警转化为动作。每个高优先级告警都应说明影响判断、第一批检查命令、相关 dashboard、回滚或降级方式、升级联系人和复盘要求。否则告警只会把人叫醒，却不能帮助人恢复服务。

8.3 备份恢复与演练#

备份的价值只有通过恢复证明。数据库、对象存储、配置仓库、镜像仓库、密钥系统和发布记录都可能成为恢复链路的一部分。团队需要明确 RPO 和 RTO：最多能丢多少数据，最长能停多久，并据此设计备份频率、跨区域策略和恢复流程。

演练不应只在灾难恢复项目里做。至少要定期验证从备份恢复一份数据库到隔离环境，验证镜像和配置能重建服务，验证密钥轮换不会破坏启动，验证依赖不可用时服务能降级。没有演练过的备份，不能算生产能力。

9.1 适合引入的场景#

当服务承接生产用户流量、影响收入或核心业务、需要多人协作维护、部署频率较高、依赖数据库和外部服务、或对安全合规有要求时，应尽早建立完整生产基线。此时镜像 digest、配置版本、Secret 治理、资源容量、灰度发布、SLO 告警和回滚演练都不是可选项。

对平台型团队来说，越早把这些能力模板化越划算。一个服务手工补配置还可控，几十个服务各自发挥就会让事故复盘变成考古。模板、策略和门禁的价值在于减少团队间差异，而不是限制工程师判断。

9.2 不适合过度工程化的场景#

临时实验、内部一次性工具、无状态低风险任务或学习环境，不一定需要完整灰度、SLO、复杂网络策略和多区域备份。过度工程化会让反馈周期变慢，也会让团队把注意力花在工具上，而不是验证业务假设。

但“不完整”不等于“无底线”。即使是实验服务，也不应该把密钥写进镜像，不应该使用可变 tag 部署重要环境，不应该默认 root + 特权容器，不应该没有任何日志和退出机制。可以降低治理等级，但不能突破基本安全和可恢复边界。

9.3 团队治理的成熟路径#

推荐的成熟路径是先统一制品和发布记录，再治理配置与密钥，然后补资源容量和探针，接着完善安全基线、可观测性和 SLO，最后把备份恢复、演练和复盘反哺模板。这个顺序能先解决“发布和回滚有没有证据”，再解决“运行和事故有没有边界”。

团队治理的最终目标不是拥有更多平台功能，而是让新人也能按同一套路径上线和排障。一个成熟团队应该能回答：某服务当前线上运行的完整输入是什么，最近一次变更影响了什么，出问题时谁有权限操作，回滚需要多久，复盘结论会如何进入下一次发布门禁。