Istio 架构与核心组件
好，我们直接进入正题。上一章聊了为什么需要服务网格，这章咱们把 Istio 拆开看看。你把它想象成一个智能交通系统，控制平面就是交管中心，数据平面就是路口的摄像头和信号灯。
我个人习惯，学一个新东西，先看它长什么样，再琢磨怎么用。 Istio 的架构图很简单，但你要是只看官方文档，容易被一堆名词绕晕。我结合自己踩过的坑，带你捋一遍。
整体架构：控制平面 vs 数据平面
Istio 分两层：控制平面和数据平面。数据平面负责处理流量，控制平面负责告诉数据平面怎么处理。
说白了，数据平面干苦力，控制平面下指令。这个关系很重要，你想想看，如果控制平面挂了，数据平面还能按最后一条指令跑一阵子，但没法做调整了。
数据平面处理的是“数据包”，控制平面处理的是“配置”。两者之间通过 xDS 协议通信，这是 Istio 与 Envoy 对话的语言。
核心组件逐个拆解
Istio 1.5 之后，控制平面合并成了一个单体——istiod。但内部还是那几个组件在干活。我刚开始接触的时候，总觉得“合并成一个了，就不用学那么细了吧？” 结果出了问题，日志里全是 istiod 的报错，根本不知道是 Pilot 还是 Citadel 的锅。还是得拆开看。
下面这个表，是我总结的几个核心组件，你看一眼就能对上号：
| 组件名 | 所属平面 | 核心职责 | 一句话记住它 |
|---|---|---|---|
| Pilot | 控制平面 | 服务发现 + 流量管理 | 它告诉 Envoy 去哪找谁，怎么走 |
| Mixer | 控制平面 | 访问控制 + 遥测采集 | 它负责“同意与否”以及“记个账” |
| Citadel | 控制平面 | 证书签发 + 身份管理 | 它就是 Istio 的 CA（证书颁发机构） |
| Galley | 控制平面 | 配置验证 + 分发 | 它是守门员，检查配置有没有语法错误 |
| Envoy | 数据平面 | 代理所有进出流量 | 每个 Pod 里的“交通警察” |
Pilot：服务发现的“大脑”
Pilot 是我接触最多的组件。它负责两件事：一是从平台（比如 Kubernetes）拉取服务注册信息，二是把这些信息转换成 Envoy 能理解的配置。
记得有一次，我在项目里调整了服务间的超时时间，结果怎么都不生效。查了一整天，最后发现 Pilot 的缓存没刷新。嗯，这里要注意，Pilot 有自己的缓存机制，改了配置别急着看效果，等几秒或者手动触发一次同步。
我曾经直接修改了 Envoy 的配置，想绕过 Pilot 做点“骚操作”。事实证明，这是给自己挖坑。Pilot 会定期覆盖 Envoy 的配置，你改的会被冲掉。正确的做法是通过 Istio 的 CRD（比如 VirtualService、DestinationRule）来操作。
Mixer：策略与遥测的“管家”
Mixer 在 Istio 1.5 之后默认被移除了，但它的能力被拆解并内置到了 Envoy 和 istiod 里。但我觉得还是有必要讲一下，因为很多老项目还在用，而且理解它的设计思路，对你理解“策略执行点”这个概念很有帮助。
Mixer 的核心就是“解耦”。它把策略检查和遥测报告从 Envoy 里抽出来，变成一个独立的服务。好处是 Envoy 变轻了，坏处是多了一跳网络开销，性能会有损耗。
为什么会这样？因为每个请求到了 Envoy，Envoy 得先问 Mixer：“这个请求能过吗？” 然后 Mixer 查完策略再告诉 Envoy。一来一回，延迟就上去了。这也是为什么后来 Istio 社区决定把它砍掉，直接让 Envoy 自己做策略检查。
如果你在用 Istio 1.5 之前的版本，并且启用了 Mixer，务必注意它的性能瓶颈。我曾经在一个高并发的支付系统上，因为 Mixer 的检查逻辑太复杂，导致 p99 延迟从 10ms 飙到了 200ms。
Citadel：安全通信的“护盾”
Citadel 是 Istio 实现 mTLS（双向 TLS）的核心。咱们这门课是讲“接口安全策略”的，所以 Citadel 是你必须吃透的组件。
它的工作流程很简单：
- Citadel 监听 Kubernetes 的 ServiceAccount 创建事件。
- 为每个 ServiceAccount 生成一个 X.509 证书，并注入到对应的 Pod 里。
- Envoy 之间通信时，用这个证书做双向认证。
说白了，就是 Istio 给每个服务发了一张“身份证”，别人一看就知道你是谁。
我在项目里遇到过一个坑：证书轮换。Citadel 默认证书有效期是 24 小时，到期前会自动轮换。但如果你的集群时间不同步，证书验证就会失败，服务直接断连。所以，确保 NTP（网络时间协议）服务正常工作，这是最基本的前提。
Galley：配置的“验证员”
Galley 相对来说比较低调，但它的作用很重要。它负责验证你提交的所有 Istio 配置（比如 VirtualService、DestinationRule 等），确保它们符合规范，然后把正确的配置分发给 Pilot。
我个人习惯，每次改动配置前，都会用 istioctl analyze 命令先检查一遍。这个命令背后调用的就是 Galley 的验证逻辑。如果不检查，直接 apply，很可能会把错误的配置推到集群里，导致服务间通信异常。
举个例子，我曾经写了一个 VirtualService，把流量路由到了一个不存在的 subset（子集）上。如果没有 Galley 帮我拦住，Pilot 会把这个配置下发下去，结果就是 50% 的请求都 503 了。
Envoy：数据平面的“执行者”
前面四个都是控制平面的，Envoy 是唯一一个跑在数据平面的。它作为 Sidecar 容器，跟业务容器一起待在同一个 Pod 里。
Envoy 接收来自 Pilot 的配置，然后根据这些配置来转发、拦截、修改流量。你设置的重试、超时、熔断、限流，最终都是 Envoy 在执行。
你别看 Envoy 只是一个代理，它的能力非常强，支持热重启、动态配置、丰富的过滤器链。我们在后面讲“安全策略落地”的时候，会频繁操作 Envoy 的行为。
排查问题时，我最常用的就是直接看 Envoy 的 admin 界面。在 Pod 里执行 curl localhost:15000/stats 或者 curl localhost:15000/config_dump，就能看到 Envoy 当前的所有配置和统计信息。这比看日志快多了。
它们是怎么协同工作的？
了解了每个组件，我们来看看它们怎么配合。下面这张图，是我自己整理的 Istio 核心工作流程：
你从上往下看：
- 第一步：用户通过
kubectl apply提交 Istio 配置（比如一个 VirtualService）。这个配置先被 Kubernetes API 接收。 - 第二步：Galley 监听到新配置，对它进行格式和逻辑校验。如果校验通过，就转发给 Pilot。
- 第三步：Pilot 拿到配置后，同时做两件事：一个是结合服务注册信息，生成 Envoy 能读懂的 xDS 配置；另一个是从 Citadel 那边获取证书信息。
- 第四步：Pilot 把最终的配置下发给每个 Pod 里的 Envoy 代理。Citadel 则把证书直接注入到 Pod 里。
- 第五步：Envoy 根据配置，开始拦截业务容器的所有进出流量，执行路由、限流、mTLS 等策略。
整个流程的核心是“配置驱动”。你改配置 → Istio 自动响应 → 所有代理自动更新。你不需要重启任何服务，这就是“流量管理”的精髓。
关于 mTLS 的进一步说明
刚才 Citadel 部分提到了 mTLS，这里我再多说两句。因为咱们这个课程叫“接口安全策略落地”，mTLS 就是第一道防线。
mTLS 不是简单地“加个证书”，它涉及三个层面的工作：
- 身份认证：服务 A 访问服务 B 时，B 要求 A 出示证书，证明“你确实是 A”。
- 机密性：证书验证通过后，建立一个加密通道（TLS），所有数据都加密传输。
- 完整性：防止数据在传输过程中被篡改。
Istio 默认开启的是“宽容模式”（permissive mode），意思是：如果对方发了证书就做 mTLS，没发证书就用明文。但为了安全，我建议你在生产环境开启“严格模式”（strict mode），强制所有服务间通信都必须走 mTLS。
我曾经在一个有 200 多个微服务的系统上，直接开启了全局严格模式。结果一堆老服务炸了——因为它们不支持 mTLS，也没有对应的证书。正确做法是：先开启宽容模式观察一段时间，确认所有服务都能正常获取证书后，再逐步切换到严格模式。
本章小结
到这，Istio 的核心架构和组件我们就过了一遍。控制平面（istiod）负责定规则，数据平面（Envoy）负责执行规则。Pilot 管“路怎么走”，Citadel 管“你是谁”，Galley 管“规则对不对”。Envoy 则是那个在每个 Pod 里默默干活的兄弟。