📚 课程目录第2章服务网格基础概念

2. 服务网格基础概念：什么是服务网格、Sidecar模式、数据平面与控制平面、主流服务网格对比

服务网格这几年热度一直没降过。说实话，我刚接触这个概念时也被绕晕过——它到底是一个独立产品，还是Kubernetes的插件？其实都不准确。这块内容理解透了，后面讲内部开发者平台嵌入服务网格的逻辑才站得住。咱们一个一个来拆。

2.1 什么是服务网格

服务网格，简单说，就是基础设施层的一个专用网络通信层。它把微服务之间的流量管理、安全、可观测性抽出来，放到一个独立的平面里，不碰业务代码。

你想想看，传统微服务里，每个服务都得自己处理重试、超时、熔断、认证这些事。要么用库，要么自己写。我见过一个项目，团队花了两周往Java SDK里集成Hystrix，结果版本冲突折腾了一周。服务网格就是把这类逻辑从代码里挪出来，放到系统层去解决。

核心转变： 从“服务自己管网络”变成“网络替你管服务”。业务代码只需要关注业务逻辑，流量治理全交给网格。

2.2 Sidecar模式

服务网格的实现基础，就是Sidecar模式。你可能从Docker或Kubernetes里听说过它——在一个Pod里跑两个容器，一个是业务容器，另一个是辅助容器。这个辅助容器就是Sidecar。

Sidecar本质上是一个轻量级的网络代理，它会拦截进出业务服务的所有流量，然后在代理层执行策略：路由、负载均衡、TLS终止、访问控制、遥测数据收集……

举个例子：服务A想调用服务B，不再直接在代码里写http://service-b:8080，而是发到本地的Sidecar代理——通常是127.0.0.1的某个端口。Sidecar再根据控制平面下发的配置，决定把请求转发给哪个实例。

# 一个典型的Istio Sidecar注入后的Pod结构
apiVersion: v1
kind: Pod
metadata:
  name: payment-v1
spec:
  containers:
  - name: payment          # 业务容器
    image: payment:1.0
  - name: istio-proxy      # Sidecar代理
    image: docker.io/istio/proxyv2:1.20.0
    ports:
    - containerPort: 15001  # 入站流量拦截
    - containerPort: 15006  # 出站流量拦截

注意这里：Sidecar代理是用iptables规则把流量透明劫持过来的。业务容器完全无感，甚至不知道有Sidecar存在。这也是服务网格最大的价值——零侵入。

我个人习惯，在测试环境注入Sidecar后，先到Pod里跑个curl localhost:15000/stats查看代理状态。如果一直不通，先检查iptables是否生效，别急着找网格的Bug。

2.3 数据平面与控制平面

服务网格分为两个逻辑平面：数据平面和控制平面。这两个概念必须分清，否则后面配策略时会一脸懵。

数据平面：由所有Sidecar代理组成。它直接处理业务流量，做转发、负载均衡、健康检查、熔断。每个代理只做一件事——按照控制平面给的规则，高效地转发数据包。
控制平面：负责管理数据平面的行为。它收集服务发现信息、下发路由规则、生成TLS证书、聚合链路追踪和指标。控制平面本身不碰业务流量，只跟数据平面通信。

数据平面是“跑腿的”，控制平面是“发指令的”。二者通过xDS协议（发现服务、监听器、路由、集群等配置）交互。

我曾经遇到一个坑：团队把Istio控制平面升级到1.16，但数据平面还留在1.15。结果Sidecar代理报No healthy upstream——因为新版控制平面下发的Envoy配置字段变了，旧版Envoy不认。所以升级时务必控制平面和数据平面版本保持一致。

2.4 主流服务网格对比

现在市场上主流的选项有四个：Istio、Linkerd、Consul Connect、Kuma。我每个都接触过，简单说说它们的特点。

特性	Istio	Linkerd	Consul Connect	Kuma
数据平面	Envoy（高性能，功能丰富）	Linkerd-proxy（Rust编写，轻量）	内置代理 + Envoy可选	Envoy（与Istio类似）
控制平面语言	Go	Rust + Go	Go	Go
多集群支持	原生支持，配置复杂	通过Service Mirror实现	基于Consul的数据中心同步	原生支持，API简化
资源消耗	较高（Envoy内存占用大）	低（Rust代理极省资源）	中等	中等
学习曲线	陡峭，CRD繁多	平缓，CLI直观	中等，依赖Consul生态	较平缓，API统一
适用场景	大型企业、复杂策略	小型团队、注重资源效率	已有Hashicorp栈	多云/混合云统一管理

Istio功能最全，但重。我前东家的Kubernetes集群有400个Pod，Istio控制平面吃掉2个8C16G的节点资源。你得算好这笔账。

Linkerd更轻量，Rust写的数据平面启动快，内存占用低。我习惯拿它做小团队的快速试验，但有些高级功能（如多重认证、协议嗅探）不如Istio完整。

Consul Connect最大的优势是跟Consul服务发现无缝衔接，如果你已经在用Consul做注册中心，迁移成本低。但它强依赖Consul集群的稳定性，曾经一次Consul Leader选举导致格断联——虽然概率低，但要注意。

Kuma相对新一些，但它在多集群统一管理上做得不错，控制平面天生支持zone隔离，适合混合云场景。如果你有多个K8s集群+虚拟机混合部署，Kuma值得看看。

最后再看一下整体的知识结构，我画了张图把核心概念串起来。

看得清楚吧？左侧数据平面里每个业务服务配一个Sidecar代理，流量经过代理转发。右侧控制平面集中管理策略、证书、配置。二者通过xDS协议通信。这就是服务网格最基本的运作模型。

注意： 别把控制平面和数据平面部署在同一个Kubernetes集群内导致资源竞争。我见过测试环境把Istiod和业务Pod放在同一节点组，结果控制平面OOM后全集群流量策略失效，Sidecar退回“透传”模式，熔断规则全丢了。生产环境建议控制平面独占节点组，加上PodDisruptionBudget和反亲和性。

理解了这些基础概念，后面嵌入内部开发者平台时，你才能判断该在哪个层面做抽象——是把Sidecar注入做成平台模板的一部分，还是通过控制平面API动态下发路由策略。这些选择直接影响平台的可维护性和性能。