这是一个创建于 1136 天前的主题，其中的信息可能经有所发展或是发生改变。
晚上压测个接口，带和不带 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