Sidecar 通俗例子理解 Istio
假设你公司一栋大楼里有很多办公室,每个办公室就是一个微服务 Pod,办公室之间要互相打电话(服务调用)。
没有 Istio 的情况:
每个办公室员工自己管打电话:自己处理超时、报错、加密通话、记通话日志。
- 新版本灰度:需要改每个办公室内部的业务代码(SDK),写逻辑控制多少电话打去新办公室。
- 熔断:某个办公室挂了,其他办公室自己写代码判断要不要不再打过去。
对应 Spring Cloud:业务代码里面引入 SDK,所有流量能力写在业务程序里。
Sidecar 模式(传统 Istio):
每个办公室门口强制安排一个接待员,就是Envoy sidecar 代理。
✅ 业务办公室里面的人完全不用改,只管干自己业务,所有进出电话全部先过接待员。
接待员 Envoy 能干的事:
- 流量:10% 的电话转给新办公室(金丝雀),超时就重试,对方办公室故障就直接熔断,不把电话打过去;还可以故意模拟对方慢、故意报错做测试(故障注入)。