服务治理技术选型

Istio是一个开源的**服务网格（Service Mesh）**平台，主要用来管理微服务之间的通信。

可以把它理解成：
👉 在系统里“所有服务之间通信的中间层管家”。

如果说Kubernetes负责“部署和调度服务”，
那 Istio 负责“服务之间怎么通信、怎么控制、怎么监控”。

在微服务架构里，会有很多复杂问题：

• 服务之间怎么调用？（A 调 B）
• 调用失败怎么办？重试？熔断？
• 怎么做灰度发布 / 金丝雀发布？
• 怎么统计调用延迟、成功率？
• 怎么保证通信安全（加密、认证）？

👉 这些问题如果写在业务代码里，会非常乱。

Istio 的作用就是：
把这些“通用通信能力”从业务代码里抽出来统一处理。

Istio 通过一个很关键的设计：
Sidecar（边车模式）
每个服务旁边都会多一个代理（通常是 Envoy）：

服务A ↔ Sidecar代理A ↔ Sidecar代理B ↔ 服务B

👉 所有流量都会经过代理，而不是服务直接通信。

这样带来的好处：

• 不改业务代码就能控制流量
• 可以统一做限流、重试、日志
• 可以插入安全策略（mTLS）

它能做
1️⃣ 流量管理

• 灰度发布（10%流量到新版本）
• A/B测试
• 路由控制

2️⃣ 可观测性

• 请求成功率
• 延迟
• 调用链追踪（Tracing）

3️⃣ 安全

• 服务间自动加密（mTLS）
• 身份认证
• 权限控制

4️⃣ 容错能力

• 超时
• 重试
• 熔断

和 Kubernetes 的关系

• Kubernetes：负责部署、扩缩容
• Istio：负责服务通信治理

👉 两者是互补关系，不是替代关系。