1 · Service-Mesh#

把“通信逻辑”从业务代码中剥离出来，交给基础设施处理

S - 什么场景：微服务架构下，服务之间需要大量网络通信，且必须处理服务发现、负载均衡、重试、熔断、限流、mTLS、可观测性（tracing/metrics/logging）等横切关注点

C - 什么冲突：这些通信逻辑如果嵌入业务代码（SDK/框架方式），会导致：

• 每种语言都要实现一套，多语言栈维护成本爆炸
• 通信逻辑与业务逻辑强耦合，升级治理策略需要改业务代码并重新部署
• 各团队实现不一致，全局策略（如灰度、流量镜像）难以统一推行

Q - 什么问题：如何在不侵入业务代码的前提下，统一、透明地管理服务间通信？

A - 回答问题：Service Mesh — 在每个服务实例旁部署一个 Sidecar 代理（如 Envoy），由控制平面（如 Istio）统一下发策略。业务进程只管 localhost 通信，所有路由、安全、可观测性逻辑由 Sidecar 透明接管，实现”通信逻辑从业务代码剥离到基础设施层”

1.1 · 架构（以 Istio + K8s 为例）#

iptables 劫持实现透明代理，Istiod watch K8s 资源生成 xDS 配置下发给所有 Envoy，数据平面和控制平面彻底分离。

1.1.1 · 数据平面 (Data Plane)#

每个 Pod 里注入一个 Envoy Sidecar 容器（通过 istio-injection=enabled 标签，Istio 的 MutatingWebhook 自动注入）：

1. Inbound：Pod 收到的流量先被 iptables 劫持到 Sidecar → Sidecar 执行策略（mTLS 解密、鉴权、限流）→ 转发给业务容器的 localhost:port
2. Outbound：业务容器发出的流量同样被 iptables 劫持到 Sidecar → Sidecar 做服务发现、负载均衡、重试、熔断 → mTLS 加密后发到目标 Pod 的 Sidecar

业务容器全程只和 localhost 通信，完全无感知。

1.1.2 · 控制平面 (Control Plane)#

Istiod 是单体控制平面进程，整合了三个核心职责：

组件（逻辑）	职责	对接 K8s 的方式
Pilot	服务发现 + 路由规则 → 生成 xDS 配置下发给所有 Envoy	Watch Service、Endpoint、VirtualService、DestinationRule 等 CRD
Citadel	证书签发与轮换，实现 Pod 间 mTLS 零信任	利用 K8s ServiceAccount 作为身份标识
Galley	配置校验与分发	校验用户提交的 Istio CRD

1.1.3 · 流量路径（一次请求）

外部流量
  → Istio IngressGateway (本身也是 Envoy)
    → Pod A 的 Sidecar (iptables 劫持入站)
      → App A (业务处理)
        → App A 发起对 Service B 的调用
          → Pod A 的 Sidecar (iptables 劫持出站, 服务发现, 负载均衡, mTLS)
            → Pod B 的 Sidecar (mTLS 解密, 鉴权)
              → App B

1.1.4 · 关键 K8s 集成点#

• Sidecar 注入：MutatingAdmissionWebhook，namespace 级别 istio-injection=enabled
• 服务发现：Istiod watch K8s Service + Endpoints，转换为 Envoy 的 Cluster/Endpoint 配置
• 流量规则：通过 CRD 声明式管理（VirtualService 路由、DestinationRule 负载均衡策略、Gateway 入口）
• 流量劫持：init container 设置 iptables 规则，将 Pod 所有进出流量重定向到 Sidecar 端口