8.4 控制平面技术：从微服务架构到单体架构
本节，笔者继续以 Istio 的架构为例，讨论控制平面的设计。
Istio 自发布首个版本以来，有着一套“堪称优雅”的架构设计，它的架构由数据面和控制面两部分组成，前者通过代理组件 Envoy 负责流量处理；后者根据功能职责不同，由多个微服务（如 Pilot、Galley、Citadel、Mixer）组成。 Istio 控制面组件的拆分设计看似充分体现了微服务架构的优点，如职责分离、独立部署和伸缩能力，但在实际场景中，并未实现预期的效果。
服务网格控制面的问题
当业务调用出现异常时，由于接入了服务网格，工程师首先需要排查控制面内各个组件的健康状态：首先检查 Pilot 是否正常工作，配置是否正确下发至 Sidecar；然后检查 Galley 是否正常同步服务实例信息；同时，还需要确认 Sidecar 是否成功注入。
一方面，控制面组件的数量越多，排查问题时需要检查的故障点也就越多。另一方面，过多的组件设计也会增加部署、维护的复杂性。
服务网格被誉为下一代微服务架构，用来解决微服务间的运维管理问题。但在服务网格的设计过程中，又引入了一套新的微服务架构。这岂不是“用一种微服务架构设计的系统来解决另一种微服务架构的治理问题”？那么，谁来解决 Istio 系统本身的微服务架构问题呢？
在 Istio 推出三年后，即 Istio 1.5 版本，开发团队对控制面架构进行了重大调整，摒弃了之前的设计，转而采用了“复古”的单体架构。新的统一组件 istiod 整合了 Pilot、Citadel 和 Galley 的功能，并以单个二进制文件的形式进行部署，承担起之前各个组件的所有职责：
- 服务发现与配置分发：从 Kubernetes 等平台获取服务信息，将路由规则和策略转换为 xDS 协议下发至 Envoy 代理。
- 流量管理：管理流量路由规则，包括负载均衡、分流、镜像、熔断、超时与重试等功能。
- 安全管理：生成、分发和轮换服务间的身份认证证书，确保双向 TLS 加密通信；基于角色的访问控制（RBAC）和细粒度的授权策略，限制服务间的访问权限。
- 可观测性支持：协助 Envoy 采集运行时指标（如延迟、错误率、请求流量等），并将数据发送到外部监控系统（如 Prometheus）；支持分布式追踪系统（如 Jaeger、Zipkin 和 OpenTelemetry），帮助分析跨服务调用链路；提供访问日志和事件日志的采集功能。
- 配置验证与管理：验证用户提交的网格配置，并将其分发到数据平面，确保一致性和正确性。
图 8-12 Istio 架构及各个组件
Istio 1.5 版本的架构变化，实际上是将原有的多进程设计转换为单进程模式，以最小的成本实现最高的运维收益。
- 运维配置变得更加简单，用户只需要部署或升级一个单独的服务组件；
- 更加容易排查错误，因为不需要再横跨多个组件去排查各种错误；
- 更加利于做灰度发布，因为是单一组件，可以非常灵活切换至不同的控制面；
- 避免了组件间的网络开销，因为组件内部可直接共享缓存、配置等，也会降低资源开销；
通过以上分析，你是否对 Istio 控制平面的拆分架构有了新的理解？看似优雅的架构设计，落地过程中往往给运维和开发人员带来意料之外的困难。正如一句老话，没有完美的架构，只有最合适的架构！