第5章 移植与吊装：部署与运维

第5章 移植与吊装：部署与运维

本章把已经逻辑健康的商城服务，真正推到线上活下去。三站连成一课：怎么把每个服务装进一个可移植的"保鲜盒"（容器），怎么让几十个盒子在集群里排兵布阵（编排），以及怎么把"上线"和"看着它们"接成两条自动流水线（CI/CD 与可观测）。

服务切好、数据理清，还差最后一步把它们养起来。这一步人人都熟，却也是很多团队在微服务上"大翻车"的地方——你以为拆完就完了，其实拆完才是运维噩梦的开始：好几十个服务，谁来构建？谁把谁部署到哪？谁来发现"这个服务挂了"并报警？在这一章，我们把这三件"养"的事讲透。

一条主线

继续跟着商城：我们要把刚刚拆好的订单、支付、库存等十几个服务，一样样装进容器，扔进一个编排集群，让它们被 k8s 自动调度、自动发现、自动伸缩；再套上一条"代码提交→构建→镜像→部署→灰度发布"和一条"指标→日志→追踪"的流水线，让程序员只管写代码，机器管养它们。

沿途站点

5.1 容器化：器官保鲜盒——讲 Docker 怎么把"环境即代码"变成可移植的镜像，为什么隔离微服务最该用它，镜像分层、镜像仓库与镜像地址漂移这些绕不开的细节。

5.2 Kubernetes 编排：叫号排台——讲 k8s 为什么成为事实标准：声明式期望状态、自动调度、自我修复、服务发现与负载均衡的一揽子解决。也讲它"及格线以下不问别问"的复杂度，以及单机 Docker 什么时候不够。

5.3 CI/CD 与可观测性：批量排程加监护——讲两条并行流水线：一条把"提交到上线"自动化（CI/CD + 灰度发布），另一条把"指标/日志/追踪"三件套接到统一观测（可观测性）。微服务没有可观测性，等于蒙眼开车。

拐点与结论

本章认知转折是：微服务部署不是"服务够小就够了"，而是"自动化到位才是微服务"。没有容器、编排和 CI/CD，十几个服务根本没人顾得过来；没有可观测性，你连"哪里挂了"都要靠猜。所以这三个"养"的动作，不是可选项，是拆服之后活下来的最低配置。读完全章，你会明白"为什么说微服务成败在运维"这句话从来不是虚言。

这一章最容易踩的三个坑

部署与运维是"看着简单、一上就塌"的战场，三个最常见的翻车点：

1. 以为容器化 = 编排好了。把服务装进 Docker、用 docker-compose 转起来就以为上了生产，结果集群一挂没人管、扩缩全靠手。容器只是保鲜盒，编排才是把盒子排兵布阵的无影手，两者是两码事。
2. 把发布仍然当"人肉点按钮"。二十个服务还在靠发布工程师挨个敲命令，一次升级要熬夜守到凌晨。没有 CI/CD 和灰度，频繁小步上线就是空话，"快捷发布"这个微服务最大的卖点根本兑现不了。
3. 上了线却没有可观测性。服务一多，"哪里挂了全靠猜"。指标、日志、追踪三件套缺一件，排错就是蒙眼开车。上线不等于上岗，看得见才叫真的看着它。

想清楚这三条，再进站点看容器、编排、流水线具体怎么落地。

读完你应该

• 写出一个 Dockerfile 的核心要点，说清镜像分层和仓库
• 说明 k8s 的期望状态、自动调度、自我修复是怎样工作
• 判断一个团队什么时候该从"单机 Docker"升级到"编排集群"
• 布置一条配套灰度发布的 CI/CD 流水线
• 用"指标+日志+追踪"三件套设计一个可观测性方案

下一章的接力

动脉血管都接好了，可拆完的手术台是台很脆的东西——网络抖动、并发暴涨、单点宕机都会考验它。第 6 章把"抗排异和免疫"装进来：熔断、限流、重试、舱壁，让商城在恶劣环境下依然站得住。先会养，再会抗。