服务网格架构 (Istio/Linkerd)

Source: Dev.to

所以，你已经拥抱了微服务革命！恭喜你！你把单体应用拆分成了一系列独立可部署的服务，每个服务都各司其职，协同运转。听起来像是一场独立组件的美妙交响曲，对吧？好吧……也许不尽然。

随着微服务“动物园”规模的扩大，你可能会开始注意到一些…怪现象：

• 服务之间难以相互发现
• 请求莫名其妙地超时
• 调试变成了分布式日志的迷宫
• 安全性像城堡上的一把薄弱挂锁

这，就是 服务网格（Service Mesh） 的魔法出现拯救你（以及你的理智）的时候。

Service Mesh = 隐形指挥家，指挥你的微服务交响乐。
它 不是 通过重写应用代码来实现的；而是通过添加一个专门的基础设施层来处理服务之间的通信。

服务网格解决的根本挑战

想象一下，你有一堆小小的 LEGO 砖块（你的微服务），它们需要相互通信才能构建出宏伟的城堡。

试图将所有这些能力直接嵌入每个微服务，会迅速导致代码重复、实现不一致以及开发噩梦。这正是服务网格大显身手的地方。

服务网格架构

关键特性（“控制器”带来的价值）

1. 流量管理（A/B 测试、金丝雀发布、回滚）

Istio 示例 – VirtualService

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app-vs
spec:
  hosts:
    - my-app
  http:
    - route:
        - destination:
            host: my-app
            subset: v1
          weight: 90
        - destination:
            host: my-app
            subset: v2
          weight: 10

此配置告诉 Istio 将 90 % 的流量发送到 my-app 的 v1 子集，10 % 发送到 v2。

Linkerd 示例 – ServiceProfile + TrafficSplit

# TrafficSplit 资源（不同 Linkerd 版本可能略有差异）
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: my-app-traffic
spec:
  service: my-app          # Kubernetes Service 的名称
  backends:
    - service: my-app-v1   # v1 的底层 Service
      weight: 900
    - service: my-app-v2   # v2 的底层 Service
      weight: 100

Linkerd 通过将 ServiceProfile（路由元数据）与 TrafficSplit 结合，实现类似的加权路由。

2. 可观测性（指标、分布式追踪、访问日志）

• 指标 – 请求延迟、成功/错误率、请求量等。
• 分布式追踪 – 跨多个服务跟踪单个请求（Jaeger、Zipkin 等）。
• 访问日志 – 对所有服务间通信进行统一、标准化的集中日志记录。

Linkerd 示例 – 查看指标

Linkerd 自带仪表盘，可开箱即用地可视化服务指标。你也可以通过 Prometheus 查询相同的数据。

3. 弹性（重试、超时、熔断、健康检查）

Istio 示例 – 配置重试和超时

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app-retry
spec:
  hosts:
    - my-app
  http:
    - route:
        - destination:
            host: my-app
      retries:
        attempts: 3
        perTryTimeout: 2s
        retryOn: gateway-error,connect-failure,refused-stream
      timeout: 5s

（上面的片段配置了最多三次重试，每次尝试的超时为 2 秒，总请求超时为 5 秒。）

TL;DR – 为什么使用服务网格？

VirtualService 示例

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app-vs
spec:
  hosts:
  - my-app
  http:
  - route:
    - destination:
        host: my-app
    retries:
      attempts: 3
      timeout: 10s

Source: …

保护您的微服务

服务网格通过提供以下功能简化安全性：

• 相互 TLS（mTLS） – 加密服务之间的通信并验证客户端和服务器的身份。
• 授权策略 – 定义细粒度的访问控制规则，指定哪些服务可以相互通信。

Istio 示例（启用 mTLS）

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT

此策略在 default 命名空间内对所有通信强制执行严格的 mTLS。

Istio vs. Linkerd

两者都旨在解决相同的问题，但采用的方式略有不同。

Istio

由 Google、IBM 和 Lyft 构建的成熟、功能丰富的服务网格，使用 Envoy 作为数据平面。

优点

• 功能广泛 – 高级流量管理、安全策略、故障注入、分布式追踪等。
• 强大的策略执行 – 对路由、安全和可观测性提供细粒度策略。
• 生态系统集成度高 – 与其他 CNCF 项目和云原生工具配合良好。
• 成熟且被广泛采用 – 社区规模大，采纳基础稳固。

缺点

• 复杂性 – 学习曲线陡峭，对小团队或简单使用场景的运维开销较高。
• 资源消耗大 – 与 Linkerd 相比，CPU 和内存使用更高。
• 占用空间大 – 控制平面组件更为庞大。

Linkerd

由 Buoyant 开发的轻量级网格，侧重简洁、性能和易用性。

优点

• 简洁易用 – 安装、配置和运行快速，适合新手。
• 性能与效率 – 使用高性能的 Rust 代理，延迟低，资源占用最小。
• 核心功能聚焦 – 提供必要的网格特性，不会让用户感到负担。
• 开箱即用的可观测性 – 包含精致的仪表盘。

缺点

• 高级功能较少 – 对于极其复杂的流量路由或细粒度授权场景可能不足。
• 功能集较小 – 如果需要所有可能的功能，Istio 可能更合适。

服务网格入门

前置条件

• 容器编排平台 – 大多数网格运行在 Kubernetes 上，因此需要一个可用的集群。
• 了解您的应用架构 – 知道各服务之间的调用关系以及它们的部署方式。
• 基础 Kubernetes 知识 – 熟悉 Deployments、Services、Namespaces 以及 kubectl。
• 对理智的渴望 – 可选，但很有帮助！

安装概览

两种网格都提供 CLI 工具用于安装。

Istio（简化版）

# Download the Istio CLI
curl -L https://istio.io/downloadIstio | sh -

# Navigate to the downloaded directory
cd istio-*

# Install Istio with a profile (e.g., 'default' or 'demo')
bin/istioctl install --set profile=demo

Linkerd（简化版）

# Download the Linkerd CLI
curl -sL https://linkerd.io/install | sh

# Install Linkerd
linkerd install | kubectl apply -f -

为命名空间启用网格

• Istio – 为命名空间打标签：

  kubectl label namespace default istio-injection=enabled

• Linkerd – 将命名空间添加到其注入策略（示例命令）：

  linkerd inject --enable-per-pod-explicit-annot

在 Istio 与 Linkerd 之间的选择

如果你需要 Istio，请考虑：

• 需要一套完整的高级功能，以实现复杂的流量管理、安全性和可观测性。
• 拥有大型分布式系统，通信模式错综复杂。
• 团队能够处理更复杂的系统。
• 深度投入 Kubernetes 生态系统并希望实现深度集成。

如果你选择 Linkerd，请考虑：

• 想要一个简单、高性能且易于运维的服务网格。
• 对服务网格新手，倾向于温和的入门体验。
• 优先保证可靠通信、基本流量控制和良好的可观测性。
• 对资源效率有严格要求。

最终思考

微服务架构提供了巨大的灵活性和可扩展性，但它也在管理服务间通信方面带来了挑战。像 Istio 和 Linkerd 这样的服务网格并非仅是流行词汇——它们是能够为分布式系统的混乱带来秩序的强大解决方案。它们提供：

• 智能流量管理
• 强大的安全性（例如 mTLS、授权策略）
• 深入的可观测性

采用服务网格可以让你专注于构建业务逻辑，而不是与网络复杂性搏斗。无论你选择功能丰富的 Istio，还是简洁优雅的 Linkerd，都是朝着构建更具弹性、更安全、更易管理的微服务应用迈出的重要一步。

前进吧，驯服你的微服务群落——你的指挥者正等着你！