架构设计

发布日期: 2024-01-01

更新日期: 2026-03-10

文章字数: 5.4k

阅读时长: 21 分

服务网格（Service Mesh）详解

服务网格（Service Mesh）是微服务架构中的基础设施层，用于处理服务间通信。它通过将服务间通信的复杂性从业务代码中分离出来，实现了服务治理的统一管理。

服务网格概述

什么是服务网格

服务网格是一个专门用于处理服务间通信的基础设施层，它提供了一种统一的方式来管理微服务之间的网络通信，包括服务发现、负载均衡、流量管理、安全、可观测性等功能。

graph TB
    A[应用服务] --> B[服务网格]
    B --> C[服务发现]
    B --> D[负载均衡]
    B --> E[流量管理]
    B --> F[安全]
    B --> G[可观测性]
    B --> H[其他服务]
    
    style A fill:#ffcccc
    style B fill:#ccffcc
    style H fill:#ccccff

设计理念

服务网格遵循以下设计理念：

关注点分离：将服务间通信逻辑从业务代码中分离
透明代理：通过 Sidecar 模式实现透明的服务间通信
统一管理：通过控制平面统一管理所有服务间通信策略
语言无关：支持多种编程语言，无需修改业务代码

发展历程

timeline
    title 服务网格发展历程
    2016 : Linkerd 1.0 发布
         : 第一个服务网格项目
    2017 : Istio 0.1 发布
         : Google、IBM、Lyft 联合推出
    2018 : Envoy 成为 CNCF 项目
         : 服务网格数据平面标准
    2019 : Service Mesh Interface (SMI)
         : 标准化服务网格接口
    2020 : Istio 1.0 稳定版
         : 生产环境就绪
    2021 : 云原生服务网格成熟
         : 大规模生产应用

核心概念

Sidecar 模式

Sidecar 是服务网格的核心模式，每个服务实例都伴随一个 Sidecar 代理。

graph LR
    A[服务 A] --> B[Sidecar A]
    C[服务 B] --> D[Sidecar B]
    B <--> D
    
    style A fill:#ffcccc
    style B fill:#ccffcc
    style C fill:#ffcccc
    style D fill:#ccffcc

Sidecar 特点

透明代理：服务间的所有通信都通过 Sidecar
独立部署：Sidecar 与业务服务独立部署
语言无关：支持任何编程语言的服务
统一管理：所有 Sidecar 由控制平面统一管理

数据平面（Data Plane）

数据平面由所有 Sidecar 代理组成，负责实际的数据转发和处理。

数据平面职责

流量转发：转发服务间的请求和响应
服务发现：发现和连接目标服务
负载均衡：在多个服务实例间分配流量
健康检查：检查服务实例的健康状态
流量策略执行：执行路由、限流、熔断等策略

控制平面（Control Plane）

控制平面负责管理和配置数据平面，提供统一的策略管理。

控制平面职责

配置管理：管理所有 Sidecar 的配置
策略定义：定义流量管理、安全等策略
服务注册：管理服务注册和发现
证书管理：管理服务间的 TLS 证书
监控数据收集：收集和聚合监控数据

架构层次

graph TB
    A[应用层] --> B[服务网格层]
    B --> C[数据平面
Sidecar 代理]
    B --> D[控制平面
策略管理]
    C --> E[基础设施层
Kubernetes/容器]
    
    style A fill:#ffcccc
    style B fill:#ccffcc
    style C fill:#ccccff
    style D fill:#ffffcc
    style E fill:#ffccff

架构设计

整体架构

graph TB
    subgraph "控制平面"
        A[Pilot/控制中心]
        B[Citadel/安全]
        C[Galley/配置]
        D[Telemetry/监控]
    end
    
    subgraph "数据平面"
        E[Sidecar A]
        F[Sidecar B]
        G[Sidecar C]
    end
    
    subgraph "应用服务"
        H[服务 A]
        I[服务 B]
        J[服务 C]
    end
    
    A --> E
    A --> F
    A --> G
    B --> E
    B --> F
    B --> G
    
    H --> E
    I --> F
    J --> G
    
    E <--> F
    F <--> G
    
    style A fill:#ccffcc
    style E fill:#ccccff
    style H fill:#ffcccc

Sidecar 注入方式

自动注入

# 通过 MutatingWebhook 自动注入
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    istio-injection: enabled  # 启用自动注入

手动注入

1 2	# 使用 istioctl 手动注入 istioctl kube-inject -f deployment.yaml \| kubectl apply -f -

流量路径

sequenceDiagram
    participant App1 as 应用服务 A
    participant Sidecar1 as Sidecar A
    participant Sidecar2 as Sidecar B
    participant App2 as 应用服务 B
    
    App1->>Sidecar1: 发送请求
    Sidecar1->>Sidecar1: 服务发现
    Sidecar1->>Sidecar1: 负载均衡
    Sidecar1->>Sidecar1: 流量策略
    Sidecar1->>Sidecar2: 转发请求
    Sidecar2->>Sidecar2: 安全验证
    Sidecar2->>App2: 转发请求
    App2->>Sidecar2: 返回响应
    Sidecar2->>Sidecar1: 返回响应
    Sidecar1->>App1: 返回响应

流量劫持、特征分析与负载均衡

服务网格的数据平面要实现「无侵入」的流量治理，核心链路是：先把流量劫持到 Sidecar → 在 Sidecar 内解析并分析流量特征 → 基于特征做路由与负载均衡。下面按这三步说明做法与关系。

1. 流量劫持（Traffic Hijacking）

流量劫持的目的是：让 Pod 内应用发出的出站流量和发往应用的入站流量都先经过 Sidecar，而不是应用与外界直连。这样所有服务间通信都可被统一拦截、观测和策略控制。

劫持思路概览

graph LR
    subgraph "未劫持"
        A1[应用] -->|直连| B1[其他服务]
    end
    subgraph "劫持后"
        A2[应用] -->|被重定向| C[Sidecar]
        C -->|转发| B2[其他服务]
    end

入站：发往本 Pod 某端口的请求被重定向到 Sidecar 的入站监听端口，由 Sidecar 再转发给本 Pod 内的应用。
出站：应用以为自己在访问「目标地址:端口」，实际连接被重定向到 Sidecar 的出站端口，由 Sidecar 做服务发现、路由和负载均衡后再连到真实后端。

常见实现方式

方式	说明	典型实现
iptables 重定向	在 init 容器里配置 iptables，把指定端口的流量 REDIRECT 到 Sidecar	Istio（默认）、Linkerd 早期
eBPF	在内核用 eBPF 程序做重定向，无需改 iptables，性能更好	Cilium、Linkerd 可选
透明代理	Sidecar 监听本地或虚拟网卡，应用仍用原目标地址，由代理解析并转发	各类 Sidecar 的通用能力

Istio 的 iptables 劫持示意

Istio 通过 init 容器 在 Pod 启动前写好 iptables 规则，把「非 Sidecar 发出的」出站流量和入站流量都转到 Envoy Sidecar：

flowchart TB
    subgraph Pod
        App[应用进程]
        Envoy[Envoy Sidecar]
        App -->|"出站: 例如 :15001"| Envoy
        Envoy -->|"入站: 例如 :15006"| App
    end
    External[集群内/外服务] <--> Envoy

出站：应用访问 user-service:80 时，内核根据 iptables 把连接重定向到 Envoy 的 outbound 监听端口（如 15001），Envoy 再根据 user-service 做服务发现和负载均衡。
入站：发往本 Pod 业务端口的流量被重定向到 Envoy 的 inbound 端口（如 15006），Envoy 校验、统计后再转发给本 Pod 应用。

这样无需改应用代码或配置，即可实现透明劫持。

2. 流量特征分析（Traffic Characterization）

流量进入 Sidecar 后，Sidecar 会解析协议并提取流量特征，用于路由匹配、负载均衡选后端、限流键、监控维度等。

可用的流量特征层次

graph TB
    L4[L4 特征] --> L7[L7 特征]
    L4 --> 目标地址
    L4 --> 目标端口
    L4 --> 协议
    L7 --> HTTP方法
    L7 --> 路径/URL
    L7 --> Host/Authority
    L7 --> Header/Query
    L7 --> gRPC 服务/方法

L4：目标 IP、端口、协议（TCP/UDP）——用于判断「是不是要交给网格」、以及做简单路由。
L7（HTTP/gRPC）：方法、路径、Host、Header、Query、gRPC 服务名/方法名等——用于：
- 路由：VirtualService 的 match（按 path、header、version 等）。
- 负载均衡：一致性哈希的 key（如 x-user-id）、会话保持。
- 限流/配额：按 path、user 等维度限流。
- 可观测性：指标和追踪的维度（status、path、client 等）。

在配置中的体现

按特征路由：在 VirtualService 里用 uri、headers、queryParams 等做 match，再决定 destination 和 weight。
按特征负载均衡：在 DestinationRule 里用 consistentHash 的 httpHeaderName 或 useSourceIp 等，把同一特征的流量固定到同一组实例，实现会话保持或均匀分摊。

因此，流量特征分析是「劫持之后、负载均衡之前」的中间步骤：先解析出特征，再据此做路由与负载均衡决策。

3. 基于特征做负载均衡（Load Balancing）

完成劫持和特征分析后，Sidecar 对「要访问的服务」做服务发现，得到多个 Endpoint，再按配置的负载均衡算法选出一个后端并转发。

与「流量劫持 + 特征分析」的关系

sequenceDiagram
    participant App as 应用
    participant Sidecar as Sidecar
    participant CP as 控制平面
    participant Backend as 后端实例

    App->>Sidecar: 请求（被劫持）
    Sidecar->>Sidecar: 解析 L4/L7 特征
    Sidecar->>Sidecar: 路由匹配（VirtualService）
    Sidecar->>CP: 服务发现 / 集群配置
    CP-->>Sidecar: Endpoint 列表 + LB 策略
    Sidecar->>Sidecar: 按特征 + 算法选实例
    Sidecar->>Backend: 转发请求
    Backend-->>Sidecar: 响应
    Sidecar-->>App: 响应

劫持：保证流量一定经过 Sidecar。
特征分析：提供「按 path/header/用户做路由」和「一致性哈希 key、会话保持」等输入。
负载均衡：在已确定的 destination 的多个实例中，用 Round Robin、Least Request、一致性哈希等算法选出一个实例。

算法与特征的使用

算法	是否依赖流量特征	典型用法
ROUND_ROBIN	否	均匀分摊，不关心请求内容。
LEAST_REQUEST	可选	可按请求头做一致性哈希前的分流。
RANDOM	否	随机选实例。
CONSISTENT_HASH	是	用 `httpHeaderName`（如 `x-user-id`）、`httpCookie`、`useSourceIp` 等做 key，同一 key 总是到同一实例，便于会话保持或缓存亲和。

例如：希望同一用户的请求尽量打到同一实例，可以在 DestinationRule 里配置基于 x-user-id 的 consistentHash，这就是基于流量特征的负载均衡：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: user-service
spec:
  host: user-service
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: "x-user-id"  # 按请求头做一致性哈希，同一用户固定到同一实例

小结

流量劫持：通过 iptables/eBPF/透明代理把入站和出站流量都引到 Sidecar，实现无侵入拦截。
流量特征分析：在 Sidecar 内解析 L4/L7 特征，为路由、负载均衡、限流和可观测性提供依据。
负载均衡：在服务发现得到的多个实例中，结合流量特征（如 header、cookie、source ip）和配置的算法（轮询、最少请求、一致性哈希等）选择后端并转发。

三者串联起来，就是服务网格数据平面上「劫持 → 分析 → 负载均衡」的完整链路；前文主要功能中的「负载均衡」「流量管理」等章节，是在此基础上的具体配置与策略。

主要功能

1. 服务发现

服务网格自动发现和管理服务实例。

服务注册

# Kubernetes Service
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - port: 80
    targetPort: 8080

自动发现

Kubernetes：自动发现 Service 和 Endpoint
Consul：集成 Consul 服务注册中心
Eureka：集成 Eureka 服务注册中心

2. 负载均衡

提供多种负载均衡算法。

负载均衡算法

轮询（Round Robin）：依次分配请求
最少连接（Least Connection）：分配给连接数最少的实例
随机（Random）：随机分配请求
一致性哈希（Consistent Hash）：基于请求特征分配

配置示例

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: user-service
spec:
  host: user-service
  trafficPolicy:
    loadBalancer:
      simple: LEAST_CONN  # 最少连接算法

3. 流量管理

流量路由

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - match:
    - headers:
        version:
          exact: v2
    route:
    - destination:
        host: user-service
        subset: v2
      weight: 100
  - route:
    - destination:
        host: user-service
        subset: v1
      weight: 100

流量分割（A/B 测试）

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - route:
    - destination:
        host: user-service
        subset: v1
      weight: 90  # 90% 流量到 v1
    - destination:
        host: user-service
        subset: v2
      weight: 10  # 10% 流量到 v2

流量镜像

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - route:
    - destination:
        host: user-service
        subset: v1
      weight: 100
    mirror:
      host: user-service
      subset: v2  # 镜像流量到 v2
    mirrorPercentage:
      value: 50  # 50% 流量镜像

超时和重试

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - timeout: 5s  # 超时时间
    retries:
      attempts: 3  # 重试次数
      perTryTimeout: 2s  # 每次重试超时
    route:
    - destination:
        host: user-service

4. 安全

mTLS（双向 TLS）

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT  # 强制 mTLS

授权策略

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: user-service-policy
spec:
  selector:
    matchLabels:
      app: user-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/frontend"]
    to:
    - operation:
        methods: ["GET", "POST"]

JWT 认证

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-auth
spec:
  selector:
    matchLabels:
      app: api-service
  jwtRules:
  - issuer: "https://auth.example.com"
    jwksUri: "https://auth.example.com/.well-known/jwks.json"

5. 可观测性

指标（Metrics）

服务网格自动收集以下指标：

请求速率：QPS、RPS
延迟：P50、P95、P99 延迟
错误率：4xx、5xx 错误率
流量：入站和出站流量

分布式追踪

graph LR
    A[服务 A] --> B[服务 B]
    B --> C[服务 C]
    B --> D[服务 D]
    
    A1[Trace ID: abc123] --> B1[Span 1]
    B1 --> C1[Span 2]
    B1 --> D1[Span 3]
    
    style A1 fill:#ccffcc
    style B1 fill:#ccccff
    style C1 fill:#ffffcc
    style D1 fill:#ffccff

日志聚合

服务网格可以自动收集和聚合日志：

访问日志：HTTP 请求和响应日志
错误日志：错误和异常日志
审计日志：安全相关日志

可视化

Grafana：指标可视化
Jaeger/Kiali：分布式追踪可视化
Prometheus：指标存储和查询

6. 熔断和限流

熔断器

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: user-service
spec:
  host: user-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
        http2MaxRequests: 100
        maxRequestsPerConnection: 2
    outlierDetection:
      consecutiveErrors: 5  # 连续错误数
      interval: 30s  # 检测间隔
      baseEjectionTime: 30s  # 基础驱逐时间
      maxEjectionPercent: 50  # 最大驱逐百分比

限流

apiVersion: policy.istio.io/v1beta1
kind: QuotaSpec
metadata:
  name: request-count
spec:
  rules:
  - quotas:
    - charge: 1
      quota: requestcount
---
apiVersion: policy.istio.io/v1beta1
kind: QuotaSpecBinding
metadata:
  name: request-count
spec:
  quotaSpecs:
  - name: request-count
    namespace: default
  services:
  - user-service

主流实现

Istio

Istio 是最流行的服务网格实现之一。

特点

功能完整：提供完整的服务网格功能
Kubernetes 原生：深度集成 Kubernetes
生产就绪：大规模生产环境验证
社区活跃：活跃的开源社区

架构组件

Pilot：流量管理和服务发现
Citadel：安全和证书管理
Galley：配置管理
Envoy：数据平面代理

安装示例

# 下载 Istio
curl -L https://istio.io/downloadIstio | sh -

# 安装 Istio
istioctl install --set profile=default

# 启用自动注入
kubectl label namespace default istio-injection=enabled

Linkerd

Linkerd 是第一个服务网格项目，以轻量级和易用性著称。

特点

轻量级：资源占用小
易用性：安装和配置简单
性能优秀：低延迟和高吞吐
Rust 实现：使用 Rust 编写，性能优异

安装示例

# 安装 Linkerd CLI
curl -sL https://run.linkerd.io/install | sh

# 安装 Linkerd
linkerd install | kubectl apply -f -

# 验证安装
linkerd check

Consul Connect

Consul Connect 是 HashiCorp Consul 的服务网格功能。

特点

集成 Consul：与 Consul 服务发现深度集成
多平台支持：支持 Kubernetes、Nomad 等
简单配置：配置简单直观

对比表

特性	Istio	Linkerd	Consul Connect
复杂度	高	低	中
资源占用	高	低	中
功能完整性	高	中	中
Kubernetes 集成	优秀	良好	良好
学习曲线	陡峭	平缓	中等
社区活跃度	高	中	中

使用场景

1. 微服务架构

服务网格是微服务架构的理想选择：

服务间通信：统一管理服务间通信
服务治理：统一的服务治理策略
多语言支持：支持不同编程语言的服务

2. 云原生应用

Kubernetes 集成：深度集成 Kubernetes
容器化部署：适合容器化部署场景
弹性伸缩：支持服务的弹性伸缩

3. 混合云和多云

跨云通信：统一管理跨云服务通信
统一策略：统一的流量和安全策略
服务发现：统一的服务发现机制

4. 遗留系统现代化

渐进式迁移：可以渐进式迁移到服务网格
透明代理：对业务代码透明
统一管理：统一管理新旧系统

5. 安全要求高的场景

mTLS：强制服务间 mTLS 通信
细粒度授权：细粒度的访问控制
审计日志：完整的审计日志

优缺点分析

优点

1. 关注点分离

业务代码简化：业务代码无需处理服务间通信逻辑
统一管理：统一管理所有服务间通信策略
降低复杂度：降低微服务架构的复杂度

2. 语言无关

多语言支持：支持任何编程语言
无需修改代码：无需修改业务代码
统一标准：统一的服务间通信标准

3. 统一的可观测性

自动监控：自动收集监控数据
分布式追踪：自动实现分布式追踪
统一视图：统一的可观测性视图

4. 强大的流量管理

灵活路由：灵活的流量路由策略
A/B 测试：支持 A/B 测试和灰度发布
流量镜像：支持流量镜像和回放

5. 安全性

mTLS：自动实现服务间 mTLS
细粒度授权：细粒度的访问控制
证书管理：自动的证书管理

缺点

1. 复杂度增加

学习曲线：需要学习新的概念和工具
运维复杂度：增加了运维复杂度
调试困难：问题排查可能更困难

2. 性能开销

延迟增加：Sidecar 代理增加延迟
资源占用：Sidecar 占用额外资源
吞吐量影响：可能影响系统吞吐量

3. 资源消耗

内存占用：每个 Pod 都需要 Sidecar
CPU 占用：Sidecar 占用 CPU 资源
网络开销：额外的网络跳转

4. 调试和排错

问题定位：问题可能出现在多个层面
日志分散：日志分散在多个组件
工具依赖：需要依赖特定工具

5. 供应商锁定风险

平台依赖：依赖特定的服务网格实现
迁移成本：迁移到其他平台成本高
标准不统一：不同实现标准不统一

最佳实践

1. 渐进式采用

graph LR
    A[阶段1
单服务] --> B[阶段2
部分服务]
    B --> C[阶段3
全部服务]
    C --> D[阶段4
高级功能]
    
    style A fill:#ffcccc
    style B fill:#ffffcc
    style C fill:#ccffcc
    style D fill:#ccccff

从小规模开始：先在小规模环境试用
逐步扩展：逐步扩展到更多服务
验证效果：验证效果后再全面采用

2. 性能优化

减少延迟

使用 eBPF：使用 eBPF 加速数据平面
优化配置：优化 Sidecar 配置
减少跳转：减少不必要的网络跳转

资源优化

资源限制：为 Sidecar 设置资源限制
自动伸缩：根据负载自动伸缩
选择性注入：只对需要的服务注入 Sidecar

3. 安全配置

mTLS 策略

# 生产环境使用 STRICT 模式
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT

授权策略

最小权限原则：只授予必要的权限
细粒度控制：使用细粒度的授权策略
定期审查：定期审查和更新授权策略

4. 监控和告警

关键指标

延迟：P50、P95、P99 延迟
错误率：4xx、5xx 错误率
吞吐量：QPS、RPS
资源使用：CPU、内存使用率

告警规则

# Prometheus 告警规则示例
groups:
- name: service-mesh
  rules:
  - alert: HighErrorRate
    expr: rate(istio_requests_total{response_code=~"5.."}[5m]) > 0.05
    for: 5m
    annotations:
      summary: "High error rate detected"

5. 配置管理

版本控制

GitOps：使用 GitOps 管理配置
配置审查：配置变更需要审查
回滚机制：建立配置回滚机制

环境隔离

命名空间隔离：使用命名空间隔离环境
配置分离：不同环境使用不同配置
测试验证：在测试环境验证配置

6. 故障处理

故障隔离

熔断器：使用熔断器隔离故障服务
超时设置：设置合理的超时时间
重试策略：配置合理的重试策略

降级策略

服务降级：故障时自动降级
流量切换：故障时切换流量
备用方案：准备备用方案

7. 文档和培训

文档

架构文档：详细的架构文档
操作手册：操作和维护手册
故障处理：故障处理指南

培训

团队培训：培训开发团队
运维培训：培训运维团队
最佳实践：分享最佳实践

总结

服务网格是微服务架构中的重要基础设施，它通过将服务间通信的复杂性从业务代码中分离出来，实现了服务治理的统一管理。

核心价值

简化开发：业务代码无需处理服务间通信逻辑
统一管理：统一管理所有服务间通信策略
增强可观测性：自动实现监控、追踪和日志
提升安全性：自动实现 mTLS 和细粒度授权
灵活流量管理：支持灵活的流量路由和管理

适用场景

✅ 微服务架构
✅ 云原生应用
✅ 混合云和多云环境
✅ 安全要求高的场景
✅ 需要统一可观测性的场景

选择建议

Istio：功能完整、生产就绪，适合大型企业
Linkerd：轻量级、易用，适合中小型团队
Consul Connect：已使用 Consul 的场景

注意事项

⚠️ 增加系统复杂度
⚠️ 带来性能开销
⚠️ 需要额外的资源
⚠️ 学习曲线较陡

服务网格不是银弹，需要根据实际场景和需求来决定是否采用。在采用时，应该遵循渐进式采用的原则，从小规模开始，逐步扩展。

参考文献

djaigo

https://blog.djaigo.com/fen-bu-shi-jia-gou/fu-wu-wang-ge.html

本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源 djaigo !

架构设计 Istio 服务网格 Service Mesh Envoy 微服务

向量数据库

2024-01-01 middleware

检索增强生成向量数据库 vector database embedding 相似度搜索

RDMA 详解

2024-01-01 net

零拷贝 RDMA 远程直接内存访问高性能网络 InfiniBand RoCE

服务网格（Service Mesh）详解

服务网格（Service Mesh）详解

目录

服务网格概述

什么是服务网格

设计理念

发展历程

核心概念

Sidecar 模式

Sidecar 特点

数据平面（Data Plane）

数据平面职责

控制平面（Control Plane）

控制平面职责

架构层次

架构设计

整体架构

Sidecar 注入方式

自动注入

手动注入

流量路径

流量劫持、特征分析与负载均衡

1. 流量劫持（Traffic Hijacking）

劫持思路概览

常见实现方式

Istio 的 iptables 劫持示意

2. 流量特征分析（Traffic Characterization）

可用的流量特征层次

在配置中的体现

3. 基于特征做负载均衡（Load Balancing）

与「流量劫持 + 特征分析」的关系

算法与特征的使用

小结

主要功能

1. 服务发现

服务注册

自动发现

2. 负载均衡

负载均衡算法

配置示例

3. 流量管理

流量路由

流量分割（A/B 测试）

流量镜像

超时和重试

4. 安全

mTLS（双向 TLS）

授权策略

JWT 认证

5. 可观测性

指标（Metrics）

分布式追踪

日志聚合

可视化

6. 熔断和限流

熔断器

限流

主流实现

Istio

特点

架构组件

安装示例

Linkerd

特点

安装示例

Consul Connect

特点

对比表

使用场景

1. 微服务架构

2. 云原生应用

3. 混合云和多云

4. 遗留系统现代化

5. 安全要求高的场景

优缺点分析

优点

1. 关注点分离

2. 语言无关

3. 统一的可观测性

4. 强大的流量管理