Istio性能问题讨论

栏目: 后端 · 发布时间: 5年前

内容简介:今天,来自 Shopify 的Shopify 在部署Istio作为他们的服务网格解决方案,但是遇到问题(hitting a wall:撞墙):cost/成本!

背景

今天,来自 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的功能,可以分为两大块:

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

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

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

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

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

尾声

Mixer中这两块的问题,去年就已经很明显。遗憾的是一年过去了,截止到Istio 1.1版本还是没有改变。希望Istio 1.2 中会有实质性的改善。

另外,从我们团队最近的遭遇看,Istio的性能问题,不仅仅在于Mixer,之前一直觉得不会有大问题的Pilot也是状况百出,有关这块,后续会撰文说明。


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

信息烟尘

信息烟尘

戴维·申克 / 黄锫坚 / 江西教育出版社 / 2002 / 14.50元

今天,我们被大量的信息淹没了:传真、电子邮件、各种新闻、消息和铺天盖地的广告,正如人们以前预示的那样:出现了一个令人鼓舞的信息时代,媒体专家兼网络评论员戴维·申克透过这些繁荣的表象,揭示了大量的无用的信息对我们造成的干扰,或者说,“信息烟尘”对我们个人的健康(包括精神上的和肉体上的)及对社会造成的极大危害。这《信息烟尘:在信息爆炸中求生存》宣告了“信息时代”神话的破灭。一起来看看 《信息烟尘》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

JSON 在线解析
JSON 在线解析

在线 JSON 格式化工具

在线进制转换器
在线进制转换器

各进制数互转换器