07 - 微服务怎么跑起来：容器与编排

到这里，我们知道了微服务”怎么拆、怎么通信、数据怎么办、整体长什么样”。还剩最后一个现实问题：这么多服务，到底怎么部署、怎么跑起来？

答案你其实已经学过了——Docker + K8s。这一章把它们和微服务串起来。

微服务和容器是”天生一对”

回想一下微服务的诉求：每个服务要能独立打包、独立部署、各带各的环境。而这，正是 Docker 最擅长的事：

把每个服务连同它的运行环境，打成一个独立的镜像。一个服务一个镜像，互不干扰。

用户服务  → 打成镜像 user-service:v1
商品服务  → 打成镜像 product-service:v1
订单服务  → 打成镜像 order-service:v1
支付服务  → 打成镜像 payment-service:v1

每个镜像自带自己的 Python 版本、依赖、代码，
谁想升级、谁想换技术栈，各改各的，互不影响。

微服务讲”独立”，容器给”独立”提供了完美的封装。这就是为什么一提微服务，几乎必然一起提 Docker。

服务一多，就需要”总指挥”K8s

四个服务、每个还开好几份副本，加上前一章那些配角，几十个容器散在多台机器上。手工管理它们会累死（这正是 K8s 入门第 01 章讲的痛点）。

于是用 K8s 来当”容器总指挥”。妙就妙在：上一章我们操心的好几个问题，K8s 天生就帮你解决了。

微服务需要的能力            K8s 天生提供
──────────────────      ──────────────────
某个服务挂了要自动拉起  →   自愈（挂了自动重启）
订单忙要多开几份副本    →   弹性伸缩（自动扩缩容）
发新版不能中断服务      →   滚动更新 + 一键回滚
多个副本间请求要分流    →   内置负载均衡
服务要能通过名字找彼此  →   内置服务发现（Service）

对照第 06 章那张全景图你会发现：服务注册发现、负载均衡、部署伸缩这些配角能力，K8s 基本都内建了，不用你再单独搭一套。这也是现代微服务几乎都跑在 K8s 上的原因。

两句话理清 Docker、K8s 和微服务的关系

微服务   =  "怎么拆"的思想         （把大应用拆成一组独立小服务）
Docker  =  "怎么装"的工具         （把每个服务打包成独立镜像）
K8s     =  "怎么管一大堆"的平台    （自动部署、伸缩、自愈、调度这些容器）

微服务是思想层，Docker 和 K8s 是把这套思想落地跑起来的支撑。三者是一条完整的链路。

真实生产里大致怎么落地

不用自己搭 K8s（K8s 入门里也提到），生产上一般：

1. 每个服务写好代码，用 Dockerfile 打成镜像，推到镜像仓库
2. 用云厂商的托管 K8s（阿里云 ACK、AWS EKS 等），声明”我要每个服务跑几份”
3. K8s 自动把容器调度到机器上、维持副本数、挂了重启、流量变了自动伸缩
4. 配上网关、监控、日志，一套微服务系统就转起来了

细节是很大的运维话题，这里知道”大致这么落地”即可。

小结

• 微服务讲”独立”，Docker 正好能把每个服务打成独立镜像，天生一对。
• 服务一多就用 K8s 当总指挥，而且 K8s 天生就提供了自愈、伸缩、滚动更新、负载均衡、服务发现——正好补齐微服务需要的运行支撑。
• 一句话关系：微服务是”怎么拆”的思想，Docker 是”怎么装”，K8s 是”怎么管一大堆”。

上一章 ← 06 - 一套微服务系统的全景架构 ｜ 下一章 → 08 - 完整例子：一次”下单”的旅程 ｜ 回到 README 目录