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

[GopherDaily]

晚上压测个接口，带和不带 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

[Dart]

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

[mengzhuo]

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

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

[GopherDaily]

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

[GopherDaily]

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

[ryan4yin]

我这边为了避免性能问题，关掉了 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]

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

[ryan4yin]

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

[GopherDaily]

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

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

[YzSama]

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

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

[GopherDaily]

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

[ryan4yin]

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

[ryan4yin]

@GopherDaily 嗯嗯，理解理解~

[GopherDaily]

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

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

[ryan4yin]

@GopherDaily 是这样