istio 的主要问题是资源消耗，次要问题是基本只支持 HTTP
GopherDaily · 2022-11-08 00:59:10 +08:00 · 2643 次点击这是一个创建于 746 天前的主题，其中的信息可能已经有所发展或是发生改变。
晚上压测个接口，带和不带 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
 |
1
Dart 2022-11-08 01:42:01 +08:00
HTTP 本来就耗资源，不过还要看你集群的配置，说白了 K8s 是云厂商 Google 搞出来的，设计的初衷主要还是面向“企业级”，Istio 组件也多，没有足够的资源做支撑对业务应用就是负担。
|
 |
2
mengzhuo 2022-11-08 09:30:04 +08:00  1
这就看取舍了，如果你就 10 个 node 以下，连 k8s 都不用上。
istio 是流量全加密，不需要自己再配置证书、维护证书一堆破事。 网格化改造完之后可以不用自己折腾链路监控一堆破事， egress 可以调控流量和 destination ，顺手还能断流，香得不行。 多出来的功能跟这点性能下降比，还是可以的，因为一般业务也会读个库，少说也是 50ms 起。 |
 |
3
GopherDaily OP @Dart 其实量大了更在意资源，毕竟钱的相对基数大太多了
|
|
4
GopherDaily OP @mengzhuo envoy 增加的耗时倒是不可怕，自身的序列化和反序列化消耗了大量 CPU
|
 |
5
ryan4yin 2022-11-08 11:39:21 +08:00 2
我这边为了避免性能问题，关掉了 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 这么离谱的现象，我觉得肯定是有别的问题。 |
|
6
ryan4yin 2022-11-08 11:41:13 +08:00
另外一个现象是，我们的节点 CPU 利用率其实一直不高，加了个 Sidecar 看着涨了 50% 的 CPU ，但是对成本的影响并不大...
|
|
7
ryan4yin 2022-11-08 11:42:50 +08:00
Istio Sidecar 默认的资源 requests 很小，QPS 稍微高一点基本就会用超，相当于说加了个 Sidecar 还帮我们提升了节点资源利用率 emmm
不过这个是我们集群资源利用率优化不够带来的，往下讨论又是另外一个问题了，就不展开了。 |
|
8
GopherDaily OP @ryan4yin 我是专门在压测 snowflake ID 的生产，QPS 上不去才手动去掉。
envoy 大概 1c 处理 10k req ，大规模观察是。 上了肯定是下不了的，但是不妨碍吐槽嘛。 10x 这个问题，一个可能是 envoy 配置的 upstream 链接池可能处理不了这么多的请求；另一个可能是我们在 filter 做了一些花活 |
 |
9
YzSama 2022-11-08 16:20:22 +08:00
压测 envoy 得出的理论值，另外也要看 业务应用 实例，是否也能达到这个要求。
感觉真实场景，也不会全部服务都挂上 sidecar 的。仅针对需要对外服务的业务 |
|
10
GopherDaily OP @YzSama 看你规划，大部分情况是都需要，服务发现、流量管控和 APM 都挂在 istio 上了
|
|
11
ryan4yin 2022-11-09 10:40:36 +08:00
@YzSama 是这样，我这边业务侧为了平衡成本跟流量的可观测性、流控等需求，曾经在加 sidecar 跟不加 sidecar 间反复横跳。
但是去掉了 sidecar ，它们业务服务内部又没有做完善的监控告警的话，出了问题流量降级了根本没人知道，因为出了这么次大问题，后来业务侧的领导就拍板全给加上了 sidecar emmm |
|
12
ryan4yin 2022-11-09 10:40:57 +08:00
@GopherDaily 嗯嗯，理解理解~
|
|
13
GopherDaily OP @ryan4yin sidarcar 之后 infra 终于不要大规模干预框架代码，终于不要多语言 SDK 了，感觉基本是回不去的；
而且，proxy 做为代理后针对 proxy 玩花活太容易，出成果太直接 |
|
14
ryan4yin 2022-11-29 15:40:28 +08:00
@GopherDaily 是这样
|
Select Language