← 返回 构建与部署图解 目录

🔄 CI/CD与部署图解

CI/CD全链路 + 3种部署策略 + GitHub Actions + Nginx · SVG可视化

① CI/CD全链路 ② 3种部署策略 ③ GitHub Actions实战 ④ Nginx反向代理 ⑤ 面试速答

① CI/CD全链路

CI/CD = 自动化工厂：CI（持续集成）就像自动质检流水线——你把代码push上去，机器人自动帮你编译、跑测试、检查代码质量，有问题立即报警，不让次品混入库房。CD（持续部署）就像自动发货系统——质检通过后，机器人自动把产物打包成镜像，推到服务器上，替换旧版本。你只管写代码，剩下的全自动！
👨‍💻 git push 代码推送 🔍 CI 持续集成 ① 拉取代码 git clone → checkout分支 ② 编译构建 mvn clean package / npm run build ③ 自动测试 单元测试 + 集成测试 + 代码覆盖率 ④ 代码质量检查 SonarQube / ESLint / Checkstyle ❌ 任何一步失败 → 终止！ 通知开发者修复（Slack/钉钉/邮件） 🚀 CD 持续部署 ⑤ 构建Docker镜像 docker build → myapp:commit-hash ⑥ 推送镜像到仓库 docker push → Docker Hub / 私服Harbor ⑦ 部署到服务器 docker pull + docker run / k8s apply ⑧ 健康检查 curl /health → 200 OK ✅ 部署成功！ 通知团队（Slack/钉钉/邮件）
图1：CI/CD全链路 — 从git push到自动部署的8步流水线
CI和CD的区别：CI（Continuous Integration）关注的是"代码合进来之后自动检查有没有问题"，核心是编译+测试。CD（Continuous Delivery/Deployment）关注的是"检查通过后自动发出去"，Continuous Delivery = 自动准备到可发布状态（需要人点按钮确认），Continuous Deployment = 全自动无人值守直接上线。

② 3种部署策略

🎭 蓝绿部署 Blue-Green Deployment 🔵 蓝环境 V1 正在服务 接收所有流量 🟢 绿环境 V2 新版本 待命/测试中 👥 用户 ⬇ 一键切换 用户从蓝→绿（瞬间切换） ✅ 零停机 ✅ 瞬间回滚 ⚠️ 需要双倍服务器 🐦 金丝雀部署 Canary Deployment V1 95%流量 稳定版 V2 5%流量 新版灰度 👥 📊 监控指标正常？ 5% → 20% → 50% → 100% ✅ 渐进式 ✅ 出问题影响小 ⚠️ 部署慢 ⚠️ 需要流量控制 🚂 滚动部署 Rolling Deployment V2 V1 V1 V1 ⬇ 逐个替换 V2 V2 V1 V1 ⬇ 继续... V2 V2 V2 V2 ✅ 不停机 ✅ 节省资源 ⚠️ 短暂V1/V2共存 ⚠️ 回滚慢 📋 三种部署策略对比 维度 🎭 蓝绿部署 🐦 金丝雀部署 🚂 滚动部署 停机时间 零停机 零停机 接近零停机 回滚速度 ⚡ 瞬间（切回蓝） 快（减少流量） 慢（逐个回滚） 资源消耗 双倍（蓝+绿） 略多（V1+部分V2） 最少（逐个替换） 风险控制 全有全无 ⭐ 最好（小流量验证） 中等 部署速度 ⚡ 最快（切一次） 慢（逐步扩大） 中等 适用场景 需要秒级回滚 核心业务/大版本 资源有限/K8s默认
图2：3种部署策略 — 蓝绿=两套环境切换，金丝雀=小流量验证，滚动=逐个替换

③ GitHub Actions实战

GitHub Actions = 机器人助手：你在GitHub上push代码，就像在工厂里按了启动按钮。机器人（Runner）就会按照你写的"操作手册"（workflow YAML文件），一步步自动干活：拉代码→编译→测试→打包→部署。你不用自己SSH到服务器上操作，机器人全自动完成。
📌 触发事件 push / PR / tag Job 1: Build Step 1: Checkout Step 2: Setup JDK Step 3: mvn package Step 4: Upload artifact runs-on: ubuntu-latest Job 2: Test Step 1: Checkout Step 2: Setup JDK Step 3: mvn test Step 4: 覆盖率报告 needs: build Job 3: Deploy Step 1: Docker build Step 2: Docker push Step 3: SSH到服务器 Step 4: docker pull+run Step 5: 健康检查 needs: test if: github.ref == 'refs/heads/main' ✅ 上线!
图3：GitHub Actions — 3个Job串联：Build→Test→Deploy
.github/workflows/deploy.yml
📁 .github
📁 workflows
deploy.yml
📁 src
Dockerfile
name: CI/CD Pipeline on: push: branches: [ main ] # main分支push时触发 jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # 拉取代码 - uses: actions/setup-java@v4 # 安装JDK with: { java-version: '17', distribution: 'temurin' } - run: mvn clean package -DskipTests # 打包 - uses: actions/upload-artifact@v4 # 上传产物 with: { name: app-jar, path: target/*.jar } deploy: needs: build # 等build成功 runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: docker build -t myapp:${{ github.sha }} . # 构建镜像 - run: docker push myrepo/myapp:${{ github.sha }} # 推送镜像 - run: | # SSH部署 ssh user@server "docker pull myrepo/myapp:${{ github.sha }} && docker stop myapp || true && docker run -d --name myapp -p 8080:8080 myrepo/myapp:${{ github.sha }}"

④ Nginx反向代理

Nginx反向代理 = 酒店前台：客人（浏览器）只看到前台（Nginx，80/443端口），不知道后面有哪些房间（应用服务器，8080/3000等）。前台根据客人要什么服务，把他引导到不同的房间——要Java API去8080房间，要Vue页面去3000房间，要图片去CDN。客人觉得酒店只有一个入口，但后台有多个服务在忙碌。正向代理则相反——你是酒店住客，通过前台帮你打电话叫外卖（你→代理→外部世界）。
🌐 浏览器 :80 / :443 请求 🛡 Nginx 反向代理 + 负载均衡 /api/* → 后端集群 / → 前端静态文件 SSL终止 / Gzip压缩 限流 / 缓存 / 日志 Spring Boot :8080 API服务 多实例负载均衡 Vue 静态文件 /usr/share/nginx/html Nginx直接serve 不用Node.js进程！ MySQL :3306 数据库 Redis :6379 缓存
图4：Nginx反向代理 — 前台分配请求到不同后端服务
nginx.conf — 反向代理配置
📁 /etc/nginx
nginx.conf
📁 sites-enabled
default.conf
server { listen 80; server_name example.com; # 前端静态文件 — Nginx直接服务 location / { root /usr/share/nginx/html; # Vue打包产物 try_files $uri $uri/ /index.html; # SPA路由回退 } # 后端API — 反向代理到Spring Boot location /api/ { proxy_pass http://localhost:8080; # 转发到后端 proxy_set_header Host $host; # 保留原始Host proxy_set_header X-Real-IP $remote_addr; } # 负载均衡配置 upstream backend { server 127.0.0.1:8080; # 实例1 server 127.0.0.1:8081; # 实例2 # Nginx自动轮询分配请求 } }

⑤ 面试速答

CI和CD分别是什么？有什么区别？

CI（Continuous Integration）持续集成：开发者频繁地将代码合并到主干，每次合并自动触发编译+测试，尽早发现集成问题。

CD有两个含义：

• Continuous Delivery（持续交付）：CI通过后自动准备可发布产物，但部署需要人工确认。

• Continuous Deployment（持续部署）：CI通过后全自动部署到生产环境，无需人工干预。

类比：CI = 自动质检（有问题立即发现），CD = 自动发货（质检通过后自动送出去）。Delivery = 质检通过后货物放到待发货区（等人确认），Deployment = 质检通过后直接发快递。

蓝绿部署和金丝雀部署有什么区别？

蓝绿部署：准备两套完全一样的环境（蓝=V1在线，绿=V2待命），验证通过后一次性切换所有流量到绿环境。

金丝雀部署：先让一小部分流量（5%）访问新版本，监控没问题后逐步扩大（20%→50%→100%）。

关键区别：蓝绿是"全有全无"的切换，金丝雀是"渐进式"扩大。蓝绿回滚最快（切回去就行），金丝雀风险更小（问题只影响5%用户）。

正向代理和反向代理的区别？

正向代理：代理的是客户端。你通过VPN/翻墙访问Google——Google不知道你是谁，只看到代理服务器。

反向代理：代理的是服务端。你访问example.com——你不知道后面有几台服务器，Nginx帮你分发请求。

记忆口诀：正向=你找代理帮你出去（代理客户端），反向=代理帮你接待客人（代理服务端）。

GitHub Actions的workflow基本结构是什么？

4个核心概念：

① Workflow：一个完整的自动化流程，定义在.github/workflows/*.yml中

② Event（on）：触发条件，如push、PR、定时任务

③ Job：一个工作单元，包含多个Step，可并行或串行

④ Step：最小执行单元，一个命令或一个Action

name: My Workflow # Workflow名称 on: [push] # 触发条件 jobs: # 工作单元 build: # Job名 runs-on: ubuntu-latest # 运行环境 steps: # 执行步骤 - uses: actions/checkout@v4 # 使用Action - run: mvn package # 执行命令
Nginx为什么能做负载均衡？有哪些策略？

Nginx作为反向代理，接收客户端请求后可以将请求分发到多台后端服务器，这就是负载均衡。

常见策略：

• 轮询（默认）：请求依次分给每台服务器，像排队叫号

• 权重（weight）：配置高的服务器分更多请求

• IP Hash：同一IP的请求总发到同一台服务器（会话保持）

• 最少连接（least_conn）：发给当前连接数最少的服务器

upstream backend { server 192.168.1.10:8080 weight=3; # 权重3 server 192.168.1.11:8080 weight=1; # 权重1 # 75%请求去.10，25%去.11 }
什么是DevOps？和CI/CD什么关系？

DevOps是一种文化/方法论，核心是开发（Dev）和运维（Ops）协作，通过自动化工具缩短交付周期。

CI/CD是DevOps实践中的核心技术手段——DevOps说"开发和运维要密切合作"，CI/CD就是具体怎么合作：代码改了→自动测试→自动部署。

关系：DevOps = 目标/文化，CI/CD = 工具/实践。就像"健康生活"（DevOps）和"每天运动+合理饮食"（CI/CD）的关系。

📌 速记口诀

CI/CD全链路：push→拉代码→编译→测试→检查→构建镜像→推送→部署→健康检查
CI vs CD：CI=自动质检 / CD=自动发货（Delivery人工确认 / Deployment全自动）
蓝绿部署：两套环境一键切换→回滚最快→双倍资源
金丝雀部署：5%→20%→50%→100%→风险最小→部署慢
滚动部署：逐个替换→不停机→资源省→V1/V2短暂共存
Nginx反向代理：酒店前台→分发请求→负载均衡→SSL终止→静态文件直出
正向代理 vs 反向代理：正向代理客户端(翻墙) / 反向代理服务端(Nginx)