Istio从微服务架构回归单体istiod的教训

Istio 1.5版本之前，控制平面本身是用微服务架构开发的，拆成Mixer（鉴权 策略与遥测）、Pilot（对接Envoy数据平面、按xDS协议分发策略）、Galley （配置管理，感知外部配置）、Citadel（安全加密，认证鉴权、凭据和RBAC 管理）四个独立模块——这是一个颇具理想主义色彩的设计，希望控制平面的 每个组件都能独立部署。但经过两三年生产实践，大量用户反馈这套微服务化 的控制平面有过度设计的嫌疑：独立组件反而带来部署复杂、职责边界不清晰 的问题。从1.5版本起，Istio重新回归单体架构，把Pilot、Galley、Citadel的 功能全部合并进一个新进程istiod（Mixer的功能被下沉，边车代理直接支持 相应能力），原来的独立组件变成istiod内部的逻辑子模块，而不是完全推翻 之前的设计——只是把多进程形态优化成单进程形态。istiod承担起数据平面 交互（边车注入、策略分发、配置分发）、流量控制（请求路由、熔断限流 重试、故障注入流量镜像等调试能力）、通信安全（CA证书生成、SDS代理、 认证授权）、可观测性（日志/追踪/度量）几乎全部控制平面职责。这个案例 是一个值得记住的架构教训：微服务拆分不是免费的午餐，”每个组件都能 独立部署”这个理想目标，如果换来的是部署复杂度和职责边界模糊，代价可能 超过收益——单体不是微服务时代的原罪，该不该拆分要看拆分本身是否真的 换来了对应的收益。