服务网格
服务网格(Service Mesh)将微服务间通信的横切关注点(负载均衡、熔断、重试、追踪、mTLS)从业务代码中剥离,下沉到基础设施层的 Sidecar 代理中处理。
核心思想
传统微服务(Spring Cloud 方式)
业务代码 + Ribbon/Feign + Resilience4j + Sleuth + ...
→ 每个服务都需要引入这些库,语言/框架绑定
服务网格方式
业务代码(只关心业务逻辑)
+ Sidecar 代理(Envoy,透明拦截所有进出流量)
→ 与语言/框架无关,统一治理
架构组成
控制平面(Control Plane)— Istiod
├── Pilot — 下发路由规则给 Envoy
├── Citadel — 管理证书(mTLS)
└── Galley — 配置验证
数据平面(Data Plane)
每个 Pod 注入一个 Envoy Sidecar
所有流量经由 Envoy 代理,无需修改业务代码
Istio 安装(K8s)
# 下载 istioctl
curl -L https://istio.io/downloadIstio | sh -
# 安装(demo profile 适合学习)
istioctl install --set profile=demo -y
# 为命名空间开启 Sidecar 自动注入
kubectl label namespace default istio-injection=enabled流量管理
VirtualService(路由规则)
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-service
spec:
hosts:
- order-service
http:
# 灰度:10% 流量到 v2
- match:
- headers:
X-Gray:
exact: "true"
route:
- destination:
host: order-service
subset: v2
- route:
- destination:
host: order-service
subset: v1
weight: 90
- destination:
host: order-service
subset: v2
weight: 10DestinationRule(熔断 + 负载均衡)
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: order-service
spec:
host: order-service
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
connectionPool:
tcp:
maxConnections: 100
http:
http1MaxPendingRequests: 50
maxRequestsPerConnection: 10
outlierDetection: # 熔断配置
consecutive5xxErrors: 5 # 连续 5 次 5xx 则驱逐实例
interval: 30s
baseEjectionTime: 30s
maxEjectionPercent: 50
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2安全(mTLS)
# 强制命名空间内所有服务间通信使用 mTLS
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT# 授权策略:只允许 frontend 服务访问 order-service
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: order-policy
spec:
selector:
matchLabels:
app: order-service
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/frontend"]
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/order/*"]可观测性
Istio 自动采集三种信号,无需修改业务代码:
| 信号 | 工具 |
|---|---|
| 指标(Metrics) | Prometheus + Grafana(Kiali 面板) |
| 链路追踪 | Jaeger / Zipkin(需传播 B3 头) |
| 访问日志 | Envoy Access Log → ELK |
# 开启访问日志
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
name: access-log
spec:
accessLogging:
- providers:
- name: envoySpring Cloud vs 服务网格
| 能力 | Spring Cloud | Istio |
|---|---|---|
| 负载均衡 | LoadBalancer(代码) | Envoy(透明) |
| 熔断 | Resilience4j(代码) | DestinationRule outlierDetection |
| 重试 | Feign Retry(代码) | VirtualService retries |
| 链路追踪 | Micrometer Tracing(代码) | 自动注入(透明) |
| mTLS | 手动实现 | 自动(PeerAuthentication) |
| 语言依赖 | 强依赖 JVM | 无语言限制 |
| 运维复杂度 | 低 | 高(需 K8s + Istio) |
结论:中小项目用 Spring Cloud 即可;大规模多语言异构微服务、或需要统一零信任安全时,引入服务网格。两者并不互斥,可共存过渡。
迁移路径
阶段 1:Spring Cloud 原有体系继续运行
阶段 2:部署到 K8s,保留 Spring Cloud 能力
阶段 3:引入 Istio,逐步将 LB/熔断/追踪下沉到 Sidecar
阶段 4:移除 Ribbon/Resilience4j 等依赖,业务代码更纯粹
相关链接
本目录
- 微服务安全(mTLS 对比、JWT 方案)
- 灰度发布(VirtualService 流量分割)
- 链路追踪(Istio 自动注入 vs Micrometer)
- 熔断与限流(Resilience4j vs DestinationRule)
- Spring Cloud 基础
- Spring Cloud 目录