istio 的主要问题是资源消耗，次要问题是基本只支持 HTTP

This topic created in 1290 days ago, the information mentioned may be changed or developed.

晚上压测个接口，带和不带 sidecar 的 QPS 差了 10 倍，虽然感觉可能不纯是 envoy 带来的，但还是挺想吐槽。

往好处想是活来了，KPI 来了，绩效也来了。

顺便推荐 hey 和 ghz ，使用便捷程度直追 ab 。

Summary: Count: 500000 Total: 10.63 s Slowest: 29.76 ms Fastest: 0.37 ms Average: 1.57 ms Requests/sec: 47052.73 Response time histogram: 0.373 [1] | 3.311 [490186] | 6.249 [8568] | 9.188 [467] | 12.126 [371] | 15.065 [245] | 18.003 [55] | 20.941 [102] | 23.880 [0] | 26.818 [1] | 29.757 [4] | Latency distribution: 10 % in 0.84 ms 25 % in 0.97 ms 50 % in 1.37 ms 75 % in 1.99 ms 90 % in 2.49 ms 95 % in 2.81 ms 99 % in 3.91 ms Status code distribution: [OK] 500000 responses

qps

sidecar

14 replies 2022-11-29 15:40:28 +08:00

Dart

Nov 8, 2022

HTTP 本来就耗资源，不过还要看你集群的配置，说白了 K8s 是云厂商 Google 搞出来的，设计的初衷主要还是面向“企业级”，Istio 组件也多，没有足够的资源做支撑对业务应用就是负担。

mengzhuo

Nov 8, 2022

这就看取舍了，如果你就 10 个 node 以下，连 k8s 都不用上。

istio 是流量全加密，不需要自己再配置证书、维护证书一堆破事。
网格化改造完之后可以不用自己折腾链路监控一堆破事，
egress 可以调控流量和 destination ，顺手还能断流，香得不行。
多出来的功能跟这点性能下降比，还是可以的，因为一般业务也会读个库，少说也是 50ms 起。

GopherDaily

Nov 8, 2022

@Dart 其实量大了更在意资源，毕竟钱的相对基数大太多了

GopherDaily

Nov 8, 2022

@mengzhuo envoy 增加的耗时倒是不可怕，自身的序列化和反序列化消耗了大量 CPU

ryan4yin

Nov 8, 2022

我这边为了避免性能问题，关掉了 mTLS.
不过我刚到公司就是 Istio 了，没专门跟无 Sidecar 模式做过对比。
不过我们业务场景下加了 Sidecar QPS 降低肯定没这么夸张，上 Istio 成本要涨十倍的话，业务团队肯定不会接的，老板不得骂死。

我印象中 QPS 高的服务，纯 HTTP ，无调优情况下 sidecar : app 的 cpu 比值为 1:2 ，延迟增加了 3ms.

但是有了 Sidecar 后很多事情就好做了，比如说我们因此得以快速上线 gRPC ，把增加的损耗又全砍掉了。
接口改造为 gRPC 后，服务流量下降 70%，延迟下降 30% ~ 50%，第二步优化给 gRPC 上再加了层 gzip ，流量又降了 70%，而 CPU/延迟基本没啥增加（砍流量主要是为了省 AWS 跨区流量费）。

总的来说多了个 Sidecar 性能有损耗很正常，加它的目的不就是为了拿性能换开发迭代效率嘛。

至于差了 10 倍 QPS 这么离谱的现象，我觉得肯定是有别的问题。

ryan4yin

Nov 8, 2022

另外一个现象是，我们的节点 CPU 利用率其实一直不高，加了个 Sidecar 看着涨了 50% 的 CPU ，但是对成本的影响并不大...

ryan4yin

Nov 8, 2022

Istio Sidecar 默认的资源 requests 很小，QPS 稍微高一点基本就会用超，相当于说加了个 Sidecar 还帮我们提升了节点资源利用率 emmm
不过这个是我们集群资源利用率优化不够带来的，往下讨论又是另外一个问题了，就不展开了。

GopherDaily

Nov 8, 2022

@ryan4yin 我是专门在压测 snowflake ID 的生产，QPS 上不去才手动去掉。
envoy 大概 1c 处理 10k req ，大规模观察是。
上了肯定是下不了的，但是不妨碍吐槽嘛。

10x 这个问题，一个可能是 envoy 配置的 upstream 链接池可能处理不了这么多的请求；另一个可能是我们在 filter 做了一些花活

YzSama

Nov 8, 2022

压测 envoy 得出的理论值，另外也要看业务应用实例，是否也能达到这个要求。

感觉真实场景，也不会全部服务都挂上 sidecar 的。仅针对需要对外服务的业务

GopherDaily

Nov 8, 2022

@YzSama 看你规划，大部分情况是都需要，服务发现、流量管控和 APM 都挂在 istio 上了

ryan4yin

Nov 9, 2022

@YzSama 是这样，我这边业务侧为了平衡成本跟流量的可观测性、流控等需求，曾经在加 sidecar 跟不加 sidecar 间反复横跳。
但是去掉了 sidecar ，它们业务服务内部又没有做完善的监控告警的话，出了问题流量降级了根本没人知道，因为出了这么次大问题，后来业务侧的领导就拍板全给加上了 sidecar emmm

ryan4yin

Nov 9, 2022

@GopherDaily 嗯嗯，理解理解~

GopherDaily

Nov 9, 2022

@ryan4yin sidarcar 之后 infra 终于不要大规模干预框架代码，终于不要多语言 SDK 了，感觉基本是回不去的；

而且，proxy 做为代理后针对 proxy 玩花活太容易，出成果太直接

ryan4yin

Nov 29, 2022

@GopherDaily 是这样