Service Mesh - Istio性能之殇

Service Mesh这个概念在2017年开始爆炸式增长,同时Spring、Linkerd、Istio等Service Mesh的出现实现可谓是百家争鸣,文体两开花。Istio从我当时开始关注的他的0.3版本经过无数的bug fix,2次API更新,已经经历了1.0 release。撰写本文的时候Istio是1.0.3。

首先我想说下为什么我们选择Istio作为考量对象:首先考虑通用性,我们业务比较复杂技术栈有Go、node、python... 因此需要一种侵入性较低的方案,而且显然一口气转Spring不太现实。其次考虑稳定性,Istio由Google、IBM、Lyf支持并且已经在IBM内部做过Service的改造经历过线上的验证。

还是以一张Istio架构说起,一次API请求从Ingress进入,到Service A的Side car,A服务处理业务,这个过程经2次七层应用代理转发,并调用上游服务B,这个过程又要经历两次Side car(4次内核iptables转发,2次7层应用层代理转发)。

请输入图片描述

另外如果开启了Istio Mixer,每次请求又要额外做一些限流、日志、权限控制等等。

请输入图片描述

我们在三台Worker配置为4C、16G的节点上(阿里云计算网络增强VM实例、除了kubelet等必须组件无其他服务)业务处理能力约3000QPS,在高QPS压测中发现Mixer Telemetry占了大量CPU,Mixer Adapter中消息积压内存和GC开销上升。计算资源开销也比较严重,约3/4的计算资源都被Service Mesh的各个组件吃掉了,业务链路的延迟增加了约20ms。

4.png

我开始关注Istio的性能问题,原来官方的daily build也会有性能测试https://ibmcloud-perf.istio.io/regpatrol/。可以观察到Envoy代理以及Mixer对性能造成很大的开销,在Mixer功能全开的情况下(其实主要是Telemetry)性能只有纯Ingress(网关模式)的一半。

有意思的是我在google讨论组里面找到一份相对官方的白皮书,介绍了一个模拟业务系统的传统Gateway以及Istio引入之后的性能开销以及延迟开销,基本与我这边相同https://docs.google.com/document/d/1ob9M2TfI5GS3_rqrEhWFIpVyfFVKPTE8N3YZpeiDJxw/edit#
里面也提及了Isito未来的目标,大体都是以提升性能为目标。

Isito给我本带来了通用的熔断、限流、防火墙、路由规则、链路跟踪,但是也带来了非常严重的资源开销。在这个时间点,这些功能完全可以是可替代的而且成本相对低得多,希望在2019年能看到Istio有长足的进步和更多Service Mesh生态繁荣。

仅有 1 条评论
  1. wangbin wangbin

    请问贵司有没有在线上使用Istio?

添加新评论