📚 课程目录第1章服务网格概述

1. 服务网格概述

1.1 服务网格定义

服务网格（Service Mesh）是云原生架构中用于处理服务间通信的基础设施层。它将流量管理、安全策略、可观测性等能力从业务代码中剥离，下沉到独立的代理层，使开发者无需关注网络通信的复杂性。

  核心价值：服务网格通过 Sidecar 代理模式，实现“业务逻辑与通信逻辑的完全解耦”。在升级窗口演练中，这一特性使得灰度批次间的流量切分、访问日志留痕无需修改应用代码。

维度	传统微服务	服务网格
通信控制	内嵌在业务代码（如熔断、重试）	由 Sidecar 代理统一处理
可观测性	依赖应用 SDK 埋点	代理层自动生成访问日志与指标
升级影响	需修改代码、重新部署	控制面下发配置，数据面热更新
灰度能力	需自行实现流量路由逻辑	内置权重路由、Header 匹配等策略

1.2 Istio / Envoy 架构

Istio 是目前最成熟的服务网格实现，其核心组件包括：

控制平面（istiod）：负责配置管理、证书签发、策略下发。包含 Pilot（服务发现与配置分发）、Citadel（安全证书管理）、Galley（配置验证与处理）。
数据平面（Envoy Proxy）：以 Sidecar 模式注入到每个 Pod 中，拦截所有进出流量，执行路由、负载均衡、熔断、访问日志记录等操作。

Envoy 的关键特性：基于 xDS 协议（LDS/RDS/CDS/EDS）动态获取配置，支持热重载。在灰度批次演练中，Envoy 的访问日志过滤器（Access Log Filter）可以按批次标签精确记录流量轨迹。

1.3 数据平面与控制平面分离原理

服务网格架构的核心设计原则是控制平面与数据平面分离，这一原则直接决定了升级窗口演练中灰度批次的可行性与安全性。

平面	职责	升级影响范围	灰度批次中的角色
控制平面	策略决策、配置管理、证书签发	全局影响（需高可用部署）	统一管理灰度路由规则与日志策略
数据平面	流量转发、策略执行、日志生成	仅影响所在 Pod 实例	按批次独立升级，互不干扰

关键约束：在升级窗口演练中，控制平面升级可能导致所有数据平面短暂断连。因此，生产环境必须部署至少 2 个控制平面副本，并启用 PILOT_ENABLE_XDS_CACHE 等缓存机制，确保灰度批次间的配置推送不中断。

分离原理带来的三大优势：

独立演进：控制平面升级不影响正在处理流量的数据平面；数据平面升级（如 Envoy 版本更新）可通过灰度批次逐步替换，每批次仅影响少量 Pod。
策略集中管控：所有灰度路由规则、访问日志格式、采样率等配置在控制平面统一管理，数据平面仅负责执行，避免配置碎片化。
故障隔离：若某个 Envoy 实例因配置错误崩溃，仅影响该 Pod 的流量，控制平面可快速回滚配置，其他批次不受影响。

1.4 访问日志在架构中的位置

在服务网格架构中，访问日志由数据平面的 Envoy 代理生成，其数据流如下：

请求进入：客户端请求到达 Pod 的 Envoy Sidecar（入站监听器）。
日志记录：Envoy 根据控制平面下发的 AccessLogConfig，在请求处理的关键阶段（如请求头接收、响应发送）生成日志条目。
日志输出：日志可输出到标准输出（stdout）、文件或通过 gRPC 发送到外部日志收集系统（如 Fluentd、Logstash）。
关联分析：通过 X-Request-Id 等 Trace ID，将访问日志与分布式追踪、指标关联，形成完整的可观测性视图。

  灰度批次中的日志留痕要点：在升级窗口演练中，每个灰度批次的 Envoy 应配置独立的访问日志格式，包含 %REQ(GRPC-BATCH-ID)% 等自定义标签，以便后续按批次维度检索和分析日志。

# Envoy 访问日志配置示例（灰度批次专用）
access_log:
- name: envoy.access_loggers.file
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog
    path: /var/log/envoy/access_%GRPC-BATCH-ID%.log
    format: "[%START_TIME%] %REQ(X-REQUEST-ID)% %GRPC-BATCH-ID% %REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?)% %RESPONSE_CODE% %RESPONSE_FLAGS% %DURATION%"