4、版本控制策略：语义化版本、蓝绿部署、金丝雀发布、灰度发布
版本控制，说白了就是给你的软件打标签。没有标签的版本，就像没有名字的孩子，出了问题你都不知道该找谁。我见过太多团队，上线前还在问「这个包是哪个版本？」——这种混乱，往往就是事故的温床。
今天咱们聊四种策略：语义化版本、蓝绿部署、金丝雀发布、灰度发布。它们解决的是不同层面的问题，但目标一致——让升级变得可控、可回滚。
4.1 语义化版本：给你的版本号定规矩
语义化版本（SemVer）不是技术，是约定。它规定了版本号的格式：主版本号.次版本号.修订号。比如 2.1.3。
- 主版本号：不兼容的API变更。说白了就是「改了大接口，旧代码跑不了」。
- 次版本号：向下兼容的功能新增。加了新功能，但旧功能照常工作。
- 修订号：向下兼容的问题修复。修了个bug，不影响任何人。
我个人习惯在项目根目录放一个 VERSION 文件，内容就一行：2.1.3。CI/CD 流水线自动读取它，打标签、发通知。省心。
核心原则：版本号一旦发布，就不能再修改。如果发现打错了，就发布一个新版本。
举个例子。你有个库叫 my-lib，当前版本 1.0.0。你加了个新函数 doSomething()，但没改旧接口——那就发布 1.1.0。如果你把 doSomething() 的参数改了，导致旧调用方报错——那就得发 2.0.0。
我在项目中遇到过一件事：有个同事把修复bug的版本号从 1.2.3 改成了 1.3.0。结果下游依赖方以为有新功能，自动升级后出了问题。嗯，这就是不守规矩的代价。
小技巧：在 package.json 或 pom.xml 里用 ^ 或 ~ 控制依赖范围。比如 ^1.2.0 表示允许安装 1.x.x 的最新版本，但不允许 2.0.0。
4.2 蓝绿部署：两套环境，一键切换
蓝绿部署的思路很简单：准备两套完全一样的环境——蓝环境和绿环境。任何时候只有一套在提供服务，另一套闲置。
升级流程是这样的：
- 当前绿环境在运行 v1.0。
- 你把 v2.0 部署到蓝环境。
- 测试蓝环境上的 v2.0。
- 一切正常？好，把流量切到蓝环境。
- 绿环境变成闲置，随时准备回滚。
回滚？简单。再把流量切回绿环境就行。整个过程对用户无感。
注意：蓝绿部署需要两倍的资源。如果你的服务有100台机器，蓝绿部署就需要200台。成本翻倍，但换来的是秒级回滚能力。
我曾经在一个金融项目里用过蓝绿部署。当时上线一个核心交易系统，老板说「出问题必须在30秒内恢复」。蓝绿部署帮了大忙——有一次新版本有内存泄漏，我们10秒就切回了旧环境。老板后来请我们吃了顿饭。
但蓝绿部署也有坑。比如数据库的兼容性问题。新版本改了表结构，切回旧版本时，旧代码可能不认识新字段。所以，数据库变更要谨慎，最好做到向前兼容。
4.3 金丝雀发布：先放一只鸟试试
金丝雀发布的名字来源于矿工用金丝雀检测毒气的历史。在软件领域，就是先让一小部分用户用新版本，观察没问题再全量发布。
具体做法：
- 从集群中挑出少量机器（比如5%），部署新版本。
- 让这部分机器接收真实流量。
- 监控错误率、延迟、CPU等指标。
- 如果一切正常，逐步扩大范围，直到100%。
- 如果有问题，立刻回滚那5%的机器。
金丝雀发布和蓝绿部署不冲突。你可以先做金丝雀，确认没问题后再做蓝绿切换。我习惯把金丝雀当作「最后的防线」——毕竟自动化测试再全面，也覆盖不了所有真实场景。
关键指标：金丝雀期间要重点监控 p99 延迟、错误率、业务成功率。别只看平均延迟，那玩意儿会骗人。
举个例子。你有个电商网站，新版本改了推荐算法。你让5%的用户走新算法，95%走旧算法。如果新算法的点击率明显下降，或者报错增多，你就知道有问题了。
我记得有一次，金丝雀发布救了我们一命。新版本有个死锁bug，只在高并发下触发。测试环境根本复现不了。金丝雀跑了10分钟，错误率飙升，我们立刻回滚。如果全量发布，那天的损失至少六位数。
4.4 灰度发布：按用户群体逐步放量
灰度发布和金丝雀有点像，但思路不同。金丝雀是按机器比例放量，灰度发布是按用户群体放量。比如：
- 先让内部员工用新版本。
- 再让VIP用户用。
- 然后让普通用户用。
- 最后全量开放。
灰度发布的核心是「用户分群」。你可以根据用户ID、地域、设备类型、会员等级等维度来划分。每个群体可以设置不同的流量比例。
| 阶段 | 用户群体 | 流量比例 | 目的 |
|---|---|---|---|
| 1 | 内部员工 | 1% | 发现明显bug |
| 2 | VIP用户 | 5% | 验证核心功能 |
| 3 | 普通用户 | 20% | 压力测试 |
| 4 | 全量 | 100% | 正式上线 |
灰度发布的好处是「精准控制」。你可以针对特定用户群体做A/B测试，收集反馈。坏处是逻辑复杂——需要一套用户分群和流量路由系统。
建议：灰度发布最好配合功能开关（Feature Flag）使用。这样即使灰度出问题，你也可以远程关闭新功能，而不需要重新部署。
我曾经在一个社交App项目里做灰度发布。新版本改了朋友圈的排序算法。我们先让1%的活跃用户试用，发现新算法虽然推荐更精准，但加载速度慢了200ms。我们优化了两天，才敢放量到10%。
你想想看，如果直接全量发布，200ms的延迟可能让用户流失多少？灰度发布给了你「试错」的空间。
4.5 四种策略怎么选？
没有银弹。每种策略都有适用场景：
- 语义化版本：所有项目都该用。这是基础。
- 蓝绿部署：适合对回滚速度要求极高的场景。比如支付、交易系统。
- 金丝雀发布：适合新功能风险较高、需要真实流量验证的场景。
- 灰度发布：适合需要按用户群体精细化控制的场景。比如UI改版、算法调整。
我个人习惯的组合是：语义化版本打底 + 蓝绿部署做快速回滚 + 金丝雀发布做风险验证。灰度发布看需求，不是必须。
避坑指南：我曾经见过一个团队，同时用了蓝绿部署和金丝雀发布，但没做好协调。结果金丝雀的机器在蓝环境里，蓝绿切换时把金丝雀也切走了，导致部分用户反复跳版本。嗯，教训就是——策略之间要设计好交互逻辑。
最后说一句：版本控制策略不是写文档，是写代码。把策略落地到CI/CD流水线里，让机器自动执行。人只负责决策，不负责操作。这样才靠谱。