CI/CD 基础：流水线阶段与灰度发布流程
微服务的价值要落到“快速、安全地发布”。CI/CD（持续集成/持续交付）把从代码提交到上线的过程自动化，让发布从“每周手动操作”变成“每次提交都可验证、可发布”。本章讲流水线怎么搭，以及灰度发布如何在流水线里闭环。
CI 与 CD 的区别
- CI（持续集成）：代码合并后自动构建、测试，尽早发现集成问题。原则是“小步提交、频繁集成、快速反馈”。
- CD（持续交付/部署）：把通过验证的制品自动部署到环境。持续交付到预发为止、生产人工确认；持续部署连生产也自动发布（多数团队折中为“自动到预发、一键上生产”）。
流水线的典型阶段
一条服务流水线通常包含以下阶段（可按团队情况裁剪）：
# 以 GitLab CI 语法为例的流水线骨架（其他 CI 平台概念相同）
stages:
- build # 编译：mvn -B clean package
- test # 单元/集成测试：mvn verify，生成覆盖率报告
- image # 构建镜像并推送制品仓库
- deploy-dev # 部署到开发环境，跑冒烟测试
- deploy-test # 部署到测试环境，验收测试
- deploy-gray # 灰度发布：生产小流量
- deploy-prod # 全量发布生产
每个阶段要点：
- 静态检查与单元测试：Checkstyle/SpotBugs、JUnit + 覆盖率门禁，失败即阻断。
- 制品管理：每次构建产出唯一版本（如
1.0.0-${commit}），镜像与 jar 都打版本标签，可追溯。 - 环境部署：配置外置（Nacos/K8s ConfigMap），同一镜像在不同环境只换配置。
- 自动化验证：部署后跑冒烟/契约测试，而非“能启动就算成功”。
- 质量门禁：测试覆盖率、安全扫描（依赖漏洞）、镜像扫描不达标不放行。
灰度发布流程
生产发布高风险，普遍做法是灰度三段式：先小流量验证 → 逐步放量 → 全量收尾。
全量灰度发布流程：
1. 流水线构建新版本镜像，部署 1~2 个金丝雀实例（带 version=canary 标识）
2. 网关/负载均衡把 5%~10% 流量切到新版本（见灰度发布章节）
3. 观察核心指标：错误率、RT、业务成功率，与基线版本对比
4. 指标正常 → 权重加到 50% 再观察；异常 → 一键切回旧版本
5. 全量后保留旧实例短时间，确认稳定再下线旧版本
灰度成功的关键不在“切流量”，而在“可观测 + 可回滚”：
- 流量按版本打标，日志/指标能按版本聚合对比（见日志聚合章节）；
- 发布与回滚都是配置变更（改权重/改镜像 tag），操作路径要提前演练；
- 设置发布窗口与告警：异常指标触发自动暂停放量甚至自动回滚。
多服务发布顺序
微服务发布顺序也有讲究：改动不兼容（接口字段变更）时，先发服务提供方并保证兼容旧调用方，再发消费方；依赖升级（注册中心/配置变更）先发基础设施。必要时用“接口兼容期 + 双版本并存”平滑过渡，避免上下游同时发布的“原子发布”幻觉。
最小可用起步
不要一上来追求全自动生产发布。建议起步顺序：
- 先自动化“构建 + 单元测试 + 镜像”，保证每次提交的制品可靠；
- 再加“自动部署测试环境 + 冒烟”；
- 最后加“生产灰度”与质量门禁。
每一步都先手工能跑、再自动化，CI/CD 平台本身（Jenkins/GitLab CI/GitHub Actions 等）只是载体，阶段划分与质量门禁才是灵魂。
小结
CI/CD 的本质是“把发布流程沉淀为可重复、可验证、可回滚的流水线”。标准阶段是 构建→测试→镜像→各环境部署→灰度→全量；灰度发布要闭环“小流量验证、指标对比、一键回滚”，这才是微服务发布安全感的来源。