部署与运维

写代码只是软件生命周期的开始。把代码稳定、高效、安全地运行在生产环境，并能在故障时快速止血、在业务增长时平滑扩容，是后端工程师的分水岭能力。

部署与运维，看似是"运维同学的事"，但在云原生与 SRE 理念盛行的今天，每一位后端开发都必须理解：

• 为什么本地能跑、生产报错？ 镜像与运行时环境差异。
• 为什么流量一上来就雪崩？ 容量评估、限流、弹性扩容没做对。
• 为什么发版总提心吊胆？ 缺一套可灰度、可回滚的发布流水线。
• 为什么凌晨总被叫醒？ 缺可观测体系，只能靠"用户报障"感知问题。

本章节围绕「让软件可被可靠地交付、运行与观测」这条主线展开，覆盖从容器化、Web Server、CI/CD 到 K8s 编排的完整链路。

⏳ 部署与运维演进时间线

年份	关键事件	解决了什么痛点
2000s	物理机/虚拟机时代	资源利用率低、部署依赖人工、扩缩容慢
2006	AWS EC2 开启 IaaS	按需租用，但环境仍需手动配置
2013	Docker 诞生	"Build once, run anywhere"，环境一致性
2014	Kubernetes 开源	跨主机容器编排，解决大规模调度问题
2015	Docker Compose / Swarm	单机多容器编排的轻量方案
2016	Terraform / IaC 普及	基础设施即代码，环境可版本化、可复现
2017	Helm 1.0	K8s 应用模板化打包与版本管理
2018	Envoy + Istio 推动 Service Mesh	微服务通信治理从应用层下沉到基础设施层
2019	GitHub Actions GA	CI/CD 与代码仓库深度整合，开源友好
2020	GitOps（ArgoCD） 主流化	以 Git 为唯一可信源，声明式部署
2021	eBPF 进入生产	内核级可观测与网络性能调优
2022	BuildKit / Buildpacks 普及	镜像构建更快、更安全
2023	WebAssembly 进入服务端	多语言、跨平台、轻量沙箱
2024+	AI 辅助运维（AIOps）	异常检测、根因分析、自动化 Runbook

核心启示：从「人肉运维」到「GitOps + AIOps」，部署与运维的本质是把可重复的决策自动化，让工程师只处理真正需要判断的异常。

🌳 核心知识树

🐳 一、容器化基础（Docker）

容器化是云原生的第一块基石。它通过命名空间（Namespace）和控制组（Cgroup）实现进程级隔离，让应用与运行环境解耦。

• 核心概念：镜像与容器的关系、分层文件系统（UnionFS / OverlayFS）、Volume 数据持久化、Network 模式（bridge/host/overlay）。
• 镜像优化：多阶段构建（Multi-stage Build）大幅减小体积、.dockerignore 排除无关文件、层缓存策略（先 package.json 再 node_modules）。
• 最佳实践：以非 root 用户运行、设置 HEALTHCHECK、最小化 EXPOSE、使用 alpine / distroless 基础镜像。
• 进阶：BuildKit 构建缓存、Buildpacks 免 Dockerfile 构建、镜像安全扫描（Trivy / Snyk）。

☸️ 二、容器编排（Kubernetes）

当服务规模超过"一台机器能装下"的临界点，容器编排就是必选项。K8s 已成为事实标准。

• 核心对象：Pod（最小调度单元）、Deployment（无状态部署）、StatefulSet（有状态）、Service（服务发现与负载均衡）、Ingress（HTTP 路由）、ConfigMap / Secret（配置管理）。
• 调度机制：标签选择器、污点（Taint）与容忍（Toleration）、节点亲和性、资源请求与限制（requests/limits）。
• 弹性能力：HPA（水平 Pod 自动扩缩）、VPA（垂直扩缩）、Cluster Autoscaler（节点层扩缩）。
• 服务治理：Service Mesh（Istio / Linkerd）的流量管理（金丝雀、A/B 测试）、熔断、重试、超时。
• 存储：PV / PVC、StorageClass、有状态应用的 StatefulSet 模式。
• 应用打包：Helm Chart 模板化、Operator 模式（自定义控制器）。
• GitOps：ArgoCD / Flux 以 Git 为唯一声明源，自动同步集群状态。

🌐 三、Web Server 与网关（Nginx / OpenResty）

Nginx 是后端架构中最容易被低估的一环。它既是高性能反向代理，也是七层负载均衡、灰度网关、静态资源服务器。

• 核心机制：Reactor 事件模型（epoll）、Master-Worker 多进程架构、连接池与内存池优化。
• 反向代理与负载均衡：upstream 配置、weight / ip_hash / least_conn 策略、健康检查。
• 动静分离：静态资源走 Nginx，动态请求代理至后端、压缩（Gzip / Brotli）、HTTP/2 / HTTP/3。
• 灰度发布：基于 cookie / header / IP 段路由到不同 upstream，实现金丝雀发布。
• 高阶玩法：OpenResty + Lua 实现 WAF、限流、自定义鉴权层；Kong / APISIX 作为 API 网关。
• 安全：WAF 规则、HTTPS 配置、限流（limit_req / limit_conn）、防 CC 攻击。

🔄 四、CI/CD 自动化

CI/CD 是把"代码改动"变成"线上变更"的可控通道。没有 CI/CD 的团队，发版就是赌博。

• CI（持续集成）：代码提交触发自动化流水线——Lint → 单元测试 → 集成测试 → 镜像构建 → 制品归档。
• CD（持续交付 / 部署）：制品从测试环境 → 预发 → 生产，配套审批、灰度、回滚。
• 主流工具：GitHub Actions（生态最广）、GitLab CI（一体化）、Jenkins（插件最丰富、可定制最强）、Drone（容器化）。
• 流水线设计原则：幂等性、可观测（每一步耗时）、失败快速终止、敏感信息走 Secret 而非明文。
• 制品管理：Harbor 私有镜像仓库、npm 私有源、版本语义化（SemVer）。

🚦 五、发布策略（蓝绿 / 灰度 / 滚动）

好的发布策略，应该让用户无感地完成版本切换。

• 蓝绿发布（Blue-Green）：新版本完全部署后切流量，回滚秒级。缺点：资源占用翻倍。
• 滚动发布（Rolling Update）：逐批替换旧实例，K8s 默认策略。缺点：新旧版本共存，回滚慢。
• 金丝雀发布（Canary）：先放 1%-5% 流量到新版本，验证无异常后逐步扩大。业界最常用。
• A/B 测试：基于用户分群对比新旧版本业务指标，常用于功能验证。
• 发布回滚：版本快照、helm rollback、数据库 migration 的向前/向后兼容。

🔐 六、生产环境安全（补充方向）

• 镜像与依赖安全：Trivy / Snyk 扫描 CVE、镜像签名（Cosign）、SBOM（软件物料清单）。
• 密钥管理：K8s Secrets + External Secrets Operator 集成 Vault / AWS KMS、永远不要把密钥打入镜像。
• 网络安全：NetworkPolicy 限制 Pod 间通信、Service Mesh mTLS、TLS 证书自动续签（cert-manager）。
• 运行时安全：Falco 异常行为检测、容器逃逸防护、最小权限原则。

📊 七、可观测性（生产保障，补充方向）

"If you can't measure it, you can't improve it." —— Peter Drucker

• Metrics：Prometheus 抓取、Grafana 可视化，关键 SLI（请求量、错误率、延迟 P50/P95/P99）。
• Logs：Loki / ELK 集中收集，结构化日志（JSON）、TraceId 串联。
• Traces：Jaeger / Tempo，OpenTelemetry 统一采集规范。
• 告警：Alertmanager 按严重级别分级、避免告警风暴、OnCall 值班轮换。
• Profiling：async-profiler / bpftrace / perf 火焰图定位 CPU / 内存热点。

🐧 八、Linux 与网络基础（补充方向）

• 必备命令：top / htop / iostat / vmstat / netstat / ss / lsof / strace。
• 进程与线程：进程状态、nice / renice 调整优先级、僵尸进程与孤儿进程。
• 内存管理：虚拟内存、Swap、OOM Killer、/proc/meminfo。
• 网络调优：tcpdump / wireshark 抓包、netstat / ss 连接状态、TCP 参数调优（/etc/sysctl.conf）。
• 磁盘 I/O：SSD vs HDD、iostat 监控 await 时间、文件系统选型（ext4 / xfs）。

🎓 部署与运维能力矩阵

不同岗位的能力要求，对应不同深度：

能力域	后端开发	SRE / 运维	架构师
Docker 基础使用	✅	✅	✅
K8s 应用部署	✅	✅	✅
K8s 集群运维	-	✅	✅
Nginx 配置调优	✅	✅	✅
CI/CD 流水线	✅	✅	✅
灰度/蓝绿发布	了解	✅	✅
监控告警	了解	✅	✅
Linux 性能调优	了解	✅	✅
容量规划	-	✅	✅
故障应急响应	配合	✅	✅

🧭 选型决策树

面对"该选什么"的问题，这张决策树供参考：

Q1: 服务规模多大？
  ├─ 小（单机/几台） → Docker Compose / 单机部署
  └─ 中大（10+ 实例） → K8s

Q2: CI/CD 工具怎么选？
  ├─ 代码在 GitHub 且团队小 → GitHub Actions
  ├─ 一体化需求 + 自建 GitLab → GitLab CI
  └─ 复杂定制 + 已有基础设施 → Jenkins

Q3: 入口网关用什么？
  ├─ 简单反向代理 → Nginx
  ├─ 需要 WAF / 灰度 / 限流 → OpenResty / APISIX
  └─ 微服务流量治理 → Istio Ingress Gateway

Q4: 发布策略怎么定？
  ├─ 内部系统 / 低风险 → 滚动发布
  ├─ 核心交易链路 → 蓝绿 + 金丝雀
  └─ 业务功能验证 → A/B 测试

📚 参考资源

• Docker 官方文档
• Kubernetes 官方文档
• Nginx 官方文档
• Helm Charts
• GitHub Actions 文档
• Istio Service Mesh
• ArgoCD 文档
• Prometheus 官方文档
• Brendan Gregg - 性能调优大师博客
• 凤凰架构 - 周志明
• SRE Google 运维解密
• Kubernetes The Hard Way