转载

Istio性能问题讨论

背景

今天，来自 Shopify 的 Michael Kipper 发表了一篇文章：

Benchmarking Istio & Linkerd CPU

Shopify 在部署Istio作为他们的服务网格解决方案，但是遇到问题（hitting a wall：撞墙）：cost/成本！

作者自己做了一次对比测试，详细的测试情况请见原文。我们这里直奔结果，看 Istio 和 Linkerd2 的对比。

测试结果

控制平面

Istio性能问题讨论

Linkerd2 的控制平面，大概22 mcore。

Istio性能问题讨论

Istio 的控制平面，约 750 mcore，大约是 linkerd2 的35倍。而且从图片上的数据看，istio-telemetry 使用 643 mcore，占比高达 85%。但即使去除 mixer（ istio-telemetry），istio 依然超过100 mcore，依然是 Linkerd2 的4到5倍。

数据平面

再看控制平面的表现，Istio 这边是基于c++的成熟稳重的 Envoy，Linkerd2 则是基于新型语言Rust全新开发。

Linkerd2 Proxy 的表现，这是客户端 Sidecar：

Istio性能问题讨论

Istio/Envoy的表现（客户端 Sidecar）：

Istio性能问题讨论

还有服务器端sidecar的使用对比，就不继续转了，简单说结果是Istio/Envoy的CPU使用比 Linkerd 多 60%。

总体来说，在数据平面，Istio/Envoy的CPU使用比 Linkerd 多 50%～60%。

测试结果总结

综上所述，Istio在控制平面的CPU消耗约是 Linkerd2 的35倍（开启Mixer）或者4倍（关闭Mixer），在数据平面的CPU消耗是 Linkerd2 的1.5倍。

这个消耗还是很明显的，尤其控制平面更是有些夸张。

Twitter上的讨论

有兴趣的同学可以直接去看 twitter 上的讨论： https://twitter.com/michaelkipper

Istio性能问题讨论

讨论中谈到说既然mixer消耗最大，可以关闭，如果你不需要。但是明显这个建议是不能被接受的：毕竟使用Istio的一个很主要的原因就是可观测行，简单粗暴的去掉mixer的telemetry功能是不可取的。

然后就是一个搞笑的地方，Karl 质疑说测试对比中 Linkerd2 是否提供了同样的可观测行，William Morgan（开发Linkerd2 的 Beoyant 公司的CEO）跳出来说 Yes！

后面 Envoy 的灵魂人物，Matt Klein接连发了几个twitter

Istio性能问题讨论

最后这条值得注意：

具体到 Istio, 在我看来, 他们围绕 Mixer 做出了一些不幸的架构决定。好消息是, 我被告知, 在1.2 发布后这些问题会被解除, 这应该会大大提高proxy资源的利用率。

看来是个好消息，问题是具体会有什么内容？Matt 没说，准备去调研一下，如有收获后续更新。

Mixer背景补充

在这里补充一些Mixer的背景知识，关于Mixer的功能，可以分为两大块：

策略/policy：或者叫做precondition，体现在api上的方法名是 check()，实现上是同步阻塞+每个请求都要执行，因此对性能影响极大，早早就被质疑，考虑到策略的必要性没那么强而性能消耗又实在过高，因此社区很多人选择关闭mixer的policy功能。后来Istio依从社区的声音，在Istio1.1版本之后默认将mixer的policy功能关闭，从而结束了社区没完没了的类似问题：为什么这么慢？怎么关闭policy？
遥测/telemetry：包括metric/trace等，用于实现可观测行，体现在api上的方法名是 report()，这块也有一些质疑，不过好在report的实现是异步+批量，性能影响没check()那么夸张，而可观测性又太过重要，因此一直凑合在用。然后今天，被 Linkerd2 吊打。

有关 Mixer telemetry的实现，和mixer cache存在的问题，请见我去年的博客文章：

Mixer Cache: Istio的阿克琉斯之踵?
Istio Mixer Cache工作原理与源码分析

另外，为什么Linkerd2 的可观测性的实现性能可以高这么多？

这里涉及到Istio的架构设计，Istio的解决方案是 Sidecar 将各种请求信息发送给Mixer，由Mixer中的adapter进行各种处理，有很好的设计弹性和灵活度，但是付出了多一次 Sidecar 到Mxier的远程调用的开销。而 Linkerd2 的前身 Conduit，采用的方式是在 Sidecar 中直接完成处理，不走mixer远程访问。

有关这块的详细分析，请见我去年的演讲文章大规模微服务架构下的Service Mesh探索之路的 架构设计 一节。