全栈攻城狮

Appearance

实战篇：运维体系完整搭建 ​

概述 ​

把前六篇运维能力拼成一套完整体系：Docker 容器化（部署单元）→ CI/CD 流水线（自动发布）→ Prometheus + Grafana（指标监控）→ ELK（日志平台）→ SkyWalking（链路追踪）。以一次"从提交代码到线上稳定运行"的完整旅程演示五者如何配合。

一、运维体系总览 ​

1.1 六层闭环 ​

运维体系六层：
  容器化：镜像构建 + Compose/K8s 部署（部署单元）
  流水线：提交 → 构建 → 测试 → 部署（发布流程）
  指标监控：Prometheus + Grafana（系统是否健康）
  日志平台：ELK + Kibana（出问题查什么）
  链路追踪：SkyWalking（问题出在哪一跳）
  发布策略：灰度 + 热更新 + 优雅关闭（安全变更）

协作流程：
  发布（流水线 + 容器 + 灰度）
  → 运行（指标监控兜底）
  → 出事（监控告警 → 链路定位 → 日志查证）
// 全栈技术栈
构建：Maven + Docker 多阶段镜像
编排：Docker Compose（测试）/ K8s（生产）
CI/CD：GitLab CI / GitHub Actions
指标：Prometheus + Grafana + Alertmanager
日志：Filebeat + Kafka + Logstash + ES + Kibana
链路：OpenTelemetry + SkyWalking

1.2 目录与配置 ​

// 项目运维目录
game-server/
├── docker/                    # 镜像与编排
│   ├── Dockerfile
│   ├── docker-compose.yml     # 测试环境全栈
│   └── k8s/                   # 生产部署（见容器化章节）
├── .gitlab-ci.yml             # 流水线
├── deploy/                    # 部署脚本（冒烟/回滚）
└── monitor/                   # 监控配置
    ├── prometheus.yml
    ├── alert-rules.yml
    └── grafana-dashboard.json

二、搭建流程 ​

2.1 容器化 + 流水线 ​

第一步：容器化
  多阶段构建（JDK 构建 → JRE 运行）
  网关/逻辑/匹配等模块分别出镜像
  Compose 编排本地/测试（Redis/MySQL/MQ 一并起）

第二步：流水线
  push → build + test（门禁）
  合并 main → 部署测试环境
  打 Tag → 构建生产镜像 → 预发布
  审批 → 生产灰度发布
// 流水线核心（见 CI/CD 章节）
build → test → quality → package(docker)
→ deploy:test（main 合并触发）
→ deploy:staging（Tag 触发）
→ 生产（审批 + 灰度）

2.2 监控 + 日志 + 链路 ​

第三步：Prometheus + Grafana
  服务暴露 /metrics（Micrometer）
  Prometheus 抓取 + 告警规则
  Grafana 面板（在线/QPS/RT/GC/连接）
  Alertmanager → 钉钉告警

第四步：ELK 日志
  应用输出 JSON 日志
  Filebeat → Kafka → Logstash → ES → Kibana
  看板：错误分布 / 慢接口 / 业务检索

第五步：SkyWalking 链路
  Java Agent 接入（零侵入）
  服务拓扑 + Trace 查询
  慢链路定位（配合监控/日志）
// 启动参数整合
java \
  -javaagent:skywalking-agent.jar \
  -Dskywalking.agent.service_name=game-logic \
  -javaagent:opentelemetry-javaagent.jar \
  -Dotel.service.name=game-logic \
  -Xms2g -Xmx2g \
  -jar game-logic.jar

三、一次发布全流程 ​

3.1 发布旅程 ​

场景：发布版本 1.5.0（新增活动 + 修复充值 bug）

流程：
  1. 开发提交 → 流水线跑 build + test + quality
  2. 门禁通过 → 合并 main → 自动部署测试环境
  3. 测试通过 → 打 Tag v1.5.0 → 构建镜像
  4. 预发布部署 → 冒烟验证（登录/充值/对局）
  5. 审批 → 生产灰度 10% → 观察指标
  6. 指标正常 → 放量 100% → 发布完成

发布期间观察：
  在线数/登录成功率（不降）
  充值成功率（不降）
  错误率（不升）
  新功能使用（活动参与正常）

3.2 发布中的安全保护 ​

发布保护：
  灰度期间新旧版本并存（字段兼容）
  数据库先加字段后启用（兼容读写）
  配置热更新先行（功能开关控制）
  异常任一指标 → 立即回滚（监控告警触发）
// 发布检查表
[ ] 协议兼容（字段只增不改）
[ ] DB 变更兼容（加字段先于代码）
[ ] 配置灰度开关就绪
[ ] 监控面板新旧指标分列
[ ] 回滚镜像可用（上一版本保留）
[ ] 告警规则覆盖新功能

四、一次线上事故排查 ​

4.1 事故复盘 ​

场景：凌晨 2 点"充值失败率突增"告警

排查流程：
  1. 告警（Prometheus）：充值失败率 > 5%
  2. 链路（SkyWalking）：找失败 TraceId 样本
  3. 日志（ELK）：按 TraceId 查全链路日志
  4. 定位：支付回调服务连接池耗尽
  5. 处理：扩容回调服务 + 连接池参数调整
  6. 验证：指标恢复 → 通知恢复
  7. 复盘：连接池配置不合理 → 纳入压测场景
// 三平台联动
监控：失败率曲线（何时开始、是否扩散）
链路：失败集中在哪一跳（回调服务）
日志：具体异常（连接超时/池耗尽）

4.2 沉淀 SOP ​

运维 SOP 沉淀：
  常见问题处理手册（充值/对局/登录）
  排查模板（固定检索语句）
  告警处理流程（认领 → 处理 → 复盘）
  发布检查表（固定 checklist）

五、实现要点 ​

运维体系核心：
  六层闭环（容器/流水线/监控/日志/链路/发布策略）
  一次发布全流程（提交 → 测试 → 灰度 → 全量）
  一次事故排查（告警 → 链路 → 日志 → 修复 → 复盘）
  SOP 沉淀（处理手册 + 检查表）

常见坑：
  只搭平台不落地流程 → 形同虚设
  监控告警无人处理 → 失去意义
  发布无灰度无回滚 → 事故扩大
  排查靠经验不靠平台 → 效率低

与其他系统衔接：
  安全体系 → 日志审计/风控（上阶段）
  性能压测 → 阈值设定与容量评估
  配置中心 → 热更新与灰度开关
  运营后台 → 公告与活动配置