服务发布

我也不知道叫啥了，随便起个名字吧。。。

这里普及一下真正的工作中发布的一些类型。

🆚 三者核心区别总结

维度	滚动更新	蓝绿部署	金丝雀发布
资源占用	1x（最少）	2x（最多）	~1.2x（按比例）
发布速度	慢（逐个替换）	极快（瞬间切换）	渐进（几分钟到几小时）
回滚速度	慢（再滚一遍）	极快（切回）	极快（关掉金丝雀流量）
风险范围	高（逐步扩散）	低（全有或全无）	极低（仅小部分用户）
是否需要额外工具	否（K8s 原生）	是（需 LB 切换）	是（需流量控制）
适合场景	内部工具、低风险变更	关键业务、大版本升级	高频发布、A/B 测试

🧩 假设前提（统一上下文）

你有一个 Go Web 服务 user-api，当前运行 v1.0 版本
生产环境有 5 台服务器（或 5 个 Pod），都运行 v1.0
现在要上线 v1.1 版本
用户通过负载均衡器（如 Nginx、云厂商 SLB、K8s Service）访问服务

💡 为了简化，我们以 Kubernetes Pod 为例（但逻辑同样适用于物理机/虚拟机集群）。

滚动更新 —— “边换边跑”

像修路，一边拆旧砖一边铺新砖，路上一直能走人，但如果新砖质量差，整条路慢慢都坏了。

这是 Kubernetes 的 默认发布策略。

🔧 过程：

K8s 开始逐步替换旧 Pod：
- 先启动 1 个 v1.1 Pod
- 等它就绪后，销毁 1 个 v1.0 Pod
- 再启动第 2 个 v1.1，销毁第 2 个 v1.0……
整个过程保持 至少 4 个 Pod 在线（可配置）
最终 5 个 Pod 全部变成 v1.1

时间线：
[ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ]  ← 初始
[ v1.1 ][ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ]  ← 启动1个新，未删旧（共6个）
[ v1.1 ][ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ]  ← 删除1个旧（回到5个）
[ v1.1 ][ v1.1 ][ v1.0 ][ v1.0 ][ v1.0 ]  ← 继续...
...
[ v1.1 ][ v1.1 ][ v1.1 ][ v1.1 ][ v1.1 ]  ← 完成

✅ 优点：

资源利用率高（不需要双倍机器）
服务不中断

❌ 缺点：

一旦 v1.1 有 bug，会逐步扩散到所有用户
回滚慢（要再滚一遍回 v1.0）

⚠️ 如果 v1.1 有内存泄漏，可能在替换到第 3 个时系统就崩了。

注意！！！这里的重点在于，我们无法精准控制pod的发布，只能等它一个一个的发布完成

蓝绿部署 —— “建好再切”

像建新桥。先在旁边建一座新桥，验收合格后，交警一声令下，所有车改走新桥，旧桥封闭。

🔧 过程：

先完整部署一套 v1.1 环境（另外 5 台机器 / 5 个 Pod），和 v1.0 完全隔离
- 此时：v1.0（5台） + v1.1（5台） = 总共 10 台机器
测试 v1.1 环境没问题后，瞬间切换流量：
- 负载均衡器从指向 “蓝组（v1.0）” → 改为指向 “绿组（v1.1）”
确认稳定后，下线 v1.0 的 5 台机器

阶段1（发布前）：
LB → [ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ]

阶段2（部署新版本）：
LB → [ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ]   ← 用户还在用
      [ v1.1 ][ v1.1 ][ v1.1 ][ v1.1 ][ v1.1 ]   ← 新版本待命（无流量）

阶段3（切换瞬间）：
LB → [ v1.1 ][ v1.1 ][ v1.1 ][ v1.1 ][ v1.1 ]   ← 所有用户立刻用新版本
      [ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ]   ← 准备下线

✅ 优点：

切换极快（秒级）
回滚极快（改回 LB 指向即可）
用户体验一致（不会有人用 v1.0、有人用 v1.1）

❌ 缺点：

需要双倍资源（成本高）
数据库变更必须向后兼容（因为切换前后 v1.0/v1.1 都可能读写 DB）

金丝雀发布（互联网公司主流）

像新药试验。先给 5% 的病人试用，观察副作用，没问题再推广给所有人。

🔧 过程：

只部署 1 个 v1.1 Pod（其他 4 个仍是 v1.0）
配置负载均衡器：95% 流量 → v1.0，5% 流量 → v1.1
观察 v1.1 的监控指标（错误率、延迟、CPU）
- 如果正常 → 逐步增加比例（比如 20% → 50% → 100%）
- 如果异常 → 立即把 5% 流量切回 v1.0，v1.1 下线

初始：
LB → [ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ]

金丝雀阶段（5% 流量）：
LB → 95% → [ v1.0 ][ v1.0 ][ v1.0 ][ v1.0 ]
     5%  → [ v1.1 ]   ← 只有1个新实例

观察 OK 后（比如升到 50%）：
LB → 50% → [ v1.0 ][ v1.0 ]
     50% → [ v1.1 ][ v1.1 ][ v1.1 ]   ← 扩容 v1.1 到3个

最终全量：
LB → [ v1.1 ][ v1.1 ][ v1.1 ][ v1.1 ][ v1.1 ]

📌 注意：金丝雀的 Pod 数量不固定，关键是流量比例。

✅ 优点：

风险最小：最多只有 5% 用户受影响
真实环境验证：不是测试环境，是生产流量！
支持自动化决策（如“错误率 < 0.1% 才继续”）

❌ 缺点：

配置复杂（需要智能 LB 或 Service Mesh）
用户体验可能不一致（同一用户刷新可能看到不同版本）
需要完善的监控体系

当你学到 Argo Rollouts 或 Istio 时，就能轻松实现自动化金丝雀发布！

Pod 是什么？和 Docker 容器是什么关系？

✅ 简单说：

Pod 是 Kubernetes 的最小调度单位，它“包含”一个或多个紧密耦合的容器（通常是 1 个）。

📦 具体解释：

一个 Pod ≈ 一个“逻辑主机”，里面可以跑多个容器（比如主应用 + 日志收集 sidecar）
但在 90%+ 的 Web 场景中，一个 Pod 只包含 1 个应用容器（比如你的 Go 程序）
所以你可以暂时理解为：1 个 Pod ≈ 1 个 Docker 容器（但技术上 Pod 是容器的“包装壳”）

💡 类比：
Docker 容器 = 一个工人
Pod = 一个“工位”，通常只坐一个工人，但也可以坐两个（比如工人 + 助手）

Kubernetes 不直接管理容器，而是管理 Pod。当你写 Deployment，其实是告诉 K8s：“我要 5 个这样的 Pod”。

滚动更新 vs 金丝雀发布的根本区别（重点！）

“两者都是一样的机器数量，都是让其中一个机器更新成 v1.1，每个用户都有机会访问到 v1.1”

这个理解在“结果上看”似乎一样，但背后的机制、目的和控制能力完全不同！

我们用同一个例子深挖：

🧪 场景重设

当前：5 个 Pod 运行 v1.0
目标：上线 v1.1
负载均衡器（如 K8s Service）会把请求平均分发给所有健康 Pod

🔄 滚动更新（Rolling Update）—— “强制替换，无法控制流量”

关键特征：

K8s 自动、连续地替换 Pod，直到全部更新完毕
所有新 Pod 都会被加入 Service 的负载均衡池
你无法控制“多少流量”打到 v1.1

实际过程：

text

Step 1: 启动 1 个 v1.1 Pod → 现在有 6 个 Pod（5 v1.0 + 1 v1.1）
        Service 会把 ~1/6 ≈ 16.7% 的流量打给 v1.1

Step 2: 删除 1 个 v1.0 Pod → 现在 5 个 Pod（4 v1.0 + 1 v1.1）
        流量比例变成 20% → v1.1

Step 3: 启动第 2 个 v1.1 → 6 个 Pod（4 v1.0 + 2 v1.1）→ 33% 流量到 v1.1
Step 4: 删除 1 个 v1.0 → 5 个 Pod（3 v1.0 + 2 v1.1）→ 40% 流量...
...
Step N: 全部变成 v1.1

❗ 问题在哪？

你无法暂停！K8s 会自动继续下一步。
你无法限制 v1.1 的流量比例（比如“只让 5% 用户试用”）。
一旦 v1.1 有问题，错误会随着更新进度扩散（从 16% → 33% → 50%...），直到你手动暂停或回滚。

🚨 滚动更新的本质是“部署策略”，不是“流量控制策略”。

🐤 金丝雀发布（Canary）—— “我主动控制，只放少量流量”

关键特征：

你明确部署 1 个（或少量）v1.1 Pod
但通过流量规则，强制只有 5% 的请求能到达它
其余 95% 的请求仍然只打给 v1.0 Pod（即使 v1.1 已经就绪！）

✅ 你能做什么？

暂停在 5%，观察 1 小时、1 天
如果监控发现错误率飙升，立刻删掉金丝雀 Ingress，100% 流量切回 v1.0
如果稳定，手动把 canary-weight 改成 20 → 50 → 100

🎯 金丝雀的核心是“流量比例可控 + 人工/自动决策”

🆚 根本区别总结（一句话）

	滚动更新	金丝雀发布
控制对象	控制 Pod 数量（部署层面）	控制用户流量比例（网络层面）
能否暂停？	❌ 不能（除非手动干预）	✅ 能（停在 5% 观察）
流量比例	由 Pod 数量决定（不可控）	由你设定（精确控制）
目标	完成部署	验证新版本稳定性

服务发布 ​

🆚 三者核心区别总结 ​

🧩 假设前提（统一上下文） ​

滚动更新 —— “边换边跑” ​

🔧 过程： ​

✅ 优点： ​

❌ 缺点： ​

蓝绿部署 —— “建好再切” ​

🔧 过程： ​

✅ 优点： ​

❌ 缺点： ​

金丝雀发布 （互联网公司主流） ​

🔧 过程： ​

✅ 优点： ​

❌ 缺点： ​

Pod 是什么？和 Docker 容器是什么关系？ ​

✅ 简单说： ​

📦 具体解释： ​

滚动更新 vs 金丝雀发布的根本区别（重点！） ​

🧪 场景重设 ​

🔄 滚动更新（Rolling Update）—— “强制替换，无法控制流量” ​

关键特征： ​

实际过程： ​

❗ 问题在哪？ ​

🐤 金丝雀发布（Canary）—— “我主动控制，只放少量流量” ​

关键特征： ​

✅ 你能做什么？ ​

🆚 根本区别总结（一句话） ​

服务发布

🆚 三者核心区别总结

🧩 假设前提（统一上下文）

滚动更新 —— “边换边跑”

🔧 过程：

✅ 优点：

❌ 缺点：

蓝绿部署 —— “建好再切”

🔧 过程：

✅ 优点：

❌ 缺点：

金丝雀发布（互联网公司主流）

🔧 过程：

✅ 优点：

❌ 缺点：

Pod 是什么？和 Docker 容器是什么关系？

✅ 简单说：

📦 具体解释：

滚动更新 vs 金丝雀发布的根本区别（重点！）

🧪 场景重设

🔄 滚动更新（Rolling Update）—— “强制替换，无法控制流量”

关键特征：

实际过程：

❗ 问题在哪？

🐤 金丝雀发布（Canary）—— “我主动控制，只放少量流量”

关键特征：

✅ 你能做什么？

🆚 根本区别总结（一句话）