1. Service Mesh 控制面核心组件解析：Pilot、Mixer、Citadel、Galley 的功能与数据流

在 Istio 架构中，控制面由四个核心组件构成：Pilot、Mixer、Citadel 和 Galley。它们各自承担不同的职责，并通过清晰的数据流协同工作，共同实现服务发现、流量管理、策略执行与安全通信。理解这些组件的功能与交互，是进行控制面容量规划与压测的基础。

1.1 组件功能总览

1.2 核心数据流与组件交互

下图展示了控制面组件之间的数据流向，以及它们与数据面 Envoy 代理的交互关系。箭头方向代表配置下发与数据上报的路径。

1.3 组件功能详解

1.3.1 Pilot — 服务发现与流量管理引擎

• 服务注册表抽象：从 Kubernetes、Consul 等平台获取服务实例信息，维护统一的服务目录。
• xDS 协议下发：通过 gRPC 流将 LDS（监听器）、RDS（路由）、CDS（集群）、EDS（端点）配置推送到每个 Envoy。
• 流量规则转换：将 VirtualService、DestinationRule 等 CRD 翻译为 Envoy 可理解的 RouteConfiguration 与 Cluster。

1.3.2 Mixer — 策略与遥测中间层

• 前置检查（Check）：在请求被路由前，向 Mixer 发起属性检查（如白名单、速率限制），决定是否放行。
• 后置报告（Report）：请求完成后，将日志、指标、追踪数据批量上报给 Mixer，再由 Mixer 转发给后端适配器（Prometheus、Stackdriver 等）。
• 适配器模型：通过插件式适配器对接不同后端，每个适配器独立消耗连接与内存。

1.3.3 Citadel — 证书签发与身份管理

• CA 服务：作为网格内的证书颁发机构，为每个工作负载签发 SPIFFE 格式的 x509 证书。
• 自动轮换：证书默认有效期 24 小时，Envoy 通过 SDS（Secret Discovery Service）定期向 Citadel 请求新证书。
• 身份绑定：将 Kubernetes ServiceAccount 映射为 SPIFFE ID，确保服务间 mTLS 通信的身份可信。

1.3.4 Galley — 配置验证与分发枢纽

• CRD 校验：拦截所有 Istio 相关 CRD（如 VirtualService、DestinationRule）的写入请求，进行语义与语法校验。
• 内部模型转换：将校验通过的配置转换为 Istio 内部抽象模型，再分发给 Pilot 和 Mixer。
• 配置状态管理：维护配置的版本号与变更历史，确保 Pilot 和 Mixer 能增量更新，避免全量推送。

1.4 组件间数据流时序

以下时序图展示了一次典型的配置变更事件在控制面内部的流转过程：

1. 用户提交配置：通过 kubectl apply 创建或更新 Istio CRD。
2. K8s API 写入 etcd：配置持久化到 etcd，并触发 Watch 通知。
3. Galley 校验与转换：Galley 监听 CRD 变更，执行校验后转换为内部模型，推送给 Pilot 和 Mixer。
4. Pilot 生成 xDS：Pilot 根据新的内部模型生成对应的 LDS/RDS/CDS/EDS 配置。
5. Envoy 热更新：Envoy 通过 gRPC 流接收增量 xDS 更新，无中断地应用新配置。

1.5 组件资源消耗特征对比