Service Mesh

1. 定义与职责

服务治理层位于 应用层之下、基础设施之上，用于统一解决微服务架构中的 通信、可靠性、安全、可观测性和配置管理问题。

它的核心目标是：

让业务服务专注写业务，而不是处理分布式系统问题

核心职责：

1. 服务注册与发现
2. 服务间通信治理（负载均衡 / 超时 / 重试）
3. 熔断、限流、降级
4. 统一安全策略（mTLS / 鉴权）
5. 链路追踪与指标采集
6. 配置管理与动态变更

---

2. 服务治理层在整体架构中的位置

API 网关
│
应用层（微服务）
│
▼
┌─────────────────────────┐
│ 服务治理层 │
│ Service Mesh / 注册发现 │
└─────────────────────────┘
│
▼
数据层 / 基础设施层

---

3. 为什么需要服务治理层

3.1 没有服务治理会发生什么？

• 每个服务都要实现：
  • 重试
  • 熔断
  • 负载均衡
  • 鉴权
• 调用链混乱，问题难以定位
• 配置变更需要重新发布服务
• 安全策略分散，无法统一控制

结果：系统复杂度指数级上升。

---

3.2 服务治理的本质

• 把 “横向能力” 从业务代码中抽离
• 下沉到平台或基础设施层
• 通过配置而不是代码来治理系统

---

4. 核心能力模块

4.1 服务注册与发现（Service Discovery）

作用：

• 动态感知服务实例变化
• 支持自动扩缩容

能力：

• 服务注册
• 健康检查
• 实例剔除

常见实现：

• Consul
• Eureka
• Nacos

设计要点：

• 不依赖固定 IP
• 服务必须可被动态替换

---

4.2 服务间负载均衡

作用：

• 在多个服务实例之间合理分发请求

策略：

• Round Robin
• Least Connection
• 基于延迟的自适应负载

实现方式：

• 客户端负载均衡
• Sidecar Proxy（Service Mesh）

---

4.3 超时、重试与熔断

问题背景：

• 网络一定会失败
• 下游一定会变慢

能力：

• 请求超时控制
• 自动重试
• 熔断（Circuit Breaker）

设计要点：

• 重试必须有上限
• 超时 < 调用方 SLA
• 熔断是保护系统，不是修复系统

---

4.4 限流与流量治理

作用：

• 防止局部故障演变为系统雪崩

限流维度：

• 服务级
• 接口级
• 实例级

常见策略：

• Token Bucket
• 并发数限制

---

4.5 服务间安全（Zero Trust）

目标：

• 内部网络不再默认可信

能力：

• mTLS（双向 TLS）
• 服务身份认证
• 访问策略控制

设计要点：

• 服务身份 ≠ IP
• 安全策略集中配置

---

4.6 链路追踪与可观测性

能力：

• 分布式 Trace
• Metrics（QPS / 延迟 / 错误率）
• Logs 关联 Trace ID

工具：

• Jaeger
• Zipkin
• Prometheus

价值：

• 快速定位性能瓶颈
• 精确定位故障节点

---

4.7 配置管理与动态治理

作用：

• 无需重启即可调整系统行为

配置类型：

• 超时 / 重试参数
• 熔断阈值
• 灰度策略
• 安全策略

常见工具：

• Nacos
• Apollo
• Consul KV

---

5. Service Mesh 架构模式

5.1 Sidecar 模式

┌───────────────┐ ┌───────────────┐
│ Service A │ │ Service B │
│ ──────────── │ │ ──────────── │
│ Business │ │ Business │
│ │ │ │
│ ┌─────────┐ │<--->│ ┌─────────┐ │
│ │ Sidecar │ │ │ │ Sidecar │ │
│ └─────────┘ │ │ └─────────┘ │
└───────────────┘ └───────────────┘

特点：

• 业务代码无感知
• 治理能力统一下沉

---

6. 技术选型

能力	技术
Service Mesh	Istio、Linkerd
Proxy	Envoy
服务发现	Consul、Nacos
链路追踪	Jaeger、Zipkin
监控	Prometheus

---

7. 架构文本图（服务治理层）

    应用服务 A
         │
    ┌────▼────┐
    │ Sidecar │
    └────┬────┘
         │
  服务发现 / 负载均衡
         │
    ┌────▼────┐
    │ Sidecar │
    └────┬────┘
         │
    应用服务 B

---

8. CTO 级设计权衡

1. 是否引入 Service Mesh

   • 服务规模 < 20：可暂缓
   • 服务规模 > 50：强烈建议

2. 复杂度与收益

   • Mesh 提供一致性
   • 但引入运维与学习成本

3. 渐进式演进

   • 先注册发现
   • 再流量治理
   • 最后安全与全链路

---

9. 常见反模式

• 业务代码和治理逻辑强耦合
• Mesh 全功能一次性上线
• 不理解就上 Istio
• 没有可观测性就做治理

---

一句 CTO 总结：
服务治理层的价值在于——
把“分布式的痛苦”，集中到平台层承受。