1. 服务网格概述
1.1 服务网格的定义
服务网格（Service Mesh）是云原生架构中用于处理服务间通信的基础设施层。它通过将流量管理、安全策略和可观测性能力从业务代码中剥离，下沉到独立的代理层（通常以 Sidecar 模式部署），实现了通信逻辑与业务逻辑的完全解耦。
核心思想：在 Kubernetes Pod 中注入一个轻量级代理（如 Envoy），所有进出业务容器的流量都经过该代理，由代理统一执行路由、负载均衡、认证、加密、监控等操作，业务容器只需关注自身逻辑。
服务网格的典型部署模型如下：
关键理解：服务网格将通信层抽象为数据面（Sidecar 代理集群）和控制面（策略下发、证书管理、指标聚合）。数据面负责执行，控制面负责决策，二者分离使得策略变更无需重启业务容器。
1.2 核心功能
服务网格提供三大核心能力，覆盖分布式系统通信的全部痛点：
| 功能域 | 核心能力 | 典型场景 |
|---|---|---|
| 流量管理 | 请求路由、灰度发布、熔断、重试、超时、流量镜像 | 金丝雀发布 5% 流量到 v2 版本；根据 Header 将特定用户路由到灰度环境 |
| 安全 | mTLS 自动加密、身份认证、细粒度授权策略、证书轮换 | 服务间全链路 mTLS 加密；基于 JWT 的访问控制；拒绝未授权服务调用 |
| 可观测性 | 分布式追踪、Prometheus 指标、访问日志、拓扑可视化 | Jaeger 追踪请求全链路；Kiali 展示服务依赖图；审计日志记录每一次 RPC |
1.3 主流服务网格对比
当前生产环境最成熟的服务网格方案为 Istio、Linkerd 和 Consul Connect。三者在架构、性能、功能深度上各有侧重：
| 对比维度 | Istio | Linkerd | Consul Connect |
|---|---|---|---|
| 数据面代理 | Envoy（C++，功能极强） | Linkerd-proxy（Rust，轻量） | Envoy 或内置代理 |
| 控制面组件 | Pilot、Mixer（已弃用）、Citadel、Galley → 现为 istiod 单体 | 控制面极简（仅 controller + destination） | Consul Server + 内置 Connect 控制器 |
| 性能开销 | 中等（Envoy 功能多，资源占用较高） | 低（Rust 代理，P50 延迟增加 < 5ms） | 中等（依赖 Envoy 时与 Istio 接近） |
| mTLS 支持 | 自动 mTLS，严格/宽容/关闭模式 | 自动 mTLS，默认开启 | 自动 mTLS，基于 Connect CA |
| 授权策略 | AuthorizationPolicy（CRD），支持 JWT、DENY、ALLOW | ServerAuthorization（资源型），策略较简单 | Intentions（服务到服务 ACL） |
| 可观测性集成 | Prometheus、Grafana、Jaeger、Kiali 原生集成 | Prometheus + Grafana 内置，支持 OpenTelemetry | Prometheus 集成，需额外配置 |
| Kubernetes 原生度 | 极高，CRD 驱动，社区最活跃 | 极高，专为 K8s 设计，安装极简 | 中等，强依赖 Consul 生态，支持 VM 混合 |
| 学习曲线 | 陡峭（概念多、CRD 多） | 平缓（概念少、默认安全） | 中等（需理解 Consul 体系） |
选型建议：若团队追求功能全面、生态丰富且愿意投入学习成本，Istio 是当前事实标准；若追求极简运维、低资源开销且功能够用即可，Linkerd 是更轻量的选择；若已有 Consul 基础设施或需要同时管理 K8s 和虚拟机，Consul Connect 的多平台支持更具优势。
1.4 服务网格架构总览
下图以 Istio 为例展示服务网格的完整架构，后续章节将围绕该架构中的策略注入点（控制面与数据面）展开 OPA 集成与审计日志配置：
本课程聚焦：上图中橙色高亮的 OPA 策略引擎 和 审计日志收集器 是本章节的核心。后续将详细讲解如何在 Istio 控制面集成 OPA 作为外部授权服务，并在 Envoy Sidecar 侧配置审计日志输出，实现服务间调用的策略执行与全量审计。