Istio：微服务之间那些麻烦事，它替你管了

Kubernetes 把应用拆成了一个个微服务，拆完之后你会发现新的问题来了：服务之间怎么通信？谁来管认证、加密、限流、灰度发布？每个服务自己搞一套，代码越写越乱。

Istio 干的就是这件事。它是一个开源的服务网格，透明地盖在你现有的应用上面，把流量管理、安全认证、可观测性这些能力统一收到底层，业务代码基本不用改。

架构：三个角色各管一摊

Istio 的架构不复杂，理解了三个核心组件就差不多了。

Envoy 负责数据面。每个微服务旁边都会挂一个 Envoy 代理，所有进出的流量都经过它。服务之间怎么路由、要不要熔断、要不要重试，全由 Envoy 处理。业务代码不需要知道这些事的存在。

Istiod 是控制面。它负责服务发现、配置下发和证书管理。你在 Istiod 上配一条路由规则，它会自动同步到所有的 Envoy 代理上。

Ztunnel 是后加进来的。用 Rust 写的轻量级代理，跑在 Ambient mesh 模式下。这个模式不需要在每个服务旁边塞 sidecar，靠节点级的代理就能完成安全连接和可观测性，资源开销小很多。

实际能解决什么问题

举几个常见的场景。

流量管理：你想把 5% 的流量导到新版本上做灰度发布，在 Istio 里配一条规则就行，Envoy 会自动按比例分流。

安全认证：服务之间的调用要加密、要验证身份，以前得每个服务自己搞 TLS 和证书，现在 Istio 自动帮你处理 mTLS，服务间通信加密是开箱即用的。

可观测性：每个请求的延迟、成功率、流量大小，Envoy 全都记录下来。配合 Prometheus、Grafana 之类的工具，服务的运行状态一目了然。

项目结构

Istio 的代码分散在多个仓库里，各管各的：

• istio/api：定义 API 接口和配置格式
• istio/istio：主仓库，包含核心组件、安装文件和示例
• istio/proxy：Envoy 的扩展，处理认证授权和遥测
• istio/ztunnel：Ztunnel 的 Rust 实现
• istio/client-go：Kubernetes 客户端，方便用代码操作 Istio 资源

其中 istio/api 和 istio/client-go 提供稳定的接口，可以作为库直接引用。其他仓库的内部接口不保证向后兼容。

值不值得用

Istio 是 CNCF 毕业项目，社区活跃，文档完善。38000 多个 Star 也说明了它的认可度。

不过它不是轻量级的工具。Istiod 加上一堆 Envoy 代理，对集群资源有一定开销。如果你的服务数量不多、流量不大，可能用不到这些能力。但如果你的微服务规模上去了，服务间的流量管理、安全、可观测性全靠自己搞，成本反而更高。

Ambient mesh 模式是个值得关注的方向。去掉 sidecar 之后部署变简单了，资源占用也降下来了，对资源敏感的环境比较友好。

关注的方向。去掉 sidecar 之后部署变简单了，资源占用也降下来了，对资源敏感的环境比较友好。