运维体系（Ops / SRE Platform）
目标：让系统“可发布、可回滚、可治理、可恢复”
P0（基础运维）
├── CMDB
├── 容器平台（K8s）
├── 发布平台
├── 配置中心
P1（稳定运行）
├── 服务治理（Service Mesh / Dubbo / SpringCloud）
├── 运维工具集
P2（事件驱动）
├── 事件中心（告警 / 事件 / 变更）
├── 灰度平台（Feature Flag）
├── 变更管理平台
P3（可靠性工程）
├── 自动化运维 / 自愈
├── 容量 & 成本管理
├── 运维审计 / 合规
服务治理
下面我将以“治理能力本身”而非具体框架为主线，对服务治理（Service Governance）做一次体系化、平台化、可演进的完整拆解，并把 Service Mesh、Dubbo、Spring Cloud 放在同一张能力坐标系中进行对比与落地说明，避免“工具即架构”的误区。
一、什么是服务治理（先立共识）
1️⃣ 一句话定义
服务治理，是在分布式系统中，对“服务之间的调用关系、通信行为与运行风险”进行统一控制、观测和演进的能力体系。
核心对象不是“服务”，而是：
- 调用
- 流量
- 失败
- 演进节奏
2️⃣ 服务治理要解决的本质问题
- 服务如何被发现
- 请求如何被路由
- 失败如何被隔离
- 流量如何被控制
- 变更如何被平滑演进
- 问题如何被快速定位
二、服务治理的核心能力拆解（与技术无关）
| 能力域 | 说明 |
|---|---|
| 服务发现 | 服务注册、心跳、下线 |
| 路由治理 | 版本路由、标签路由 |
| 负载均衡 | 本地 / 全局策略 |
| 弹性治理 | 超时、重试、熔断、隔离 |
| 流量治理 | 限流、降级、灰度 |
| 可观测性 | Metrics / Traces |
| 安全治理 | mTLS、认证 |
| 演进治理 | 蓝绿、金丝雀 |
👉 这张表就是“服务治理平台”的能力清单。
三、三种技术路线的本质差异
1️⃣ Dubbo / Spring Cloud（SDK 型治理）
架构特点
- 治理能力 内嵌在业务进程中
- 通过 SDK / Starter 实现
优点
- 性能损耗低
- 语义清晰
- 上手成本低
局限
- 强语言绑定
- 升级成本高
- 治理策略分散在代码中
2️⃣ Service Mesh（Sidecar / Ambient）
架构特点
- 治理能力 下沉到基础设施层
- 通过代理（Envoy）实现
优点
- 语言无关
- 策略集中
- 对业务零侵入
局限
- 架构复杂
- 运维成本高
- 性能与可观测性成本
3️⃣ 本质差异总结
| 维度 | Dubbo / SC | Service Mesh |
|---|---|---|
| 治理位置 | 应用内 | 基础设施层 |
| 侵入性 | 高 | 低 |
| 语言依赖 | 强 | 无 |
| 升级难度 | 高 | 低 |
| 适用阶段 | 中小规模 | 大规模、多语言 |
四、核心治理能力逐项展开（重点）
1️⃣ 服务发现与注册
- 服务实例注册
- 健康检查
- 动态上下线
Mesh 中由控制面维护，SDK 中由客户端完成。
2️⃣ 路由与流量治理（治理的灵魂）
常见规则
- 按版本
- 按标签
- 按请求头
- 按用户
典型场景
- 金丝雀发布
- A/B 测试
- 灰度回滚
3️⃣ 弹性与容错治理
标准能力
- Timeout
- Retry
- Circuit Breaker
- Bulkhead
没有弹性治理的微服务，一定会“雪崩”。
4️⃣ 限流与降级
- 全局限流
- 单服务限流
- 熔断后自动降级
5️⃣ 可观测性（治理的眼睛）
- QPS / RT / Error
- 依赖拓扑
- 异常传播路径
📌 Mesh 天然更适合统一观测。
6️⃣ 安全治理（零信任基础）
- 服务身份
- mTLS
- 调用鉴权
五、治理与平台的协同关系（你关心的重点）
与发布平台
- 发布策略驱动路由规则
- 自动灰度
与配置中心
- 治理规则配置化
- 动态生效
与 SRE
- SLO 触发限流 / 降级
与 CMDB
- 服务拓扑与归属关系
六、落地策略（非常现实）
1️⃣ 不要“全量 Mesh 化”
- 从入口 / 核心链路开始
- 混合治理是常态
2️⃣ 统一“治理抽象”
- 规则模型统一
- 执行方式可多样
3️⃣ 治理规则必须可回滚
七、成熟度演进模型
L1：基础发现与负载
- SDK 模式
L2：弹性治理
- 超时 / 熔断
L3：流量治理
- 灰度 / 限流
L4：平台治理
- Mesh / 控制面
